| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. We would assume that the length of the string literal token was at least 2
2. We would allocate a buffer with size length-2
And when the stars aligned (one of which would be an invalid source location due to stale PCH)
The length would be 0 and we would try to allocate a 4GB buffer.
Add checks for this corner case and a bunch of asserts.
(We really really should have had an assert for 1.).
Note that there's no test case since I couldn't get one (it was major PITA to reproduce),
maybe later.
llvm-svn: 131492
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
|
|
|
|
|
|
|
|
| |
i64 is like LL
i32 is like L
Also set isMicrosoftInteger to true only if the suffix is well formed.
llvm-svn: 123230
|
|
|
|
|
|
| |
Patch by Paul Curtis!
llvm-svn: 120759
|
|
|
|
|
|
| |
related to.
llvm-svn: 119479
|
|
|
|
|
|
| |
possible to create one without a preprocessor.
llvm-svn: 119476
|
|
|
|
| |
llvm-svn: 119475
|
|
|
|
|
|
| |
Preprocessor to Lexer where they make more sense.
llvm-svn: 119474
|
|
|
|
| |
llvm-svn: 119472
|
|
|
|
| |
llvm-svn: 119471
|
|
|
|
| |
llvm-svn: 119470
|
|
|
|
| |
llvm-svn: 119469
|
|
|
|
|
|
| |
pushing the dependency on the preprocessor out a bit.
llvm-svn: 119468
|
|
|
|
|
|
| |
by Martin Vejnar!
llvm-svn: 116460
|
|
|
|
| |
llvm-svn: 116129
|
|
|
|
| |
llvm-svn: 115743
|
|
|
|
| |
llvm-svn: 112680
|
|
|
|
|
|
| |
in wide strings. radar 8360841.
llvm-svn: 112672
|