The sanitizers whose supported set of platforms I am sure of are now diagnosed
if enabled explicitly on an unsupported platform. Unsupported sanitizers which
are enabled implicitly (as part of a larger group) are silently disabled. As a
side effect, this makes SanitizerArgs parsing toolchain-dependent (and thus
essentially reverts r188058), and moves SanitizerArgs ownership to ToolChain.
Details
Diff Detail
Event Timeline
+Richard, who reviewed the original patch
I support this change.
include/clang/Driver/SanitizerArgs.h | ||
---|---|---|
119 ↗ | (On Diff #5068) | Can you add a comment for these functions? |
lib/Driver/SanitizerArgs.cpp | ||
232 ↗ | (On Diff #5068) | This part: if (Kinds & Foo) { Kinds &= ~Foo; <...> } can be factored out into a separate function. |
Yes, moving ownership of the SanitizerArgs from Driver to ToolChain makes sense to me; the latter is parameterized by a set of command-line arguments, the former is not. I also support this change =)
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
231 ↗ | (On Diff #5089) | Do an early return here instead. |
245 ↗ | (On Diff #5089) | -fsanitize=thread is also unsupported in this case. |
lib/Driver/ToolChains.cpp | ||
300 ↗ | (On Diff #5089) | Can you move this piece to filterUnsupportedKinds? |
314 ↗ | (On Diff #5089) | Can you move this piece to filterUnsupportedKinds? |
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
231 ↗ | (On Diff #5089) | Done. |
245 ↗ | (On Diff #5089) | Added. |
lib/Driver/ToolChains.cpp | ||
300 ↗ | (On Diff #5089) | I think so. The logic behind isTargetIPhoneOS() and isTargetIOSSimulator() is in Darwin::AddDeploymentTarget and is rather more complex than my translation (e.g. it checks certain flags). This branch was untested though, so I'm inclined to change the logic and let Apple folks fix this if it causes a problem. |
314 ↗ | (On Diff #5089) | Likewise. |
lib/Driver/ToolChains.cpp | ||
---|---|---|
300 ↗ | (On Diff #5089) | The reason behind the check for "isTargetIPhoneOS() && !isTargetIOSSimulator()" in ASan (added by me) was to prevent people from trying ASan on the real iOS devices where it doesn't work, but let them use ASan for iossim builds. |
include/clang/Basic/DiagnosticDriverKinds.td | ||
---|---|---|
66 ↗ | (On Diff #5116) | separate commit? |
include/clang/Driver/SanitizerArgs.h | ||
136 ↗ | (On Diff #5116) | Kind is actually a Mask. There is no FlagName parameter. Consider fixing parameter names and comment. |
lib/Driver/SanitizerArgs.cpp | ||
50 ↗ | (On Diff #5116) | please remove blank lines in added block |
235 ↗ | (On Diff #5116) | ditto |
249 ↗ | (On Diff #5116) | I'd appreciate booleans like "IsLinux", "IsX86" etc. for brevity. |
261 ↗ | (On Diff #5116) | Make sure you agree with glider@ on this part. I think it would be fine to revert this piece to get the patch committed, leave a FIXME, and deal with/refactor this part later. |
- Address reviewer comments
include/clang/Basic/DiagnosticDriverKinds.td | ||
---|---|---|
66 ↗ | (On Diff #5116) | Yeah, this would go with whichever commit removes the isTargetIOS checks. |
include/clang/Driver/SanitizerArgs.h | ||
136 ↗ | (On Diff #5116) | Updated. |
lib/Driver/SanitizerArgs.cpp | ||
50 ↗ | (On Diff #5116) | Done. |
235 ↗ | (On Diff #5116) | Done. |
249 ↗ | (On Diff #5116) | Done. |
261 ↗ | (On Diff #5116) | After investigating how Xcode builds iOS stuff on Darwin I think I've come to the conclusion that the driver sees the wrong triple, so my change wouldn't work. Reverted to be dealt with later. |
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
47–52 ↗ | (On Diff #5139) | If I say: clang -target triple -fsanitize=foo,bar -fno-sanitize=bar and bar is not supported on triple, I don't think we should diagnose it. |
- Avoid diagnosing unsupported sanitizers which are added then removed
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
47–52 ↗ | (On Diff #5139) | Agree, done. |
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
56 ↗ | (On Diff #5142) | Hmm, should we mask out AllAdd here too? We don't want to issue two diagnostics for -fsanitize=bad -fsanitize=bad. But on the other hand diagnosing -fsanitize=bad -fsanitize=group-including-bad might be nice. Ugh. Maybe what we want is a limit of one diagnostic per problem? |
132–135 ↗ | (On Diff #5142) | This looks a bit strange. We won't diagnose -fsanitize=address -fno-sanitize=address -fsanitize=init-order Following the principle of later arguments overriding earlier ones, I would have expected a diagnostic for that, but not for: -fsanitize=address -fsanitize=init-order -fno-sanitize=address Seems to be a pre-existing oddness, though. |
- Address review comments
lib/Driver/SanitizerArgs.cpp | ||
---|---|---|
56 ↗ | (On Diff #5142) | Yes, masking out AllAdd doesn't seem like it will work trivially. Deduplicating in filterUnsupportedMask by accumulating a mask of diagnosed kinds seems to work, although (as the new test shows) we don't give the best diagnostics in the world sometimes. |
132–135 ↗ | (On Diff #5142) | *shrug* I'll let Alexey comment on this, as he introduced this behavior in r173670. |