The real fix here is to make sure the . operator actually gets its own source
location. Right now, it depends on what code is being inlined from the stdlib
thus the failure with the debug stdlib only. We can relax the test further in
the short term.
rdar://108132971
This patch replaces the stateful generation of SILScope information in
SILGenFunction with data derived from the ASTScope hierarchy, which should be
100% in sync with the scopes needed for local variables. The goal is to
eliminate the surprising effects that the stack of cleanup operations can have
on the current state of SILBuilder leading to a fully deterministic (in the
sense of: predictible by a human) association of SILDebugScopes with
SILInstructions. The patch also eliminates the need to many workarounds. There
are still some accomodations for several Sema transformation passes such as
ResultBuilders, which don't correctly update the source locations when moving
around nodes. If these were implemented as macros, this problem would disappear.
This necessary rewrite of the macro scope handling included in this patch also
adds proper support nested macro expansions.
This fixes
rdar://88274783
and either fixes or at least partially addresses the following:
rdar://89252827
rdar://105186946
rdar://105757810
rdar://105997826
rdar://105102288
There was a regression in atos, but now a new-enough Xcode version that
includes the fixed atos is now available on Swift CI bots. We can
re-enable the tests.
Radar-Id: rdar://problem/85471075
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
The two TSan versions of the
`test/Concurrency/Runtime/async_let_fibonacci.swift` were disabled for
different reasons:
[1] Swift Concurrency work broke the test and it was never re-enabled.
[2] Regression in atos required test to be disabled. Re-enablement was
blocked on Swift CI upgrading to an Xcode that contains the fixed
version of atos.
While the TSan versions of the test was not running they fell out of
sync with the original test and then started failing for different
(trivial) reasons once re-enabled.
Please help us keep these tests running by:
* Not landing work that makes them fail (and deferring the fix to a
later point), if at all possible. Breaking sanitizers should be a
"blocker".
* Keeping them in sync with the original tests.
Radar-Id: rdar://83162880
[1] rdar://76446550 (Re-enable test: Sanitizers/tsan/async_let_fibonacci.swift)
[2] rdar://80274830 ([Swift CI] Sanitizer report symbolication fails due to regression in atos)
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
We updated the Swift CI nodes to a version of Xcode that includes the
fix for a regression in atos that broke sanitizer report symbolication.
Regression: rdar://79151503 (If atos is handed a dSYM, it should find the binary rather than erring)
Fix: rdar://80345994 (Regression: atos -p <pid> exits immediately)
Radar-Id: rdar://80274830
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
After upgrading the OS and Xcode on the CI nodes sanitizer report
symbolication fails because we fail to start atos. This might be a
sandboxing issue.
Radar-Id: rdar://80274830
Some new Sanitizer tests are failing on watchOS because we fail to start
atos to symbolicate the report. FileCheck then fails when we assert on
the generated report.
Radar-Id: rdar://75766734
Disable for "remote runs". We don't copy the corresponding `.dSYM`
with the test binary, and hence symbolication (source info) does not
succeed.
Also explicitly mark this test unsupported on for the 32-bit iOS
simulator. It has an outdated version of `atos` that can't demangle
Swift symbol names.
Enable on other platforms.
rdar://68353068
This test checks that Sanitizer reports contain properly symbolicated
stacks. Let's make sure that all of the expected frames appear in the
stack by disabling inlining and preventing tail call optimization.
rdar://68171463
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
Add a test that checks symbolication for out-of-process and in-process
symbolication for both Apple platforms and Linux.
Note that there already exist tests in the compiler-rt test suite that
check report symbolication. The purpose of this test is to have simple
smoke tests for Swift, and specifically Swift demangling.
rdar://62753845
Co-authored-by: Julian Lettner <julian.lettner@apple.com>
