- User Since
- Jul 12 2012, 2:19 PM (314 w, 4 h)
The way in which you're checking for the problematic cases is unnecessarily expensive. Instead of performing a separate AST traversal, please detect whether you should be producing the warning directly when forming the problematic expressions. (For example, you could store a list of pending "dereference of noderef" expressions in the ExpressionEvaluationContextRecord, remove items from the list if you find they're the operand of a unary address-of operator, and diagnose any remaining items once you've left the evaluation context.)
Tue, Jul 17
Mon, Jul 16
Fri, Jul 13
Thu, Jul 12
Wed, Jul 11
Tue, Jul 10
Mon, Jul 9
Sat, Jul 7
Can we avoid the duplication by putting this check in Sema::ParsedFreeStandingDeclSpec instead?
Fri, Jul 6
Thu, Jul 5
Tue, Jul 3
Looks fine, but please put the test case somewhere more appropriate (under SemaCXX, for instance).
Mon, Jul 2
Fri, Jun 29
Looks right to me (other than the missing constexpr in C++14 onwards). Though this is subtle enough that I suspect the only way to know for sure is to try it.
Thanks, I think this test needs a target triple to avoid the funny msvc
enum rules. I'm working on it.
Hmm, so this will mean that we can have internal linkage declarations marked Used for which there is no definition, and we need to not warn on that.
Thu, Jun 28
This is not specific to the ASTImporter; any change to the AST after a call to getParents would have similar problems. Generally, responsibility for dealing with this must lie with the consumer of the parent map, not with the ASTContext, since the ASTContext generally doesn't even know when the AST gets mutated.
I'm not 100% thrilled that we're emitting two warnings about the same thing for slightly different reasons; alternatives welcome. :)