| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186199
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix is.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
llvm-svn: 186185
|
|
|
|
|
|
|
|
|
| |
lookup in the surrounding context. Slightly rework how we handle friend
declarations to inherit the visibility of the prior declaration, rather
than setting a friend declaration to be visible whenever there was a prior
declaration.
llvm-svn: 186040
|
|
|
|
| |
llvm-svn: 185880
|
|
|
|
|
|
| |
avoid specifying the vector size unnecessarily.
llvm-svn: 185610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
namespaces to try for potential typo corrections.
llvm-svn: 184762
|
|
|
|
|
|
| |
This is needed to parse libstdc++ 4.7's type_traits, see PR13530.
llvm-svn: 184476
|
|
|
|
|
|
|
|
|
|
|
| |
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
llvm-svn: 181832
|
|
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|
|
|
|
|
|
| |
Per discussion in cfe-commits, asserting may be a better way than introducing a special test flag.
llvm-svn: 181073
|
|
|
|
|
|
|
|
| |
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
llvm-svn: 180789
|
|
|
|
|
|
| |
operators during overload resolution.
llvm-svn: 179150
|
|
|
|
|
|
| |
Fixes the bootstrap regression I introduced in r179067.
llvm-svn: 179079
|
|
|
|
|
|
|
|
|
|
|
|
| |
contexts not represented by scopes.
This fixes a regression I introduced in r178136, where we would not
consider the using directives from the semantic declaration contexts
that aren't represented by the lexical scopes (Scope) when performing
unqualified name lookup. This lead to horribly funny diagnostics like
"no identifier named 'foo'; did you mean 'foo'?".
llvm-svn: 179067
|
|
|
|
| |
llvm-svn: 179061
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declarations.
Normal name lookup ignores any hidden declarations. When name lookup
for builtin declarations fails, we just synthesize a new
declaration at the point of use. With modules, this could lead to
multiple declarations of the same builtin, if one came from a (hidden)
submodule that was later made visible. Teach name lookup to always
find builtin names, so we don't create these redundant declarations in
the first place.
llvm-svn: 178711
|
|
|
|
|
|
|
|
| |
smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.
llvm-svn: 178668
|
|
|
|
|
|
| |
unqualified name lookup into declarations contexts represented by the qualified-id but not in the actual scope hierarchy.
llvm-svn: 178136
|
|
|
|
|
|
|
| |
Thanks to Richard S. for pointing out that the warning would show up
with -Weverything.
llvm-svn: 177218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
llvm-svn: 177126
|
|
|
|
|
|
| |
No (intended) functionality change.
llvm-svn: 176726
|
|
|
|
|
|
|
|
|
| |
ignore invalid declarations.
This reduces the "ambiguous reference" errors (which are rather strange in C/ObjC) and fixes an assertion hit
with an invalid code test case.
llvm-svn: 175869
|
|
|
|
|
|
| |
-Wundefined-internal warnings with PCH.
llvm-svn: 173538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
llvm-svn: 172665
|
|
|
|
| |
llvm-svn: 172514
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.
llvm-svn: 169075
|
|
|
|
|
|
| |
expose only the iterators instead.
llvm-svn: 168770
|
|
|
|
|
|
| |
add some assertions. No functionality change.
llvm-svn: 168725
|
|
|
|
|
|
|
|
| |
getUnderlyingDecl()) so that derivatives of
CorrectionCandidateCallback::ValidateCandidate(...) don't have to worry
about being thrown by UsingDecls and such.
llvm-svn: 168317
|
|
|
|
|
|
| |
namespace.
llvm-svn: 166194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
|
|
|
|
|
|
|
|
|
|
|
| |
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
|
|
|
|
|
|
| |
longer needed after the unused Context member was removed in r164104.
llvm-svn: 164196
|
|
|
|
| |
llvm-svn: 162630
|
|
|
|
| |
llvm-svn: 162586
|
|
|
|
|
|
| |
sure we always have the right end.
llvm-svn: 160855
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
|
| |
constructor will be used for moving that object, in the computation of its
exception specification.
llvm-svn: 160417
|
|
|
|
|
|
|
| |
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
|
|
|
|
| |
llvm-svn: 158985
|
|
|
|
| |
llvm-svn: 158982
|
|
|
|
| |
llvm-svn: 158741
|
|
|
|
|
|
| |
typo-correction after a scope specifier.
llvm-svn: 158231
|
|
|
|
|
|
|
|
|
| |
are otherwise too short to try to correct.
The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.
llvm-svn: 158109
|