- Adding attribute((no_uninitialized_checks))
- Mapping attribute((no_uninitialized_checks)) to llvm::Attribute::UninitializedChecks (under MSAN)
- Mapping attribute((no_thread_safety_analysis)) llvm::Attribute::ThreadSafety (under TSAN)
- Updating Docs & Tests
Details
Diff Detail
Event Timeline
lib/Sema/SemaDeclAttr.cpp | ||
---|---|---|
655–656 | Can we promote this to an error? There's no existing code that (mis)uses this attribute, so there should be no compatibility concerns. Please also add tests for this warning or error, and for checkAttributeNumArgs() condition above. |
lib/Sema/SemaDeclAttr.cpp | ||
---|---|---|
655–656 | I copy-pasted the code from the pre-existing code for no_thread_safety_analysis Yes, I guess we can make it an error. Will do the change tomorrow. |
lib/Sema/SemaDeclAttr.cpp | ||
---|---|---|
655–656 | There are tests for no_address_safety_analysis in test/SemaCXX/warn-thread-safety-parsing.cpp (lines 93-121). For this attribute, tests should probably go into test/SemaCXX/attr-no-uninitialized-checks.cpp (because we don't do static analysis, it is attr- instead of warn-). |
Promoted warnings to errors for no_uninitialized_checks and no_address_safety_analysis and added tests
Feel free to submit as-is to get bots green and make progress. See comments below -- we should discuss those separately. I'll try to send a cfe-dev email when I can?
docs/LanguageExtensions.rst | ||
---|---|---|
1609 | I actually find it really unfortunate that this attribute and the -Wthread-safety escape hatch attribute are the same. I suspect there are many scenarios where users can't accomodate the reduced programming model checked by -Wthread-safety, use this attribute to escape that analysis, and would still like TSan to point out the actual races. Thoughts? | |
docs/MemorySanitizer.rst | ||
83 | I think we should aim for more consistency across the attribute names. I think that will benefit users more than anything else... Is there a reason not to tie these to the 'sanitize' naming scheme? |
Feel free to submit as-is to get bots green and make progress. See comments below -- we should discuss those separately. I'll >> try to send a cfe-dev email when I can?
I'd better commit the final thing. Bots are not a problem, I'll disable the only failing test for now.
I actually find it really unfortunate that this attribute and the -Wthread-safety escape hatch attribute are the same. I suspect there >> are many scenarios where users can't accomodate the reduced programming model checked by -Wthread-safety, use this ?
attribute to escape that analysis, and would still like TSan to point out the actual races.
Thoughts?
There are pros and cons here.
If we add yet another attribute to disable tsan we will have two.
Users will be confused. They will be adding one instead of another.
But yes, we will lose finer granularity.
I slightly prefer to to have one attribute here rather than two, but I am open to other suggestions.
I think we should aim for more consistency across the attribute names. I think that will benefit users more than anything else...
Is there a reason not to tie these to the 'sanitize' naming scheme?
Will we have to rename the existing no_address_safety_analysis then?
That's not trivial given that gcc already uses it too.
Also, the idea behind these attributes was that we don't tie them to particular tools.
I actually find it really unfortunate that this attribute and the -Wthread-safety escape hatch attribute are the same. I suspect there are many scenarios where users can't accomodate the reduced programming model checked by -Wthread-safety, use this attribute to escape that analysis, and would still like TSan to point out the actual races.
Thoughts?