Commit Graph

11 Commits

Author SHA1 Message Date
Douglas Gregor c197057b42 <rdar://problem/13605348> Don't consider invalid user-defined literal operators during overload resolution.
llvm-svn: 179150
2013-04-10 05:18:00 +00:00
Jordan Rose 7f43dddae0 Handle universal character names and Unicode characters outside of literals.
This is a missing piece for C99 conformance.

This patch handles UCNs by adding a '\\' case to LexTokenInternal and
LexIdentifier -- if we see a backslash, we tentatively try to read in a UCN.
If the UCN is not syntactically well-formed, we fall back to the old
treatment: a backslash followed by an identifier beginning with 'u' (or 'U').

Because the spelling of an identifier with UCNs still has the UCN in it, we
need to convert that to UTF-8 in Preprocessor::LookUpIdentifierInfo.

Of course, valid code that does *not* use UCNs will see only a very minimal
performance hit (checks after each identifier for non-ASCII characters,
checks when converting raw_identifiers to identifiers that they do not
contain UCNs, and checks when getting the spelling of an identifier that it
does not contain a UCN).

This patch also adds basic support for actual UTF-8 in the source. This is
treated almost exactly the same as UCNs except that we consider stray
Unicode characters to be mistakes and offer a fixit to remove them.

llvm-svn: 173369
2013-01-24 20:50:46 +00:00
Richard Smith 6f21206850 DR1473: Do not require a space between operator"" and the ud-suffix in a
literal-operator-id.

llvm-svn: 166373
2012-10-20 08:41:10 +00:00
Andy Gibbs c6e68daac0 Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
2012-10-19 12:44:48 +00:00
Richard Smith 5731c75414 PR12225: The requirement that literal operators be namespace-scope functions
does not imply that such functions can't be declared at block scope.

llvm-svn: 152509
2012-03-10 22:18:57 +00:00
Richard Smith c1b0565a26 Literal operator suffixes and regular names live in separate namespaces.
llvm-svn: 152395
2012-03-09 08:37:16 +00:00
Richard Smith 768ceccc75 Literal operators can't have default arguments.
llvm-svn: 152394
2012-03-09 08:16:22 +00:00
Richard Smith 0df56f4a90 Implement C++11 [lex.ext]p10 for string and character literals: a ud-suffix not
starting with an underscore is ill-formed.

Since this rule rejects programs that were using <inttypes.h>'s macros, recover
from this error by treating the ud-suffix as a separate preprocessing-token,
with a DefaultError ExtWarn. The approach of treating such cases as two tokens
is under discussion for standardization, but is in any case a conforming
extension and allows existing codebases to keep building while the committee
makes up its mind.

Reword the warning on the definition of literal operators not starting with
underscores (which are, strangely, legal) to more explicitly state that such
operators can't be called by literals. Remove the special-case diagnostic for
hexfloats, since it was both triggering in the wrong cases and incorrect.

llvm-svn: 152287
2012-03-08 02:39:21 +00:00
Richard Smith d67aea28f6 User-defined literals: reject string and character UDLs in all places where the
grammar requires a string-literal and not a user-defined-string-literal. The
two constructs are still represented by the same TokenKind, in order to prevent
a combinatorial explosion of different kinds of token. A flag on Token tracks
whether a ud-suffix is present, in order to prevent clients from needing to look
at the token's spelling.

llvm-svn: 152098
2012-03-06 03:21:47 +00:00
Richard Smith e18f0faff2 Lexing support for user-defined literals. Currently these lex as the same token
kinds as the underlying string literals, and we silently drop the ud-suffix;
those issues will be fixed by subsequent patches.

llvm-svn: 152012
2012-03-05 04:02:15 +00:00
Richard Smith 72eebee0cb Add tests for [over.literal]. Fix a few bugs which were exposed by the tests.
llvm-svn: 151997
2012-03-04 09:41:16 +00:00