- User Since
- Jul 12 2012, 2:19 PM (357 w, 4 d)
Interesting. I think all of the new warnings in the test cases here are undesirable (they duplicate errors produced by the constant evaluator), but the removed warnings all look like improvements.
Sun, May 19
Sat, May 18
Fri, May 17
Thu, May 16
This implementation is accepted by the lowest supported versions of all of our supported compilers: https://godbolt.org/z/yZJDu3
The approach we've been taking for this up until now is to use a ConstantExpr node to mark the entry point of a constant context; it looks like that would continue to work here, but we're missing those nodes in some cases? (This is preferable to using a flag because it also -- eventually -- gives us a place to store the evaluated value, which we're going to need for various upcoming features, particularly consteval.)
LGTM, thank you! :)
Wed, May 15
I expect we'll want a ContainsErrors bit on Stmt, propagated similarly to the existing InstantiationDependent / ContainsUnexpandedParameterPack / ... bits. For example, the constant evaluator will want to quickly bail out of evaluating expressions and statements containing errors, and the error recovery TreeTransform that we perform to fix typos will want that too (and maybe could be able to fix other kinds of errors for which we build these error nodes eventually?).
Generally, I think this is a good, useful feature, but there's one point from http://clang.llvm.org/get_involved.html 's checklist for accepting language extensions on which its case is weak, as reflected by this feedback from @alexr on D17741:
I don't think we want to add a fundamental new preprocessor feature like __FILE_BASENAME__ without at least getting some early buy-in from the WG14 and WG21 committees.
Tue, May 14
Thanks for working on this!
Mon, May 13
The problem may well be that you're recursively triggering deserialization of the std namespace from its own deserialization.
Thinking about this some more: distinguishing between "macro expansion" and other cases seems like a proxy for "this token came from inside the preprocessor / lexer" versus "this token was provided by the user", which is also exactly what IsNewToken is supposed to capture. I don't think we need two separate flags here.
Yeah, this seems to match the library wording. (I think it's short-sighted and over-fitting -- this is baking into the library specification that the language happens to not allow unions to have base classes today -- but this isn't the venue for that discussion.)
Sun, May 12
Fri, May 10
If I understand correctly, you want to be able to compile a program against some struct and union layouts, and then at load time "update" the program to cope with the actual layouts for those types being something else, but containing (at least) the set of members you know about. And your proposed approach is to add intrinsics into the IR that identify the GEPs that we emitted to model struct field accesses, but to otherwise not change the emitted IR. If so, I don't see how this approach to that problem can work. There seem to be a couple of problems:
Thu, May 9
Wed, May 8
Remove unneeded test change.