The class seems to have an invariant that Entries is non-empty if
Invalid is false. It appears this method was previously private, and
all internal uses checked Invalid. Now there is an external caller, so
check Invalid to avoid array OOB underflow.
Fixes PR20420.
llvm-svn: 213816
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
being declared, not at the end. When pretty-printing a non-type template
parameter, put the name of the parameter in the middle of the type, not at the
end.
llvm-svn: 213718
This field is never inspected in the object state initialized by this
constructor; however, initializing it seems reasonable, since it has
a meaningful value.
llvm-svn: 213499
C99 array parameters can have index-type CVR qualifiers, and the TypePrinter
should print them when present (and we were not for constant-sized arrays).
Otherwise, we'd drop the restrict in:
int foo(int a[restrict static 3]) { ... }
llvm-svn: 213445
Assigns indices to try blocks. These indices will used in constructing
tables that the mscrt function __except_handler3 reads during SEH.
Testing will occur once we actually emit the tables, in a subsequent
patch.
llvm-svn: 213437
In C99, an array parameter declarator might have the form: direct-declarator
'[' 'static' type-qual-list[opt] assign-expr ']'
and when the size of the array is a constant, don't omit the static keyword
when printing the type. Also, in the VLA case, put a space after the static
keyword (some assignment expression must follow it).
llvm-svn: 213424
is unused (this is match behavior when property-dot syntax is used to
use same getter). rdar://17514245
Patch by Anders Carlsson with minor refactoring by me.
llvm-svn: 213423
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
llvm-svn: 213304
This is a follow-up to an IRC conversation with Richard last night; __assume
does not evaluate its argument, and so the argument should not contribute to
whether (__assume(e), constant) can be used where a constant is required.
llvm-svn: 213267
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
llvm-svn: 213224
With this change the memory of buffer in NestedNameSpecifierLocBuilder
is allocated in one place. It also prevents from allocation of tiny blocks.
llvm-svn: 213178
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
llvm-svn: 213167
We would correctly insert sufficiently aligned padding between vbases
when our leading base was empty, however we would neglect to increase
the required alignment of the most derived class.
This fixes PR20315.
llvm-svn: 213123
No functionality changed, just some cleanups:
- Switch some loops to range-based for.
- Name some iterators with a more creative name than "I".
- Reduce dependence on auto. Does RD->bases() give you a list of
CXXBaseSpecifiers or CXXRecordDecls? It's more clear to just say which
upfront.
llvm-svn: 213121
While we previously supported __uuidof applied to a template
specialization, we would only find the uuid attribute if it was applied
to the template argument. We would erroneously ignore the uuid
attribute on the specialization itself.
This is required to parse Windows Runtime C++ Template Library headers.
llvm-svn: 213016
Switch some things to use range-based for loops.
Change CXXUuidofExpr::GetUuidAttrOfType's return type to be const.
No functionality changed.
llvm-svn: 213009
This source range is useful for all kinds of diagnostic QOI and refactoring
work, so let's make it more discoverable.
This commit also makes use of the new function to enhance various diagnostics
relating to return types and resolves an old FIXME.
llvm-svn: 212154
There are slight differences between /GR- and -fno-rtti which made
mapping one to the other inappropriate.
-fno-rtti disables dynamic_cast, typeid, and does not emit RTTI related
information for the v-table.
/GR- does not generate complete object locators and thus will not
reference them in vftables. However, constructs like dynamic_cast and
typeid are permitted.
This should bring our implementation of RTTI up to semantic parity with
MSVC modulo bugs.
llvm-svn: 212138
The pointer for a class's RTTI data comes right before the VFTable but
has no name. To be properly compatible with this, we do the following:
* Create a single GlobalVariable which holds the contents of the VFTable
_and_ the pointer to the RTTI data.
* Create a GlobalAlias, with appropriate linkage/visibility, that points
just after the RTTI data pointer. This ensures that the VFTable
symbol will always refer to VFTable data.
* Create a Comdat with a "Largest" SelectionKind and stick the private
GlobalVariable in it. By transitivity, the GlobalAlias will be a
member of the Comdat group. Using "Largest" ensures that foreign
definitions without an RTTI data pointer will _not_ be chosen in the
final linked image.
Whether or not we emit RTTI data depends on several things:
* The -fno-rtti flag implies that we should never not emit a pointer to
RTTI data before the VFTable.
* __declspec(dllimport) brings in the VFTable from a remote DLL. Use an
available_externally GlobalVariable to provide a local definition of
the VFTable. This means that we won't have any available_externally
definitions of things like complete object locators. This is
acceptable because they are never directly referenced.
To my knowledge, this completes the implementation of MSVC RTTI code
generation.
Further semantic work should be done to properly support /GR-.
llvm-svn: 212125
Avoid a second key lookup when the back reference key is going to be
inserted in the StringMap. The string lookups in the msmangler are the
main responsible for the huge overhead when compared to the itanium
mangler. This patch makes a small but noticeable improvement.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4130
Patch by Agustín Bergé!
llvm-svn: 211813
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
Types defined in function prototype are diagnosed earlier in C++ compilation.
They are put into declaration context where the prototype is introduced. Later on,
when FunctionDecl object is created, these types are moved into the function context.
This patch fixes PR19018 and PR18963.
Differential Revision: http://reviews.llvm.org/D4145
llvm-svn: 211718
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
llvm-svn: 211677
VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.
Reviewed by: majnemer
Differential Revision: http://reviews.llvm.org/D4281
llvm-svn: 211667
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
This fixes PR19955.
llvm-svn: 211570
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
This fixes PR19955.
Differential Revision: http://reviews.llvm.org/D4250
llvm-svn: 211568
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
hint attributes. Includes tests for pragma printing and for attribute order
which is incorrectly reversed by ParsedAttributes.
Reviewed by Aaron Ballman
llvm-svn: 210925
Summary:
Do not store duplicate parents when memoization data is available.
This does not solve the duplication problem, but ameliorates it.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4124
llvm-svn: 210902
CRTP-like patterns involve a class which inherits from another class
using itself as a template parameter.
However, the base class itself may try to create a pointer-to-member
which involves the derived class. This is problematic because we
may not have finished parsing the most derived classes' base specifiers
yet.
It turns out that MSVC simply uses the unspecified inheritance model
instead of doing anything fancy.
This fixes PR19987.
llvm-svn: 210886
Richard Trieu