[4.2][Exclusivity] Teach separate-stored-property relaxation about TSan instrumentation #17178
Conversation
Factor out common logic for detecting sanitizer instrumentation and put it in SIL/InstructionUtils.
…strumentation The compile-time exclusivity diagnostics explicitly allow conflicting accesses to a struct when it can prove that the two accesses are used to project addresses for separate stored properties. Unfortunately, the logic that detects this special case gets confused by Thread Sanitizer's SIL-level instrumentation. This causes the exclusivity diagnostics to have false positives when TSan is enabled. To fix this, teach the AccessSummaryAnalysis to ignore TSan builtins when determining whether an access has a single projected subpath. rdar://problem/40455335
|
@swift-ci Please test |
|
@swift-ci please nominate Explanation: There is a false positive in the compile-time exclusivity diagnostics that manifests only when Thread Sanitizer is enabled. The exclusivity logic that detects when it is safe to have overlapping accesses to two different stored properties of the same struct gets confused by TSan's SIL-level instrumentation. This manifests as code that compiles without errors normally and only fails to build under TSan. The bug dates from the introduction of the separate-stored property exclusivity relaxation. However, it is a much bigger problem now that we're diagnosing more exclusivity violations as errors rather than warnings. |
The compile-time exclusivity diagnostics explicitly allow conflicting accesses
to a struct when it can prove that the two accesses are used to project addresses
for separate stored properties. Unfortunately, the logic that detects this special
case gets confused by Thread Sanitizer's SIL-level instrumentation. This causes
the exclusivity diagnostics to have false positives when TSan is enabled.
To fix this, teach the AccessSummaryAnalysis to ignore TSan builtins when
determining whether an access has a single projected subpath.
rdar://problem/40455335