| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
failing to lex the string, as suggested by Eli.
Part of rdar://11305263.
llvm-svn: 156081
|
|
|
|
|
|
|
|
|
| |
not as we expect; it may be due to racing issue of a file coming from PCH
changing after the PCH is loaded.
rdar://11353109
llvm-svn: 156043
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
|
|
| |
basic source character set in C++98. Add -Wc++98-compat diagnostics for same in
literals in C++11. Extend such support to cover string literals as well as
character literals, and mark N2170 as done.
This seems too minor to warrant a release note to me. Let me know if you disagree.
llvm-svn: 152444
|
|
|
|
|
|
|
| |
first codepoint! Also, don't reject empty raw string literals for spurious
"encoding" issues. Also, don't rely on undefined behavior in ConvertUTF.c.
llvm-svn: 152344
|
|
|
|
|
|
|
| |
user-defined-floating-literal. Support for raw forms of these literals
to follow.
llvm-svn: 152302
|
|
|
|
| |
llvm-svn: 152277
|
|
|
|
|
|
|
| |
kinds as the underlying string literals, and we silently drop the ud-suffix;
those issues will be fixed by subsequent patches.
llvm-svn: 152012
|
|
|
|
|
|
| |
Downgrade error for non-wide character literals with an unexpected encoding to a warning for compatibility with gcc and older versions of clang. <rdar://problem/10837678>.
llvm-svn: 150295
|
|
|
|
| |
llvm-svn: 150072
|
|
|
|
|
|
| |
Patch by Eitan Adler
llvm-svn: 149984
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
|
|
| |
never are
llvm-svn: 148391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updates ProcessUCNExcape() for C++. C++11 allows UCNs in character
and string literals that represent control characters and basic
source characters. Also C++03 allows UCNs that refer to surrogate
codepoints.
UTF-8 sequences in character literals are now handled as single
c-chars.
Added error for multiple characters in Unicode character literals.
Added errors for when a the execution charset encoding of a c-char
cannot be represented as a single code unit in the associated
character type. Note that for the purposes of this error the asso-
ciated character type for a narrow character literal is char, not
int, even though in C narrow character literals have type int.
llvm-svn: 148389
|
|
|
|
| |
llvm-svn: 144521
|
|
|
|
| |
llvm-svn: 143769
|
|
|
|
|
|
| |
for string literal parsing. No functional change on little-endian architectures; should fix test failures on PPC.
llvm-svn: 143585
|
|
|
|
|
|
|
|
|
|
| |
(For now, we are assuming the source character set is always UTF-8; this can be easily extended if necessary.)
Tests will be coming up in a subsequent commit.
Patch by Seth Cantrell.
llvm-svn: 143416
|
|
|
|
| |
llvm-svn: 141798
|
|
|
|
|
|
|
|
| |
buffer as an 'unsigned char', so that integer promotion doesn't
sign-extend character values > 127 into oblivion. Fixes
<rdar://problem/10188919>.
llvm-svn: 140608
|
|
|
|
| |
llvm-svn: 140478
|
|
|
|
| |
llvm-svn: 140368
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
|
|
|
|
|
|
|
|
| |
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
|
|
|
|
| |
llvm-svn: 138031
|
|
|
|
| |
llvm-svn: 137430
|
|
|
|
| |
llvm-svn: 137301
|
|
|
|
| |
llvm-svn: 137298
|
|
|
|
| |
llvm-svn: 137039
|
|
|
|
| |
llvm-svn: 136210
|