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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243243 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233491 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233490 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211441 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211434 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211426 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209468 91177308-0d34-0410-b5e6-96231b3b80d8
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...
=)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206932 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191274 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186903 91177308-0d34-0410-b5e6-96231b3b80d8
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174768 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, we can't accept the UCN as an extension because we're
required to treat it as two tokens for preprocessing purposes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173622 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164639 91177308-0d34-0410-b5e6-96231b3b80d8
It does a conservative estimate on the size of numbers that can fit into
uint64_t. This bound is improved.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164624 91177308-0d34-0410-b5e6-96231b3b80d8
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164484 91177308-0d34-0410-b5e6-96231b3b80d8
string literal, produce a diagnostic pointing at the erroneous character
range, not at the start of the literal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163459 91177308-0d34-0410-b5e6-96231b3b80d8
David Majnemer