|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| | with CK_NoOp. Fixes PR7727.
llvm-svn: 109757 | 
| | 
| 
| 
| | llvm-svn: 109440 | 
| | 
| 
| 
| 
| 
| 
| | fixes crashes on both valid and invalid code.  The diagnostic here could
potentially be improved, but it's good enough as-is.
llvm-svn: 109257 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | reinterpret_casts (possibly indirectly via C-style/functional casts)
on values, e.g., 
  int i;
  reinterpret_cast<short&>(i);
The IR generated for this is essentially the same as for
  *reinterpret_cast<short*>(&i).
Fixes PR6437, PR7593, and PR7344. 
llvm-svn: 108294 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | (e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary. 
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253 | 
| | 
| 
| 
| 
| 
| | either integer values or other pointers. Fixes <rdar://problem/8134521>.
llvm-svn: 107905 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | provides C "integer type" semantics in C and C++ "integral type"
semantics in C++. 
Note that I still need to update isIntegerType (and possibly other
predicates) using the same approach I've taken for
isIntegralType(). The two should have the same meaning, but currently
don't (!).
llvm-svn: 106074 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678 | 
| | 
| 
| 
| 
| 
| | at array qualifiers. Fixes rdar://problem/8018292.
llvm-svn: 105494 | 
| | 
| 
| 
| 
| 
| 
| | CXXBasePaths::isAmbiguous(), rather than just asserting that we have a
canonical type. Fixes PR7176.
llvm-svn: 104374 | 
| | 
| 
| 
| | llvm-svn: 104019 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | "used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions. 
The new scheme:
  - For every use of a vtable, Sema calls MarkVTableUsed() to indicate
  the use. For example, this occurs when calling a virtual member
  function of the class, defining a constructor of that class type,
  dynamic_cast'ing from that type to a derived class, casting
  to/through a virtual base class, etc.
  - For every definition of a vtable, Sema calls MarkVTableUsed() to
  indicate the definition. This happens at the end of the translation
  unit for classes whose key function has been defined (so we can
  delay computation of the key function; see PR6564), and will also
  occur with explicit template instantiation definitions.
 - For every vtable defined/used, we mark all of the virtual member
 functions of that vtable as defined/used, unless we know that the key
 function is in another translation unit. This instantiates virtual
 member functions when needed.
  - At the end of the translation unit, Sema tells CodeGen (via the
  ASTConsumer) which vtables must be defined (CodeGen will define
  them) and which may be used (for which CodeGen will define the
  vtables lazily). 
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
  (1) There's a ton of churn in the tests, because the order in which
  vtables get emitted to IR has changed. I've tried to isolate some of
  the larger tests from these issues.
  (2) Some diagnostics related to
  implicitly-instantiated/implicitly-defined virtual member functions
  have moved to the point of first use/definition. It's better this
  way.
  (3) I could use a review of the places where we MarkVTableUsed, to
  see if I missed any place where the language effectively requires a
  vtable.
Fixes PR7114 and PR6564.
llvm-svn: 103718 | 
| | 
| 
| 
| 
| 
| | another.
llvm-svn: 103630 | 
| | 
| 
| 
| 
| 
| | Fixes radar 7952457.
llvm-svn: 103447 | 
| | 
| 
| 
| | llvm-svn: 102261 | 
| | 
| 
| 
| | llvm-svn: 102260 | 
| | 
| 
| 
| | llvm-svn: 102259 | 
| | 
| 
| 
| | llvm-svn: 102258 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | TryStaticImplicitCast (for references, class types, and everything
else, respectively) into a single invocation of
InitializationSequence.
One of the paths (for class types) was the only client of
Sema::TryInitializationByConstructor, which I have eliminated. This
also simplified the interface for much of the cast-checking logic,
eliminating yet more code.
I've kept the representation of C++ functional casts with <> 1
arguments the same, despite the fact that I hate it. That fix will
come soon. To satisfy my paranoia, I've bootstrapped + tested Clang
with these changes.
llvm-svn: 101549 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | functional casts over to InitializationSequence, eliminating a caller
of Sema::TryImplicitConversion. We also get access and ambiguity
checking "for free".
More cleanups to come in this routine.
llvm-svn: 101526 | 
| | 
| 
| 
| | llvm-svn: 101502 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | ResolveAddressOfOverloadedFunction when asked to complain. Previously,
we had some weird handshake where ResolveAddressOfOverloadedFunction
expected its caller to handle some of the diagnostics but not others,
and yet there was no way for the caller to know which case we were
in. Eliminate this madness, fixing <rdar://problem/7765884>.
llvm-svn: 101312 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation.  This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.
Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.
Fixes <rdar://problem/7806091>.
llvm-svn: 99849 | 
| | 
| 
| 
| 
| 
| 
| 
| | initialization code. Exposed a bug where we were not marking an
implicit conversion as an lvalue when we were forming a call to a
conversion function whose return type is a reference.
llvm-svn: 99459 | 
| | 
| 
| 
| 
| 
| 
| 
| | CheckReferenceInit) over to the new initialization code
(InitializationSequence), which is better-tested and doesn't require
us to compute the entire conversion sequence twice.
llvm-svn: 99452 | 
| | 
| 
| 
| 
| 
| | required when emitting a destructor definition.
llvm-svn: 98609 | 
| | 
| 
| 
| 
| 
| 
| | pointer-to-member-to-derived to a pointer-to-member-to-base. Fixes
PR6072.
llvm-svn: 97923 | 
| | 
| 
| 
| 
| 
| 
| | and CXXRecordDecl::getDefinition(); it's totally unnecessary. No
functionality change.
llvm-svn: 95836 | 
| | 
| 
| 
| 
| 
| 
| | conversions.  Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path.  Prepare for friends.
llvm-svn: 95775 | 
| | 
| 
| 
| 
| 
| | (partial fix for radar 7591784).
llvm-svn: 95245 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
  const int i;
  (void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it. 
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
  - the left-hand side of a '.' operator
  - the left-hand side of an assignment
  - a C++ throw expression
  - a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
  - we were deducing const-qualified return types of non-class type
  from a block return, which doesn't fit well
  - we weren't always setting the known return type of a block when it
  was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
llvm-svn: 95167 | 
| | 
| 
| 
| 
| 
| | instantiation.
llvm-svn: 93533 | 
| | 
| 
| 
| 
| 
| | Patch by Enea Zaffanella.
llvm-svn: 93522 | 
| | 
| 
| 
| 
| 
| 
| | sequence.  Lots of small relevant changes.  Fixes some serious problems with
ambiguous conversions;  also possibly improves associated diagnostics.
llvm-svn: 93214 | 
| | 
| 
| 
| 
| 
| 
| 
| | CV-qualifiers. Remove an error expectation from the 'good' set of const-cast
test cases. With this patch, the final non-template test case from PR5542
passes. (It's the same as the one already in const-cast.cpp.)
llvm-svn: 92257 | 
| | 
| 
| 
| | llvm-svn: 92162 | 
| | 
| 
| 
| 
| 
| 
| | paths. Fixes "cannot compile this unexpected cast lvalue yet" error in
llvm/lib/Analysis/IPA/GlobalsModRef.cpp.
llvm-svn: 91932 | 
| | 
| 
| 
| | llvm-svn: 91503 | 
| | 
| 
| 
| 
| 
| | (fixes radar 7465023).
llvm-svn: 91171 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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}}
      ^
llvm-svn: 90992 | 
| | 
| 
| 
| 
| 
| | in objective-c++ mode without being too lenient.
llvm-svn: 90895 | 
| | 
| 
| 
| 
| 
| | mode as they are pervasive.
llvm-svn: 90867 | 
| | 
| 
| 
| 
| 
| | classes. Fixes PR5545.
llvm-svn: 89215 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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)
llvm-svn: 88969 | 
| | 
| 
| 
| | llvm-svn: 88893 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | that we're dealing with canonical types like the documentation say
(yay, CanQualType). Alas, this is another instance where using
getQualifiers() on a non-canonical QualType got us in trouble.
Good news: with this fix, Clang can now parse all of its own headers!
llvm-svn: 88848 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | reference. CheckReferenceInit already inserts implicit casts to the necessary types. This fixes an assertion in CodeGen for some casts and brings a fix for PR5453 close, if I understand that bug correctly.
- Also, perform calculated implicit cast sequences if they're determined to work. This finally diagnoses static_cast to ambiguous or implicit bases and fixes two long-standing fixmes in the test case. For the C-style cast, this requires propagating the access check suppression pretty deep into other functions.
- Pass the expressions for TryStaticCast and TryStaticImplicitCast by reference. This should lead to a better AST being emitted for such casts, and also fixes a memory leak, because CheckReferenceInit and PerformImplicitConversion wrap the node passed to them. These wrappers were previously lost.
llvm-svn: 88809 | 
| | 
| 
| 
| 
| 
| 
| 
| | cast) that is converting to a class type, enumerate its constructors
as in any other direct initialization. This ensures that we get the
proper conversion sequence.
llvm-svn: 88751 |