Fixed incompatibility in lexer with MSVC for a wide string literal from L#macro_arg in a function-like macro
Details
Diff Detail
Event Timeline
| include/clang/Lex/Token.h | ||
|---|---|---|
| 69 | Can we make this unsigned short instead? | |
| 268 | is formed by macro | |
| lib/Lex/TokenLexer.cpp | ||
| 449 | processing | |
| 450 | References to bug reports shouldn't be in the source code. Instead, I'd have a description of what the special logic is trying to accomplish. | |
| 451–453 | This if is getting pretty gnarly, maybe it would be a little cleaner if you broke this logic up a little bit. | |
Can we get rid of our kw_L__FUNCTION__ hack with this change?
| lib/Lex/TokenLexer.cpp | ||
|---|---|---|
| 532–533 | What's the rationale behind this change? | |
| lib/Lex/TokenLexer.cpp | ||
|---|---|---|
| 532–533 | In construct L#x we don't have ## that should be skipped. So I just check it and skip this ## only if it exists. | |
Can we get rid of our kw_L__FUNCTION__ hack with this change?
No, I don't think we can. My solution fixes only lexer, but when we building LFUNCTION we're building an expression.
Best regards,
Alexey Bataev
Software Engineer
Intel Compiler Team
12.12.2014 7:39, David Majnemer пишет:
Can we get rid of our kw_L__FUNCTION__ hack with this change?
Comment at: lib/Lex/TokenLexer.cpp:524
@@ -515,2 +523,3 @@PasteOpLoc = Tokens[CurToken].getLocation();
- ++CurToken;
+ if (Tokens[CurToken].is(tok::hashhash))
+ ++CurToken;
What's the rationale behind this change?
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
lgtm
| include/clang/Lex/Token.h | ||
|---|---|---|
| 69 | OK, I guess either way there is no overall size increase. We could probably pack Kind and Flags more tightly, but that's separable. | |
| lib/Lex/TokenLexer.cpp | ||
| 410 | The convention for functions uses a leading lower case. | |
| 448–454 | Let's rearrange this to check the Macro bool first so we can short-circuit out with the least amount of work. | |
Can we make this unsigned short instead?