Commit Graph

8 Commits

Author SHA1 Message Date
Nico Weber 7607fce112 Don't mark record decls invalid when one of its methods is invalid, PR18284.
Without this patch, record decls with invalid out-of-line method delcs would
sometimes be marked invalid, but not always.  With this patch, they are
consistently never marked invalid.

(The code to do this was added in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100809/033154.html
, but the test from that revision is still passing.)

As far as I can tell, this was the only place where a class was marked invalid
after its definition was complete.

llvm-svn: 197848
2013-12-21 00:49:51 +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
David Majnemer 1365781b5b Sema: Don't assume a nested name specifier holds a type
Sema::PerformObjectMemberConversion assumed that the Qualifier it was
given holds a type. However, the specifier could hold just a namespace.
In this case, we should ignore the qualifier and not attempt to cast to
it.

llvm-svn: 187715
2013-08-05 04:53:41 +00:00
Kaelyn Uhrain 10413a46a0 Allow typo correction to try removing nested name specifiers.
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).

Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.

llvm-svn: 185487
2013-07-02 23:47:44 +00:00
Kaelyn Uhrain b18b0c0f16 Look for corrections in enclosing namespaces that require a global NestedNameSpecifier.
CorrectTypo will now see and consider those corrections that are effectively
shadowed by other declarations in a closer context when resolved via an
unqualified lookup. This involves adding any parent namespaces to the set of
namespaces as fully-qualified name specifiers, and also adding potential
corrections that passed name lookup but were rejected by the given
CorrectionCandidateCallback into the set of failed corrections that should be
tried with the set of namespace specifiers.

llvm-svn: 185486
2013-07-02 23:47:35 +00:00
Benjamin Kramer a2dcac1095 Fix PR13394: Erasing from a vector changes the end of the vector, so make sure we always have the right end.
llvm-svn: 160855
2012-07-27 10:21:08 +00:00