| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Prevents an assert on successive redeclarations.
Fixed PR5573.
llvm-svn: 91956
|
| |
|
|
| |
llvm-svn: 91951
|
| |
|
|
| |
llvm-svn: 91948
|
| |
|
|
|
|
| |
while at it, remove an outdated FIXME
llvm-svn: 91946
|
| |
|
|
|
|
|
|
| |
size_t. Also, fix an issue with initialization of parameters in calls,
where we weren't removing the cv-qualifiers on the parameter type
itself. Fixes PR5823.
llvm-svn: 91941
|
| |
|
|
|
|
|
| |
paths. Fixes "cannot compile this unexpected cast lvalue yet" error in
llvm/lib/Analysis/IPA/GlobalsModRef.cpp.
llvm-svn: 91932
|
| |
|
|
| |
llvm-svn: 91928
|
| |
|
|
| |
llvm-svn: 91927
|
| |
|
|
|
|
|
| |
InitializationSequence. Fixes the -fsyntax-only failure in
llvm/lib/Transforms/Scalar/InstructionCombining.cpp.
llvm-svn: 91921
|
| |
|
|
|
|
|
| |
a size, check whether the transformed type is itself an array type. If
so, take the major array bound as the size to allocate. Fixes PR5833.
llvm-svn: 91907
|
| |
|
|
|
|
| |
don't have a FunctionDecl) over to InitializationSequence.
llvm-svn: 91906
|
| |
|
|
|
|
| |
use the location information but we did spend a bunch of time building faked-up TypeLocs
llvm-svn: 91905
|
| |
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 91902
|
| |
|
|
|
|
| |
who prefers to be stealthy and mysterious.
llvm-svn: 91888
|
| |
|
|
|
|
| |
must also mark the member decl as referenced.
llvm-svn: 91887
|
| |
|
|
| |
llvm-svn: 91884
|
| |
|
|
| |
llvm-svn: 91883
|
| |
|
|
| |
llvm-svn: 91882
|
| |
|
|
| |
llvm-svn: 91881
|
| |
|
|
|
|
| |
before in the new function Sema::DiagRuntimeBehavior, addressing one of Chris' comments.
llvm-svn: 91870
|
| |
|
|
|
|
|
|
|
| |
this was useful, and on review Doug and I decided it was probably on the level
of a bug in the standard and therefore not worth a warning even in -pedantic.
If someone disagrees and urgently wants clang++ to warn about this in strict
c++98 mode, we can talk about it.
llvm-svn: 91868
|
| |
|
|
|
|
| |
since the context is available in the Decl
llvm-svn: 91862
|
| |
|
|
|
|
|
|
|
| |
constructor call, the conversion is only a standard conversion
sequence if that constructor is a copy constructor. This fixes PR5834
in a semi-lame way, because the "real" fix will be to move over to
InitializationSequence. That will happen "soonish", but not now.
llvm-svn: 91861
|
| |
|
|
|
|
|
| |
sure to fill in the initialized member of a union when a member was
explicitly designated. Fixes PR5843.
llvm-svn: 91858
|
| |
|
|
|
|
|
|
|
|
| |
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
llvm-svn: 91852
|
| |
|
|
|
|
|
|
|
| |
not deduce an "overload" type. Such a deduction indicates a failure in
semantic analysis (e.g., PR5811) that currently isn't caught until
code-generation time. This assertions makes it clearer that this
particular issue is a semantic-analysis problem, not a code-gen problem.
llvm-svn: 91844
|
| |
|
|
|
|
| |
as a g++ extension (fixes radar 7481987).
llvm-svn: 91827
|
| |
|
|
|
|
| |
support diagnostics and error recovery.
llvm-svn: 91825
|
| |
|
|
|
|
|
|
|
|
| |
Sema::getTypeName.
"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though;
it doesn't ignore namespaces. Someone more familiar with the lookup code
should fix this properly.
llvm-svn: 91809
|
| |
|
|
| |
llvm-svn: 91808
|
| |
|
|
| |
llvm-svn: 91803
|
| |
|
|
|
|
| |
assignment.
llvm-svn: 91798
|
| |
|
|
| |
llvm-svn: 91797
|
| |
|
|
|
|
| |
over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
|
| |
|
|
| |
llvm-svn: 91795
|
| |
|
|
| |
llvm-svn: 91794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
|
| |
|
|
| |
llvm-svn: 91772
|
| |
|
|
|
|
|
| |
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
llvm-svn: 91771
|
| |
|
|
|
|
| |
instantiation, since we're not using a Scope object for that anyway.
llvm-svn: 91770
|
| |
|
|
|
|
|
| |
Magically fixes all the terrible lookup problems associated with not pushing
a new scope. Resolves an ancient xfail and an LLVM misparse.
llvm-svn: 91769
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 91767
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 91750
|
| |
|
|
|
|
|
|
|
|
| |
dependent.
Avoids an assertion arising during object-argument initialization in overload
resolution. In theory we can resolve this at definition time if the class
hierarchy for the member is fully known.
llvm-svn: 91747
|
| |
|
|
| |
llvm-svn: 91702
|
| |
|
|
|
|
| |
with "declared at" rather than "previous declaration is here".
llvm-svn: 91699
|
| |
|
|
| |
llvm-svn: 91696
|
| |
|
|
| |
llvm-svn: 91678
|
| |
|
|
|
|
|
|
|
|
| |
nested-name specifier name.
I accidentally checked in the test case for this in the last commit ---
fortunately, that refactor was inspired by having debugged this problem already,
so I can fix the bug quick (though probably not fast enough for the buildbots).
llvm-svn: 91677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
different functions and pick the function at lookup initialization time.
In theory we could actually divide the criteria functions into N different
functions for the N cases, but it's so not worth it.
Among other things, lets us invoke LookupQualifiedName without recomputing
IDNS info every time.
Do some refactoring in SemaDecl to avoid an awkward special case in LQN
that was only necessary for redeclaration testing for anonymous structs/unions ---
which could be done more efficiently with a scoped lookup anyway.
llvm-svn: 91676
|