Age | Commit message (Collapse) | Author |
|
the bug where array elements and member initializers weren't copied correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94340 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94335 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94334 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94332 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initialization code. Pass an InitializedEntity pointer through to most init checker functions. Right now, it's ignored everywhere except when initializing vectors in C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94325 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sema::PerformCopyInitialization overload.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94324 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94316 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arrays and vectors are pretty different beasts in C++. Doug, please review/comment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
correctly look through arrays to see cv-qualifiers. Also enhances the routine
for doing this to preserve more type sugaring for diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93252 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93233 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sequence. Lots of small relevant changes. Fixes some serious problems with
ambiguous conversions; also possibly improves associated diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93214 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not just the viable ones. This is reasonable because the most common use of
deleted functions is to exclude some implicit conversion during calls; users
therefore will want to figure out why some other options were excluded.
Started sorting overload results. Right now it just sorts by location in the
translation unit (after putting viable functions first), but we can do better than
that.
Changed bool OnlyViable parameter to PrintOverloadCandidates to an enum for better
self-documentation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92990 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointing to the declaration that we found that has that name (if it is
unique).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ASTContext. Fixes <rdar://problem/7495428>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
test/FixIt/typo.c:19:4: error: field designator 'bunds' does not refer to any
field in type 'struct Window'; did you mean 'bounds'?
.bunds.
^~~~~
bounds
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92376 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't have a FunctionDecl) over to InitializationSequence.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
use the location information but we did spend a bunch of time building faked-up TypeLocs
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
InitializationSequence (when a FunctionDecl is present). This required
a few small fixes to initialization sequences:
- Make sure to use the adjusted parameter type for initialization of
function parameters.
- Implement transparent union calling semantics in C
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91902 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91882 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91881 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
since the context is available in the Decl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91862 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sure to fill in the initialized member of a union when a member was
explicitly designated. Fixes PR5843.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91796 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91767 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
InitializationSequence. Specially, switch initialization of a C++
class type (either copy- or direct-initialization).
Also, make sure that we create an elidable copy-construction when
performing copy initialization of a C++ class variable. Fixes PR5826.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. What's
new:
- InitializationSequence now has a "C conversion sequence" category
and step kind, which falls back to
- Changed the diagnostics for returns to always have the result type
of the function first and the type of the expression second.
CheckSingleAssignmentConstraints to peform checking in C.
- Improved ASTs for initialization of return values. The ASTs now
capture all of the temporaries we need to create, but
intentionally do not bind the tempoary that is actually returned,
so that it won't get destroyed twice.
- Make sure to perform an (elidable!) copy of the class object that
is returned from a class.
- Fix copy elision in CodeGen to properly see through the
subexpressions that occur with elidable copies.
- Give "new" its own entity kind; as with return values and thrown
objects, we don't bind the expression so we don't call a
destructor for it.
Note that, with this patch, I've broken returning move-only types in
C++0x. We'll fix it later, when we tackle NRVO.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91669 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with a non-trivial default constructor, zero-initialize the storage
and then call the default constructor. Fixes PR5800.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91548 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
InitializationSequence
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91542 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
InitializationSequence to perform the actual initialization.
Also, introduced the notion of a tree of initialized entities, so that
we can know where an initialization began when dealing with nested
initializations (as occur when performing list initialization). This
will, eventually, be useful for producing better diagnostics when list
initialization fails, because we can show the path from the top-level
object being initialized down to the actual subobject where
initialization failed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91516 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
than using its own partial implementation of initialization.
Switched CheckInitializerTypes over to
InitializedEntity/InitializationKind, to help move us closer to
InitializationSequence.
Added InitializedEntity::getName() to retrieve the name of the entity,
for diagnostics that care about such things.
Implemented support for default initialization in
InitializationSequence.
Clean up the determination of the "source expressions" for an
initialization sequence in InitializationSequence::Perform.
Taught CXXConstructExpr to store more location information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91492 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
WIP, yet again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91368 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91325 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91323 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
isn't turned on anyway yet, so it cannot be tested.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91294 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91234 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
no extra safety anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91207 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91097 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
new notion of an "initialization sequence", which encapsulates the
computation of the initialization sequence along with diagnostic
information and the capability to turn the computed sequence into an
expression. At present, I've only switched one CheckReferenceInit
callers over to this new mechanism; more will follow.
Aside from (hopefully) being much more true to the standard, the
diagnostics provided by this reference-initialization code are a bit
better than before. Some examples:
p5-var.cpp:54:12: error: non-const lvalue reference to type 'struct
Derived'
cannot bind to a value of unrelated type 'struct Base'
Derived &dr2 = b; // expected-error{{non-const lvalue reference to
...
^ ~
p5-var.cpp:55:9: error: binding of reference to type 'struct Base' to
a value of
type 'struct Base const' drops qualifiers
Base &br3 = bc; // expected-error{{drops qualifiers}}
^ ~~
p5-var.cpp:57:15: error: ambiguous conversion from derived class
'struct Diamond' to base class 'struct Base':
struct Diamond -> struct Derived -> struct Base
struct Diamond -> struct Derived2 -> struct Base
Base &br5 = diamond; // expected-error{{ambiguous conversion from
...
^~~~~~~
p5-var.cpp:59:9: error: non-const lvalue reference to type 'long'
cannot bind to
a value of unrelated type 'int'
long &lr = i; // expected-error{{non-const lvalue reference to type
...
^ ~
p5-var.cpp:74:9: error: non-const lvalue reference to type 'struct
Base' cannot
bind to a temporary of type 'struct Base'
Base &br1 = Base(); // expected-error{{non-const lvalue reference to
...
^ ~~~~~~
p5-var.cpp:102:9: error: non-const reference cannot bind to bit-field
'i'
int & ir1 = (ib.i); // expected-error{{non-const reference cannot
...
^ ~~~~~~
p5-var.cpp:98:7: note: bit-field is declared here
int i : 17; // expected-note{{bit-field is declared here}}
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90992 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90710 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rather than punting to a DependentSizedArrayType, tightening up our
type checking for template definitions. Thanks, John!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
incomplete array initialization, where we have the following in a
template:
int a[] = { 1, 2, something-value-dependent };
// ...
sizeof(a);
The type of "a" appears to be a non-dependent IncompleteArrayType, but
treating it as such makes the sizeof(a) fail at template definition
time. We now correctly handle this by morphing the IncompleteArrayType
into a DependentSizedArrayType with a NULL expression, indicating that
its size has no corresponding expression (and, therefore, the type is
distinct from others).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:
typedef const int CInt;
typedef CInt Self;
Self.isConstQualified() currently returns false!
Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions:
- the "local" version only returns qualifiers on this particular
QualType instance
- the "normal" version that will eventually combine qualifiers from this
QualType instance with the qualifiers on the canonical type to
produce the full set of qualifiers.
This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()
expressions over to
Context.hasSameUnqualifiedType(T1, T2)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88969 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84222 91177308-0d34-0410-b5e6-96231b3b80d8
|