-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Fix 11438 and 10807: categorize user defined literal as literal instead of number #4701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
4986637
69b786d
3b8c088
2eac468
6bd09b5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -638,7 +638,7 @@ class TestToken : public TestFixture { | |
| givenACodeSampleToTokenize nonNumeric("abc", true); | ||
| ASSERT_EQUALS(false, Token::Match(nonNumeric.tokens(), "%num%")); | ||
|
|
||
| givenACodeSampleToTokenize binary("101010b", true); | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't know in what context I've rewritten them to valid C++ integers
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think 101010b is used in inline assembler. |
||
| givenACodeSampleToTokenize binary("0b101010", true); | ||
| ASSERT_EQUALS(true, Token::Match(binary.tokens(), "%num%")); | ||
|
|
||
| givenACodeSampleToTokenize octal("0123", true); | ||
|
|
@@ -653,7 +653,7 @@ class TestToken : public TestFixture { | |
| givenACodeSampleToTokenize floatingPoint("0.0f", true); | ||
| ASSERT_EQUALS(true, Token::Match(floatingPoint.tokens(), "%num%")); | ||
|
|
||
| givenACodeSampleToTokenize doublePrecision("0.0d", true); | ||
| givenACodeSampleToTokenize doublePrecision("0.0", true); | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do not know where 0.0d comes from. I don't want to immediately say if we need that or not.
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems to come from this commit: acad87c And I don't see why that was added it could be by mistake. I guess we can remove |
||
| ASSERT_EQUALS(true, Token::Match(doublePrecision.tokens(), "%num%")); | ||
|
|
||
| givenACodeSampleToTokenize signedLong("0L", true); | ||
|
|
@@ -685,6 +685,12 @@ class TestToken : public TestFixture { | |
|
|
||
| givenACodeSampleToTokenize positiveNull("+.0", true); | ||
| ASSERT_EQUALS(true, Token::Match(positiveNull.tokens(), "+ %num%")); | ||
|
|
||
| givenACodeSampleToTokenize decimalSeparated("123'456'678", true); | ||
| ASSERT_EQUALS(true, Token::Match(decimalSeparated.tokens(), "%num%")); | ||
|
|
||
| givenACodeSampleToTokenize userDefinedLiteral("123_udl", true); | ||
| ASSERT_EQUALS(false, Token::Match(userDefinedLiteral.tokens(), "%num%")); | ||
| } | ||
|
|
||
|
|
||
|
|
@@ -950,6 +956,12 @@ class TestToken : public TestFixture { | |
| ASSERT(tok.tokType() == Token::eBoolean); | ||
| tok.str("false"); | ||
| ASSERT(tok.tokType() == Token::eBoolean); | ||
| tok.str("\"foo\"_userDefinedLiteral"); | ||
| ASSERT(tok.tokType() == Token::eOther); // should be eLiteral | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. User defined string literals are still not properly processed, but this seems a lot harder to (properly) accomplish.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please use |
||
| tok.str("123_userDefinedLiteral"); | ||
| ASSERT(tok.tokType() == Token::eLiteral); | ||
| tok.str("0x123._userDefinedLiteral"); | ||
| ASSERT(tok.tokType() == Token::eLiteral); | ||
| } | ||
|
|
||
| void isStandardType() const { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unit tests pointed me here:
12his valid asm (12 in hex), but it is not a valid C++ int. So after my changes, this is seen as a literal. Therefore this changeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to allow and handle
12hand101010buntilTokenizer::simplifyAsm()is executed. The checks should not see such tokens at all. My guess is that it doesn't matter if they are number or literal..There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like we need more tests for ASM blocks.