| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93353
|
| |
|
|
| |
llvm-svn: 93348
|
| |
|
|
| |
llvm-svn: 93347
|
| |
|
|
| |
llvm-svn: 93346
|
| |
|
|
| |
llvm-svn: 93340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93314
|
| |
|
|
|
|
|
| |
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: 93287
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93260
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93238
|
| |
|
|
|
|
| |
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: 93216
|
| |
|
|
|
|
|
| |
sequence. Lots of small relevant changes. Fixes some serious problems with
ambiguous conversions; also possibly improves associated diagnostics.
llvm-svn: 93214
|
| |
|
|
|
|
| |
(fixes radar 6969189).
llvm-svn: 93201
|
| |
|
|
|
|
| |
non-NULL before looking at the entity itself.
llvm-svn: 93199
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 93190
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
function, be sure to adjust the resulting argument type to a pointer
(if necessary). Fixes PR5910 and PR5949.
llvm-svn: 93178
|
| |
|
|
| |
llvm-svn: 93177
|
| |
|
|
|
|
| |
for all visible conversion functions.
llvm-svn: 93173
|
| |
|
|
|
|
|
| |
say either "array type" or "function type", whichever it is. No reason
to make the user guess.
llvm-svn: 93164
|
| |
|
|
|
|
| |
in a function. Fixes radar 7522803.
llvm-svn: 93159
|
| |
|
|
|
|
| |
function. Fixes PR5985.
llvm-svn: 93150
|
| |
|
|
|
|
| |
The old test case has a little mistake.
llvm-svn: 93148
|
| |
|
|
|
|
| |
This with previous patch fixes a OSAtomic test case.
llvm-svn: 93146
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
value bindings. Along with a small change to OSAtomicChecker, this
resolves <rdar://problem/7527292> and resolves some long-standing
issues with how values can be bound to the same physical address by
not have the same "key". This change is only a beginning; logically
RegionStore needs to better handle loads from addresses where the
stored value is larger/smaller/different type than the loaded value.
We handle these cases in an approximate fashion now (via
CastRetrievedVal and help in SimpleSValuator), but it could be made
much smarter.
llvm-svn: 93137
|