| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Our string literal parser copied any source-file new-line characters
into the execution string-literal. This is incorrect if the source-file
new-line character was a \r\n sequence because new-line characters are
merely \n.
llvm-svn: 248392
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is currently no support in MSVC for using i128 as an integer
literal suffix. In fact, there appears to be no evidence that they have
ever supported this feature in any of their compilers. This was an over
generalization of their actual feature and is a nasty source of bugs.
Why is it a source of bugs? Because most code in clang expects that
evaluation of an integer constant expression won't give them something
that 'long long' can't represent. Instead of providing a meaningful
feature, i128 gives us cute ways of exploding the compiler.
llvm-svn: 243243
|
|
|
|
|
|
|
|
|
| |
While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.
Found by asan and with a little help from clang-fuzz.
llvm-svn: 233491
|
|
|
|
|
|
|
| |
We know that the last accessible char is not in [a-zA-Z0-9_.] so we can
happily scan on as long as it is. No functionality change.
llvm-svn: 233490
|
|
|
|
| |
llvm-svn: 233006
|
|
|
|
|
|
|
|
|
|
| |
Simplify boolean expressions using `true` and `false` with `clang-tidy`
Patch by Richard Thomson.
Differential Revision: http://reviews.llvm.org/D8531
llvm-svn: 232999
|
|
|
|
| |
llvm-svn: 221576
|
|
|
|
|
|
| |
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
|
|
|
|
|
|
| |
and count.
llvm-svn: 211763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
|
|
|
|
|
|
|
|
|
| |
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
|
|
|
|
|
|
|
|
|
|
|
|
| |
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The limits on the number of fix-it hints and ranges attached to a
diagnostic are arbitrary and don't apply universally to all users of the
DiagnosticsEngine. The way the limits are enforced may lead to diagnostics
generating invalid sets of fixes. I suggest removing the limits, which will also
simplify the implementation.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3879
llvm-svn: 209468
|
|
|
|
| |
llvm-svn: 209083
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
operator==
llvm-svn: 203373
|
|
|
|
| |
llvm-svn: 201532
|
|
|
|
|
|
|
|
| |
miscompilation.
Investigating yet. It seems msc16 miscompiles s[1] to be folded.
llvm-svn: 191485
|
|
|
|
| |
llvm-svn: 191424
|
|
|
|
|
|
| |
Dennett.
llvm-svn: 191420
|
|
|
|
|
|
| |
yet approved by full committee, but was unanimously supported by EWG.
llvm-svn: 191417
|
|
|
|
|
|
|
|
| |
literal operators. Also, for now, allow the proposed C++1y "il", "i", and "if"
suffixes too. (Will revert the latter if LWG decides not to go ahead with that
change after all.)
llvm-svn: 191274
|
|
|
|
|
|
| |
Patch by Eelis van der Weegen.
llvm-svn: 190971
|
|
|
|
|
|
| |
literals.
llvm-svn: 188918
|
|
|
|
|
|
| |
escape code.
llvm-svn: 188863
|
|
|
|
|
|
| |
fix a typo in a comment.
llvm-svn: 188857
|
|
|
|
|
|
|
| |
* Allow ns, us, ms, s, min, h as numeric ud-suffixes
* Allow s as string ud-suffix
llvm-svn: 186933
|
|
|
|
|
|
|
|
| |
Switch some warnings over to errors which should never have been warnings
in the first place. (Also, a minor fix to the preprocessor rules for
integer literals while I'm here.)
llvm-svn: 186903
|
|
|
|
|
|
| |
C++1y binary literals.
llvm-svn: 179883
|
|
|
|
|
|
|
| |
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
llvm-svn: 174768
|
|
|
|
|
|
| |
This is required to use them in TableGen.
llvm-svn: 173924
|
|
|
|
|
|
|
| |
Unfortunately, we can't accept the UCN as an extension because we're
required to treat it as two tokens for preprocessing purposes.
llvm-svn: 173622
|
|
|
|
| |
llvm-svn: 173368
|
|
|
|
| |
llvm-svn: 172861
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
|
| |
string parts.
Instead just use a dummy buffer, we're not going to use the decoded string anyways.
Fixes PR14292.
llvm-svn: 167594
|
|
|
|
| |
llvm-svn: 167593
|
|
|
|
| |
llvm-svn: 167059
|
|
|
|
|
|
|
| |
limit highlight to exactly the bad encoding, and highlight every
bad encoding in a string.
llvm-svn: 166900
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the behavior clearer concerning literals with the maximum
number of digits. For a 32-bit example, 4,000,000,000 is a valid uint32_t,
but 5,000,000,000 is not, so we'd have to count 10-digit decimal numbers
as "unsafe" (meaning we have to check for overflow when parsing them,
just as we would for numbers with 11 digits or higher). This is the same,
only with 64 bits to play with.
No functionality change.
llvm-svn: 164639
|
|
|
|
|
|
|
| |
It does a conservative estimate on the size of numbers that can fit into
uint64_t. This bound is improved.
llvm-svn: 164624
|
|
|
|
|
|
|
| |
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
llvm-svn: 164484
|
|
|
|
|
|
|
| |
string literal, produce a diagnostic pointing at the erroneous character
range, not at the start of the literal.
llvm-svn: 163459
|
|
|
|
| |
llvm-svn: 159634
|
|
|
|
| |
llvm-svn: 158740
|
|
|
|
|
|
| |
formatting of Doxygen's output for StringLiteralParser::StringLiteralParser.
llvm-svn: 158616
|
|
|
|
|
|
| |
for U+FFFF.
llvm-svn: 158391
|
|
|
|
|
|
| |
escape sequences.
llvm-svn: 158390
|