| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For input `0'e+1` lexer tokenized as numeric constant only `0'e`. Later
NumericLiteralParser skipped 0 and ' as digits and parsed `e+1` as valid
exponent going past the end of the token. Because it didn't mark numeric
literal as having an error, it continued parsing and tried to expandUCNs
with StringRef of length -2.
The fix is not to parse exponent when we reached the end of token.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588
rdar://problem/36076719
Reviewers: rsmith, t.p.northover
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple
Differential Revision: https://reviews.llvm.org/D41834
llvm-svn: 324419
|
|
|
|
|
|
| |
C++17.
llvm-svn: 262753
|
|
|
|
|
|
| |
of digit separators.
llvm-svn: 260307
|
|
|
|
|
|
|
|
| |
digits. Turns out we have completely separate lexing codepaths for floating
point numbers depending on whether or not they start with a zero. Who knew...
=)
llvm-svn: 206932
|
|
|
|
| |
llvm-svn: 202534
|
|
|
|
|
|
| |
contains "'e+", the pp-number ends between the 'e' and the '+'.
llvm-svn: 202533
|
|
|
|
| |
llvm-svn: 191444
|
|
|
|
|
|
| |
in a #line directive.
llvm-svn: 191443
|
|
yet approved by full committee, but was unanimously supported by EWG.
llvm-svn: 191417
|