in terms of where the type resides in the containing object. This is a
more clear embodiement of the spec & fixes a merging issue with
unions. Down to 3/1000 failures.
llvm-svn: 63455
sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.
Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.
llvm-svn: 63450
- Support initialization of reference members; complain if any
reference members are left uninitialized.
- Use C++ copy-initialization for initializing each element (falls
back to constraint checking in C)
- Make sure we diagnose when one tries to provide an initializer
list for a non-aggregate.
- Don't complain about empty initializers in C++ (they are permitted)
- Unrelated but necessary: don't bother trying to convert the
decl-specifier-seq to a type when we're dealing with a C++
constructor, destructor, or conversion operator; it results in
spurious warnings.
llvm-svn: 63431
the liveness state of block-level expressions could oscillate because
of two issues:
- The initial value before a merge was not always set to "Top"
- The set of live block-level expressions is a union, not an intersection
This fixes <rdar://problem/650084>.
llvm-svn: 63421
parameter that allows users to omit the printing of the source
location on a diagnostic. So basically it would omit the "abc.c:5:1: "
at the beginning of the line."
Patch by Alexei Svitkine!
llvm-svn: 63396
type" rather than the C definition. We do this because both C99 and
Clang always use "aggregate type" as "aggregate or union type", and
the C++ definition includes union types.
llvm-svn: 63395
LookupName et al. Instead, use an enum and a bool to describe its
contents.
Optimized the C/Objective-C path through LookupName, eliminating any
unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing
some code and arguments that are no longer used.
Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers
over to LookupName, LookupQualifiedName, or LookupParsedName, as
appropriate.
All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and
-disable-free. Plus, we're down to three name-lookup routines.
llvm-svn: 63354
- NonLoc::MakeVal() would use sizeof(unsigned) (literally) instead of consulting
ASTContext for the size (in bits) of 'int'. While it worked, it was a
conflation of concepts and using ASTContext.IntTy is 100% correct.
- RegionStore::getSizeInElements() no longer assumes that a VarRegion has the
type "ConstantArray", and handles the case when uses use ordinary variables
as if they were arrays.
- Fixed ElementRegion::getRValueType() to just return the rvalue type of its
"array region" in the case the array didn't have ArrayType.
- All of this fixes <rdar://problem/6541136>
llvm-svn: 63347
This results in a 1.7% improvement for "Cocoa.h". If we can figure out how to return a "Decl *", rather than a Sema::LookupResult(), we will likely bump the speedup from 1.7%->2.5%. I verified this, however couldn't get it to work without breaking a fair number of C++ test cases. Will discuss with Doug offline.
llvm-svn: 63320
represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.
The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.
llvm-svn: 63317
Nuno Lopes