We would previously allow inappropriate inheritance keywords to appear
on class declarations. We would also allow inheritance keywords on
templates which were not fully specialized; this was divergent from
MSVC.
Differential Revision: http://llvm-reviews.chandlerc.com/D2585
llvm-svn: 200423
This reverts commit r199475 (which reverted r199416) with fixes for the
breakages.
We wouldn't lock an inheritance model if we saw a pointer-to-member
formed as a result of the address-of operator.
llvm-svn: 199482
The MSVC ABI is rather finicky about the exact representation of it's
pointer-to-member representation. The exact position of when and where
it will go with one representation versus another appears to be when it
desires the pointer-to-member to be complete.
To properly implement this in clang, do several things:
- Give up on tracking the polymorphic nature of the class. It isn't
useful to Sema and is only pertinent when choosing CodeGen-time
details like whether the field-offset can be 0 instead of -1.
- Insist on locking-in the inheritance model when we ask our
pointer-to-member type to be complete. From there, grab the
underlying CXXRecordDecl and try to make *that* complete. Once we've
done this, we can calculate it's inheritance model and apply it using
an attribute.
N.B. My first bullet point is a lie. We will eventually care about the
specifics of whether or not a CXXRecordDecl is or is not polymorphic
because MSVC compatible mangling of such things depends on it. However,
I believe we will handle this in a rather different way.
llvm-svn: 199416
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
Summary:
Handles all inheritance models for both data and function member
pointers.
Also implements isZeroInitializable() and refactors some of the null
member pointer code.
MSVC supports converting member pointers through virtual bases, which
clang does not (yet?) support. Implementing that extension is covered
by http://llvm.org/15713
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D613
llvm-svn: 179305
Summary:
This makes it possible to share code between lib/AST/MicrosoftCXXABI.cpp
and lib/CodeGen/MicrosoftCXXABI.cpp. No functionality change.
Also adds comments about the layout of the member pointer structs as I
currently understand them.
Reviewers: rjmccall
CC: timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D590
llvm-svn: 178548
Summary:
This also relaxes the requirement on Windows that the member pointer
class type be a complete type (http://llvm.org/PR12070). We still ask
for a complete type to instantiate any templates (MSVC does this), but
if that fails we continue as normal, relying on any inheritance
attributes on the declaration.
Reviewers: rjmccall
CC: triton, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D568
llvm-svn: 178283
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
David Majnemer