| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
In version 9 (VS2010) (and prior)? versions of msvc, if the last field
in a record was a bitfield padding equal to the size of the storage
class of that bitfield was added before each vbase and vtordisp. This
patch removes that feature from clang and updates the lit tests to
reflect it.
llvm-svn: 206004
|
|
|
|
|
|
|
|
| |
The vbptr is injected after the last non-virtual base lexographically
rather than the last non-virtual base in layout order. Test case
included. Also, some line ending fixes.
llvm-svn: 206000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When __declspec(align()) is applied to a bitfield it affects the
alignment rather than the required alignment of the struct. The major
feature that this patch adds is that the alignment of the structure
obeys the alignment of __declspec(align()) from the bitfield over the
value specified in pragma pack.
Test cases are included.
The patch also includes some small cleanups in recordlayoutbuilder and
some cleanups to some lit tests, including line endings (but no
functionality change to lit tests)
llvm-svn: 205994
|
|
|
|
| |
llvm-svn: 205945
|
|
|
|
|
|
|
|
|
| |
cxx-abi-dev came up with a way to disambiguate between different
keywords used in elaborated type specifiers.
This resolves certain collisions during mangling.
llvm-svn: 205943
|
|
|
|
|
|
|
|
|
|
| |
This patch changes how we determine if padding is needed between two
bases in msvc compatibility mode. Test cases included.
In addition, a very minor change to the printing of structures to ease
lit testing.
llvm-svn: 205933
|
|
|
|
|
|
|
|
|
|
|
| |
It is very similar to GCC's __PRETTY_FUNCTION__, except it prints the
calling convention.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D3311
llvm-svn: 205780
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 205757
|
|
|
|
|
|
|
|
| |
This can actually be non-zero if you override a function from a virtual
base and you have forced the most_general pointer to member
representation.
llvm-svn: 205727
|
|
|
|
|
|
|
| |
when bridged Objective-C type conforms to the protocols in CF types's
Objective-C class. // rdar://16393330
llvm-svn: 205659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
better. This warning will now trigger on the following conditionals:
bool b;
int i;
if (b > 1) {} // always false
if (0 <= (i > 5)) {} // always true
if (-1 > b) {} // always false
Patch by Per Viberg.
llvm-svn: 205608
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No functionality change.
When determining the pattern for instantiating a generic lambda call operator specialization - we must not go drilling down for the 'prototype' (i.e. as written) pattern - rather we must use our partially transformed pattern (whose DeclRefExprs are wired correctly to any enclosing lambda's decls that should be mapped correctly in a local instantiation scope) that is the templated pattern of the specialization's primary template (even though the primary template might be instantiated from a 'prototype' member-template). Previously, the drilling down was haltted by marking the instantiated-from primary template as a member-specialization (incorrectly).
This prompted Richard to remark (http://llvm-reviews.chandlerc.com/D1784?id=4687#inline-10272)
"It's a bit nasty to (essentially) set this bit incorrectly. Can you put the check into getTemplateInstantiationPattern instead?"
In my reckless youth, I chose to ignore that comment. With the passage of time, I have come to learn the value of bowing to the will of the angry Gods ;)
llvm-svn: 205543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
llvm-svn: 205485
|
|
|
|
|
|
| |
'readonly' property. // rdar://16136439
llvm-svn: 205477
|
|
|
|
|
|
|
|
|
|
|
|
| |
at ... )')
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
|
|
|
|
|
|
|
|
|
| |
While investigating some debug info issues, Eric and I came across a
particular template case where the location of a decl was quite
different from the range of the same decl. It might've been rather
helpful if the dumper had actually showed us this.
llvm-svn: 205396
|
|
|
|
| |
llvm-svn: 205351
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI forces us into catch-22 when it comes to functions which
return types which are local:
- A function is mangled with it's return type.
- A type is mangled with it's surrounding context.
Avoid this by mangling auto and decltype(autp) directly into the
function's return type. Using this mangling has the double advantage of
being compatible with the C++ standard without crashing the compiler.
N.B. For the curious, the MSVC mangling leads to collisions amongst
template functions and either crashes when faced with local types or is
otherwise incapable of returning them.
llvm-svn: 205282
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that the ranges where the '?' <letter> manglings occur are
identical to the ranges of ASCII characters OR'd with 0x80.
Thanks to Richard Smith for the insight!
No functional change.
llvm-svn: 205270
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205250
|
|
|
|
|
|
|
| |
No test case is needed, the one in-tree is sufficient. The build-bot
never emailed me because something else had upset it.
llvm-svn: 205225
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205223
|
|
|
|
|
|
| |
MicrosoftVTableContext::computeVTablePaths(). No functionality changes.
llvm-svn: 205178
|
|
|
|
| |
llvm-svn: 205164
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205156
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205154
|
|
|
|
|
|
|
|
|
|
| |
The delta between '\xe1' and '\xc1' is equivalent to the one between 'a'
and 'A'. This allows us to reuse the computation between '\xe1' and
'\xfa' for the '\xc1' to '\xda' case.
No functionality change.
llvm-svn: 205128
|
|
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
|
|
|
|
|
|
| |
of TemplateArgumentLocs. 'uint64_t' has higher alignment requirements than a
pointer on some platforms.
llvm-svn: 205068
|
|
|
|
|
|
|
|
|
|
| |
consider that the ObjC interface of the class
includes its class extensions.
This is follow-up for rdar://16305347
llvm-svn: 205065
|
|
|
|
|
|
|
|
|
| |
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
|
|
|
|
|
|
|
|
| |
irrelevant
Reviewed in http://llvm-reviews.chandlerc.com/D3190
llvm-svn: 204953
|
|
|
|
|
|
| |
Previously we would only attach comments to the typedef.
llvm-svn: 204942
|
|
|
|
|
|
|
|
|
| |
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
|
|
|
|
|
|
|
|
| |
Store the number of clauses and children of OMPExecutableDirective and dynamically compute the locations of corresponding arrays.
http://llvm-reviews.chandlerc.com/D2977
llvm-svn: 204933
|
|
|
|
| |
llvm-svn: 204787
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3181
llvm-svn: 204786
|
|
|
|
|
|
| |
Fixes PR19240. In retrospect, this is a fairly obvious bug. :)
llvm-svn: 204744
|
|
|
|
|
|
| |
declarations for a name, reconcile first. Otherwise, when we come to reconcile, we'll ask for external declarations for that name again. No functionality change intended.
llvm-svn: 204692
|
|
|
|
|
|
| |
specialization would make us think it might have a key function.
llvm-svn: 204686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
|
|
|
|
|
|
|
|
|
| |
As of cl.exe version 18, the special layout rules for structs with
alignment 16 or greater has been dropped. This patch drops the behavior
from clang. This patch also updates the lit tests to reflect the
change.
llvm-svn: 204674
|
|
|
|
| |
llvm-svn: 204596
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
llvm-svn: 204586
|
|
|
|
|
|
| |
'TemplateArgument's.
llvm-svn: 204572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
found with a smarter version of -Wunused-member-function that I'm playwing with.
Appologies in advance if I removed someone's WIP code.
ARCMigrate/TransProperties.cpp | 8 -----
AST/MicrosoftMangle.cpp | 1
Analysis/AnalysisDeclContext.cpp | 5 ---
Analysis/LiveVariables.cpp | 14 ----------
Index/USRGeneration.cpp | 10 -------
Sema/Sema.cpp | 33 +++++++++++++++++++++---
Sema/SemaChecking.cpp | 3 --
Sema/SemaDecl.cpp | 20 ++------------
StaticAnalyzer/Checkers/GenericTaintChecker.cpp | 1
9 files changed, 34 insertions(+), 61 deletions(-)
llvm-svn: 204561
|
|
|
|
| |
llvm-svn: 204428
|
|
|
|
|
|
|
|
| |
class with complex inheritance
Reviewed at http://llvm-reviews.chandlerc.com/D3128
llvm-svn: 204394
|
|
|
|
| |
llvm-svn: 204341
|