Commit Graph

12 Commits

Author SHA1 Message Date
Richard Smith 560a3579b2 Update diagnostics now that hexadecimal literals look likely to be part of C++17.
llvm-svn: 262753
2016-03-04 22:32:06 +00:00
Richard Smith e87aeb378d When pretty-printing a C++11 literal operator, don't insert whitespace between
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.

llvm-svn: 249641
2015-10-08 00:17:59 +00:00
Alp Toker 6ed7251683 Revert "Don't require -re suffix on -verify directives with regexes."
This patch was submitted to the list for review and didn't receive a LGTM.

(In fact one explicit objection and one query were raised.)

This reverts commit r197295.

llvm-svn: 197299
2013-12-14 01:07:05 +00:00
Hans Wennborg 9b395ef284 Don't require -re suffix on -verify directives with regexes.
Differential Revision: http://llvm-reviews.chandlerc.com/D2392

llvm-svn: 197295
2013-12-14 00:46:53 +00:00
Hans Wennborg cda4b6dd00 Change semantics of regex expectations in the diagnostic verifier
Previously, a line like

  // expected-error-re {{foo}}

treats the entirety of foo as a regex. This is inconvenient when matching type
names containing regex characters. For example, to match
"void *(class test8::A::*)(void)" inside such a regex, one would have to type
"void \*\(class test8::A::\*\)\(void\)".

This patch changes the semantics of expected-error-re to only treat the parts
of the directive wrapped in double curly braces as regexes. This avoids the
escaping problem and leads to nicer patterns for those cases; see e.g. the
change to test/Sema/format-strings-scanf.c.

(The balanced search for closing }} of a directive also makes us handle the
full directive in test\SemaCXX\constexpr-printing.cpp:41 and :53.)

Differential Revision: http://llvm-reviews.chandlerc.com/D2388

llvm-svn: 197092
2013-12-11 23:40:50 +00:00
Richard Smith e6799ddae8 PR12717: Clang supports hexadecimal floating-point literals in all language
modes. For languages other than C99/C11, this isn't quite a conforming
extension, and for C++11, it breaks some reasonable code containing
user-defined literals.

In languages which don't officially have hexfloats, pare back this extension
to only apply in cases where the token starts 0x and does not contain an
underscore. The extension is still not quite conforming, but it's a lot closer
now.

llvm-svn: 158487
2012-06-15 05:07:49 +00:00
Aaron Ballman e1224a5067 Fixing hex floating literal support so that it handles 0x.2p2 properly.
llvm-svn: 150072
2012-02-08 13:36:33 +00:00
Aaron Ballman b97a5addd5 Hex literals without a significand no longer crash the lexer. Fixes bug 7910
Patch by Eitan Adler

llvm-svn: 149984
2012-02-07 13:46:03 +00:00
Douglas Gregor 227c352bae We do parse hexfloats in C++11; make it actually work.
llvm-svn: 141798
2011-10-12 18:51:02 +00:00
Benjamin Kramer 9aa0d39443 A bug I've introduced in STDIN handling surfaced a few broken tests, fix them.
Lexer/hexfloat.cpp is now XFAIL'd, I'd appreciate if someone could look into it.

llvm-svn: 106840
2010-06-25 12:48:07 +00:00
Chris Lattner fd8fb3c4cd Don't warn about use of hex floats in c++ mode by default,
matching G++'s behavior.

Warn when -pedantic or -Wc++-hex-floats is passed, and
don't warn if -pedantic -Wno-c++-hex-floats are both passed.

llvm-svn: 104295
2010-05-20 23:33:51 +00:00
Alexis Hunt 91b78382b5 Do not parse hexadecimal floating point literals in C++0x mode because they are
incompatible with user-defined literals, specifically with the following form:

  0x1p+1

The preprocessing-number token extends only as far as the 'p'; the '+' is not
included. Previously we could get away with this extension as p was an invalid
suffix, but now with user-defined literals, 'p' might well be a valid suffix
and we are forced to consider it as such.

This patch also adds a warning in non-0x C++ modes telling the user that
this extension is incompatible with C++0x that is enabled by default
(previously and with other languages, we warn only with a compliance
option such as -pedantic).

llvm-svn: 93135
2010-01-10 23:37:56 +00:00