| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
place.
Fixes radar 7284618.
llvm-svn: 93382
|
|
|
|
|
|
| |
code-completion's ResultBuilder::MaybeAddResult for later reuse.
llvm-svn: 93379
|
|
|
|
| |
llvm-svn: 93378
|
|
|
|
| |
llvm-svn: 93377
|
|
|
|
|
|
| |
are no longer using it for anything. No intended functionality change.
llvm-svn: 93376
|
|
|
|
|
|
|
|
| |
the "typed" text, first, then take into account
nested-name-specifiers, name hiding, etc. This means that the
resulting sort is actually alphabetical :)
llvm-svn: 93370
|
|
|
|
|
|
|
|
|
|
|
|
| |
to be considering user-defined conversions in the first place.
Doug, please review; I'm not sure what we should be doing if we see a real
ambiguity in selecting a copy constructor when otherwise suppressing
user-defined conversions.
Fixes PR6014.
llvm-svn: 93365
|
|
|
|
| |
llvm-svn: 93362
|
|
|
|
| |
llvm-svn: 93361
|
|
|
|
|
|
| |
constructor. Fixes radar 7537770.
llvm-svn: 93358
|
|
|
|
|
|
|
|
|
|
|
| |
provide completions for @ keywords. Previously, we only provided
@-completions after an @ was actually typed, which is useful but
probably not the common case.
Also, make sure a few Objective-C 2.0 completions only show up when
Objective-C 2.0 support is enabled (the default).
llvm-svn: 93354
|
|
|
|
|
|
| |
yet used.
llvm-svn: 93345
|
|
|
|
|
|
| |
Patch by Enea Zaffanella.
llvm-svn: 93344
|
|
|
|
|
|
| |
rewriting for any target. (refixes radar 7530235).
llvm-svn: 93331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.
Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.
Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between
C(int); // constructor
and
C (f)(int); // member function
which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:
C::C C::f(int); // error: C::C refers to the constructor name, but
// we complain nicely and recover by treating it as
// a type.
llvm-svn: 93322
|
|
|
|
|
|
|
| |
information to feed diagnostics instead of regenerating it. Much room for
improvement here, but fixes some unfortunate problems reporting on method calls.
llvm-svn: 93316
|
|
|
|
|
|
|
| |
This now rejects literal operators that don't meet the requirements.
Templates are not yet checked for.
llvm-svn: 93315
|
|
|
|
|
|
|
| |
disabled with the intent that users can start with them now and not have to change
a thing to have them work when we implement the features.
llvm-svn: 93312
|
|
|
|
| |
llvm-svn: 93288
|
|
|
|
| |
llvm-svn: 93287
|
|
|
|
|
|
|
|
| |
clang -cc1 logic for running an action against a set of options.
- This should make it easier to build tools that have a clang -cc1 like
interface, but aren't actually part of clang -cc1.
llvm-svn: 93282
|
|
|
|
|
|
|
|
| |
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
|
|
|
|
|
|
|
| |
redefined. There's a FIXME with an apology about why we don't try to
do better here. Fixes <rdar://problem/7513023>.
llvm-svn: 93274
|
|
|
|
|
|
| |
ivar name lookup. Fixes pr5986.
llvm-svn: 93271
|
|
|
|
|
|
|
|
|
|
| |
unevaluated contexts, because they only matter for code that will
actually be evaluated at runtime.
As part of this, I had to extend PartialDiagnostic to support fix-it
hints.
llvm-svn: 93266
|
|
|
|
|
|
| |
not in an evaluated context. This removes some bogus warnings.
llvm-svn: 93258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:
test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
^
template
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
^
2 diagnostics generated.
llvm-svn: 93257
|
|
|
|
| |
llvm-svn: 93256
|
|
|
|
| |
llvm-svn: 93255
|
|
|
|
|
|
|
| |
correctly look through arrays to see cv-qualifiers. Also enhances the routine
for doing this to preserve more type sugaring for diagnostics.
llvm-svn: 93252
|
|
|
|
|
|
| |
win32 targets. Fixes radar 7530235. Daniel please review.
llvm-svn: 93246
|
|
|
|
|
|
|
|
|
| |
initializers. This isn't actually in the C++ grammar (in any version),
but that's clearly an oversight: both GCC and EDG support this syntax,
and it's used within Boost code. I'll file a core issue proposing
precisely the change made here. Fixes PR6008.
llvm-svn: 93243
|
|
|
|
|
|
| |
during rewrite. No functionality chang.
llvm-svn: 93241
|
|
|
|
|
|
|
|
| |
context, do not attempt typo correction. This harms performance (as
Abramo noted) and can cause some amusing errors, as in this new
testcase.
llvm-svn: 93240
|
|
|
|
|
|
|
|
| |
I said to myself, self, why don't you go add a couple of parameters to a method
and then fail to use them, and I thought that sounded like a pretty good idea,
so I did it.
llvm-svn: 93233
|
|
|
|
|
|
| |
embedding single space characters. <rdar://problem/7485503>
llvm-svn: 93231
|
|
|
|
|
|
|
| |
fidelity with which we note them as functions/constructors and templates
thereof. Also will be helpful when reporting bad conversions (next).
llvm-svn: 93224
|
|
|
|
|
|
| |
Fixes radar 7522880.
llvm-svn: 93219
|
|
|
|
| |
llvm-svn: 93217
|
|
|
|
| |
llvm-svn: 93215
|
|
|
|
|
|
|
| |
sequence. Lots of small relevant changes. Fixes some serious problems with
ambiguous conversions; also possibly improves associated diagnostics.
llvm-svn: 93214
|
|
|
|
|
|
|
|
|
|
| |
were performing name lookup for template names in C/ObjC and always
finding nothing. Turn off such lookup unless we're in C++ mode, along
with the check that determines whether the given identifier is a
"current class name", and assert that we don't make this mistake
again.
llvm-svn: 93207
|
|
|
|
| |
llvm-svn: 93205
|
|
|
|
|
|
| |
(fixes radar 6969189).
llvm-svn: 93201
|
|
|
|
|
|
| |
non-NULL before looking at the entity itself.
llvm-svn: 93199
|
|
|
|
|
|
| |
compile LanguageKit, although the resulting code crashes (although not in any of the functions that use VLAs).
llvm-svn: 93198
|
|
|
|
|
|
|
| |
is not also a typedef-name" actually means. For anyone keeping score,
that's John: 2, Doug: 0.
llvm-svn: 93196
|
|
|
|
|
|
|
| |
latter may (eventually) perform multiple levels of desugaring (thus
breaking the newly-added tests) and the former is faster. Thanks, John!
llvm-svn: 93192
|
|
|
|
|
|
|
|
|
| |
they redefine is a class-name but not a typedef-name, per C++0x
[dcl.typedef]p4. The code in the test was valid C++98 and is valid
C++0x, but an unintended consequence of DR56 made it ill-formed in
C++03 (which we were luck enough to implement). Fixes PR5455.
llvm-svn: 93188
|
|
|
|
|
|
| |
(fixes radar 6948022)
llvm-svn: 93186
|