| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 137653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
llvm-svn: 137573
|
| |
|
|
|
|
|
| |
special member function, make sure to classify an explicitly-defaulted
copy constructor as a "copy" operation. Fixes PR10622.
llvm-svn: 137219
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
constructor. Previously, we did some bogus recursion into the fields
of anonymous structs (recursively), which ended up building invalid
ASTs that would cause CodeGen to crash due to invalid GEPs.
Now, we instead build the default initializations based on the
indirect field declarations at the top level, which properly generates
the sequence of GEPs needed to initialize the proper member. Fixes
PR10512 and <rdar://problem/9924046>.
llvm-svn: 137212
|
| |
|
|
|
|
|
| |
Use the the path that generates a loop. This fixes
bogus error that clang puts out. // rdar://9894548
llvm-svn: 137080
|
| |
|
|
|
|
|
|
| |
completely broken deserialization mapping code we had for VTableUses,
which would have broken horribly as soon as our local-to-global ID
mapping became interesting.
llvm-svn: 136371
|
| |
|
|
| |
llvm-svn: 136273
|
| |
|
|
|
|
|
|
| |
FullSourceLoc::getInstantiationLoc to ...::getExpansionLoc. This is part
of the API and documentation update from 'instantiation' as the term for
macros to 'expansion'.
llvm-svn: 135914
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
| |
llvm-svn: 135668
|
| |
|
|
|
|
| |
access specifier as public.
llvm-svn: 135649
|
| |
|
|
|
|
| |
non-value-dependent cases.
llvm-svn: 135543
|
| |
|
|
|
|
|
| |
unrestricted unions, which ended up attempting to initialize objects
in a union (which CodeGen isn't prepared for). Fixes PR9683.
llvm-svn: 135027
|
| |
|
|
|
|
|
| |
implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771
llvm-svn: 134992
|
| |
|
|
| |
llvm-svn: 134892
|
| |
|
|
|
|
|
| |
declaration with dependent type. Fixes PR10232 /
<rdar://problem/9700653>.
llvm-svn: 134515
|
| |
|
|
|
|
| |
ActOnDeclarator can return NULL. Fixes PR10270, from Hans Wennborg!
llvm-svn: 134416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 133984
|
| |
|
|
|
|
|
|
| |
When performing semantic analysis on a member declaration, fix the check for whether we are declaring a function to check for parenthesized declarators, declaration via decltype, etc.
Also fix the semantic check to not treat FuncType* as a function type.
llvm-svn: 133862
|
| |
|
|
|
|
| |
in fragile abi mode and some other cleanups. // rdar://8940528
llvm-svn: 133747
|
| |
|
|
|
|
| |
in Darwin's fragile abi mode. // rdar://8940528
llvm-svn: 133639
|
| |
|
|
|
|
|
| |
Removes dead code found in the process.
Adds a test to verify that ParenListExprs do not have NULL types.
llvm-svn: 133637
|
| |
|
|
|
|
| |
are also present.
llvm-svn: 133593
|
| |
|
|
|
|
|
| |
lookup. Previously, it was breaking self-host, but it's been a week and
a half and I can't reproduce, so I need to see if it's still failing.
llvm-svn: 133581
|
| |
|
|
| |
llvm-svn: 133501
|
| |
|
|
|
|
|
| |
operators, don't make an initializer or sub-operation for zero-width
bitfields.
llvm-svn: 133221
|
| |
|
|
|
|
|
|
|
|
| |
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
|
| |
|
|
| |
llvm-svn: 132878
|
| |
|
|
|
|
| |
to study it.
llvm-svn: 132843
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I believe, upon, careful review, that this code causes us to incorrectly
handle exception specifications of copy assignment operators in C++03
mode. However, we currently do not seem to properly implement the subtle
distinction between copying of members and bases made by implicit copy
constructors and assignment operators in C++03 - namely that they are
limited in their overload selection - in all cases. As such, I feel that
committing this code is correct pending a careful review of our
implementation of these semantics.
llvm-svn: 132841
|
| |
|
|
| |
llvm-svn: 132835
|
| |
|
|
|
|
|
|
| |
isn't yet used for the less controlled environments of initialization.
Also a few random text fixups.
llvm-svn: 132833
|
| |
|
|
|
|
| |
SemaInit.cpp. Replace them with the boolean conversion or the new Failed() function. This is a first step towards removing InitializationSequence::SequenceKind. No functionality change.
llvm-svn: 132664
|
| |
|
|
|
|
|
|
|
| |
makes it into a special member function. This is very bad and can lead
to all sorts of nastiness including implicit member functions violating
the One Definition Rule. This should probably be made ill-formed in a
later version of the standard, but for now we'll just warn.
llvm-svn: 132104
|
| |
|
|
| |
llvm-svn: 132096
|
| |
|
|
|
|
|
|
| |
behind implicit moves. We now correctly identify move constructors and
assignment operators and update bits on the record correctly. Generation
of implicit moves (declarations or definitions) is not yet supported.
llvm-svn: 132080
|
| |
|
|
|
|
|
|
| |
The general out-of-line case (including explicit instantiation mostly
works except that the definition is being lost somewhere between the AST
and CodeGen, so the definition is never emitted.
llvm-svn: 131933
|
| |
|
|
|
|
|
|
| |
fixes PR9965, but we're not out of the water yet, as we do not
successfully handle out-of-line definitions, due to my utter
misunderstanding of how we manage templates.
llvm-svn: 131920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration found is unaccessible (private) and that declaration was bring into scope via another using declaration whose target declaration is accessible (public) then no error is generated.
Example:
class A { public: int f(); };
class B : public A { private: using A::f; };
class C : public B { private: using B::f; };
Here, B::f is private so this should fail in Standard C++, but because B::f refers to A::f which is public MSVC accepts it.
This fixes 1 error when parsing MFC code with clang.
llvm-svn: 131896
|
| |
|
|
|
|
|
| |
This case is tested by the fact that the modified test produces
significatly worse diagnostics. That's on the list.
llvm-svn: 131759
|
| |
|
|
|
|
|
| |
to a warning, since apparently libstdc++'s debug mode does this (and
we can recover safely). Add a Fix-It to insert the "inline", just for kicks.
llvm-svn: 131732
|
| |
|
|
|
|
| |
for destructors until the class is complete and destructors have been adjusted.
llvm-svn: 131632
|
| |
|
|
| |
llvm-svn: 131574
|
| |
|
|
|
|
| |
other things, libcxx not building.
llvm-svn: 131573
|
| |
|
|
| |
llvm-svn: 131528
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
member functions by making sure that they're on the record before
checking for deletion.
Also make sure source locations are valid to avoid crashes.
Unfortunately, the declare-all-implicit-members approach is still
required in order to ensure that dependency loops do not result in
incorrectly deleting functions (since they are to be deleted at the
declaration point per the standard).
Fixes PR9917
llvm-svn: 131520
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I hear at least one person crying out in anguish, but it's unfortunately
necessary to avoid infinite loops with mutually dependent constructors
trying to call each other and determine if they are deleted.
It might be possible to go back to the old behavior if we can implement
part-of-file lookups efficiently, or if a solution is discovered by
which we can safely detect and avoid infinite recusion.
llvm-svn: 131515
|
| |
|
|
|
|
|
| |
constructors, including two more FIXMEs (one of which I don't actually
understand).
llvm-svn: 131487
|
| |
|
|
|
|
| |
suppress an error we were previously emitting on valid union code.
llvm-svn: 131440
|