The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-parameter-dependent
initializations into the member value inits.
llvm-svn: 336726
Functions that are a sub-Decl of a record were hashed differently than other
functions. This change keeps the AddFunctionDecl function and the hash of
records now calls this function. In addition, AddFunctionDecl has an option
to perform a hash as if the body was absent, which is required for some
checks after loading modules. Additional logic prevents multiple error
message from being printed.
llvm-svn: 336632
Summary: On constructors that do not take the end source location, it was not imported. Fixes test from D47698 / rC336269.
Reviewers: martong, a.sidorin, balazske, xazax.hun, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: a_sidorin, rnkovacs, cfe-commits
Differential Revision: https://reviews.llvm.org/D48941
llvm-svn: 336523
A Chromium developer reported a bug which turned out to be a mangling
collision between these two literals:
char s[] = "foo";
char t[32] = "foo";
They may look the same, but for the initialization of t we will (under
some circumstances) use a literal that's extended with zeros, and
both the length and those zeros should be accounted for by the mangling.
This actually makes the mangling code simpler: where it previously had
special logic for null terminators, which are not part of the
StringLiteral, that is now covered by the general algorithm.
(The problem was reported at https://crbug.com/857442)
Differential Revision: https://reviews.llvm.org/D48928
llvm-svn: 336415
As brought up on cfe-commits[1], r334650 causes the dependency of the
out parameter to the __builtin_*_overflow functions to be ignored. The result
was a usage that was otherwise constexpr (both operands to the operation were
constexpr) would be evaluated, but the out parameter wouldn't be modified, so
it would still be 'undef'.
This patch correctly handles the return value of handleAssignment to ensure that
this value is properly considered/evaluated.
[1] http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180702/233667.html
llvm-svn: 336364
Summary:
Currently, anonymous types are merged into the same redecl chain even if they
are structurally inequivalent. This results that global objects are not
imported, if there are at least two global objects with different anonymous
types. This patch provides a fix.
Reviewers: a.sidorin, balazske, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D48773
llvm-svn: 336332
Summary:
Emmiting new intrinsic that strips invariant.groups to make
devirtulization sound, as described in RFC: Devirtualization v2.
Reviewers: rjmccall, rsmith, amharc, kuhar
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D47299
Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 336137
MSVC limits char16_t and char32_t string literal names to 32 bytes of character
data, not to 32 characters. wchar_t string literal names on the other hand can
get up to 64 bytes of character data.
https://reviews.llvm.org/D48781
llvm-svn: 336097
not like bit-fields.
We used to get this right "by accident", because conversions for the
selected built-in overloaded operator would convert the enum bit-field
to its corresponding underlying type early. But after DR1687 that no
longer happens.
Technically this change should also apply to C, where bit-fields only
have special promotion rules if the bit-field's declared type is
_Bool, int, signed int, or unsigned int, but for GCC compatibility we
only look at the bit-width and not the underlying type when performing
bit-field integral promotions in C.
llvm-svn: 335925
ODRHash aims to provide Cross-TU stable hashing. Making clang::Type pointer
part of the hash connects (remotely) the ODRHash with the TU-specific
::Profile hasher.
r332281 exposed the issue by changing the way the ASTContext different
elaborated types if there is an owning tag. In that case, ODRHash stores two
different types in its TypeMap which yields false ODR violation in modules.
The current state of implementation shouldn't need the TypeMap concept
anymore. Rip it out.
Differential Revision: https://reviews.llvm.org/D48524
llvm-svn: 335853
conversions are only applied to operands of class type, and the second
standard conversion sequence is not applied.
When diagnosing an invalid builtin binary operator, talk about the
original types rather than the converted types. If these differ by a
user-defined conversion, tell the user what happened.
llvm-svn: 335781
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske, a_sidorin
Reviewed By: a_sidorin
Subscribers: labath, aprantl, a_sidorin, rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
Re-apply commit rC335480
llvm-svn: 335731
Summary:
At import of a record describing a template set its type to
InjectedClassNameType (instead of RecordType).
Reviewers: a.sidorin, martong, r.stahl
Reviewed By: a.sidorin, martong, r.stahl
Subscribers: a_sidorin, rnkovacs, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47450
Patch by Balazs Keri!
llvm-svn: 335600
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
llvm-svn: 335480
With MSVC, PCH files are created along with an object file that needs to
be linked into the final library or executable. That object file
contains the code generated when building the headers. In particular, it
will include definitions of inline dllexport functions, and because they
are emitted in this object file, other files using the PCH do not need
to emit them. See the bug for an example.
This patch makes clang-cl match MSVC's behaviour in this regard, causing
significant compile-time savings when building dlls using precompiled
headers.
For example, in a 64-bit optimized shared library build of Chromium with
PCH, it reduces the binary size and compile time of
stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6
to 6.63 s. The wall-clock time of building blink_core.dll goes from
38m41s to 22m33s. ("user" time goes from 1979m to 1142m).
Differential Revision: https://reviews.llvm.org/D48426
llvm-svn: 335466
This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal.
Fixed point literals are declared using the suffixes
```
hr: short _Fract
uhr: unsigned short _Fract
r: _Fract
ur: unsigned _Fract
lr: long _Fract
ulr: unsigned long _Fract
hk: short _Accum
uhk: unsigned short _Accum
k: _Accum
uk: unsigned _Accum
```
Errors are also thrown for illegal literal values
```
unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
```
Differential Revision: https://reviews.llvm.org/D46915
llvm-svn: 335148
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.
The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse, and therefore printed in the wrong order by
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.
The change unfortunately has some secondary effects, especially for
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attribute's order was changed instead.
It also causes some 'previous occurrence here' hints to be textually
after the main marker. This typically happens when attributes are
merged, but are incompatible. Interchanging the role of the the main
and note SourceLocation will also cause the case where two different
declaration's attributes (in contrast to multiple attributes of the
same declaration) are merged to be reversed. There is no easy fix
because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway, which often is on the same line.
Differential Revision: https://reviews.llvm.org/D48100
llvm-svn: 335084
This diff includes changes for the remaining _Fract and _Sat fixed point types.
```
signed short _Fract s_short_fract;
signed _Fract s_fract;
signed long _Fract s_long_fract;
unsigned short _Fract u_short_fract;
unsigned _Fract u_fract;
unsigned long _Fract u_long_fract;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
short _Fract short_fract;
_Fract fract;
long _Fract long_fract;
// Saturated fixed point types
_Sat signed short _Accum sat_s_short_accum;
_Sat signed _Accum sat_s_accum;
_Sat signed long _Accum sat_s_long_accum;
_Sat unsigned short _Accum sat_u_short_accum;
_Sat unsigned _Accum sat_u_accum;
_Sat unsigned long _Accum sat_u_long_accum;
_Sat signed short _Fract sat_s_short_fract;
_Sat signed _Fract sat_s_fract;
_Sat signed long _Fract sat_s_long_fract;
_Sat unsigned short _Fract sat_u_short_fract;
_Sat unsigned _Fract sat_u_fract;
_Sat unsigned long _Fract sat_u_long_fract;
// Aliased saturated fixed point types
_Sat short _Accum sat_short_accum;
_Sat _Accum sat_accum;
_Sat long _Accum sat_long_accum;
_Sat short _Fract sat_short_fract;
_Sat _Fract sat_fract;
_Sat long _Fract sat_long_fract;
```
This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches.
Differential Revision: https://reviews.llvm.org/D46911
llvm-svn: 334718
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.
Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".
Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.
Reviewers: zturner, erik.pilkington
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47887
llvm-svn: 334399
Avoid storing information for definitions since those can be out-of-line and
vary between modules even when the declarations are the same.
llvm-svn: 334151
When looking up a template name, we can find an overload set containing a
function template and an unresolved non-type using declaration.
llvm-svn: 334106
For pointer assignments of VLA types, Clang currently detects when array
dimensions _lower_ than a variable dimension differ, and reports a warning.
However it does not do the same when the _higher_ dimensions differ, a
case that GCC does catch.
These two pointer types
int (*foo)[1][bar][3];
int (*baz)[1][2][3];
are compatible with each another, and the program is well formed if
bar == 2, a matter that is the programmers problem. However the following:
int (*qux)[2][2][3];
would not be compatible with either, because the upper dimension differs
in size. Clang reports baz is incompatible with qux, but not that foo is
incompatible with qux because it doesn't check those higher dimensions.
Fix this by comparing array sizes on higher dimensions: if both are
constants but unequal then report incompatibility; if either dimension is
variable then we can't know either way.
Differential Revision: https://reviews.llvm.org/D47628
llvm-svn: 333989
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Fixed the test that was failing by not checking for dso_local on some
targets.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333923
```
// Primary fixed point types
signed short _Accum s_short_accum;
signed _Accum s_accum;
signed long _Accum s_long_accum;
unsigned short _Accum u_short_accum;
unsigned _Accum u_accum;
unsigned long _Accum u_long_accum;
// Aliased fixed point types
short _Accum short_accum;
_Accum accum;
long _Accum long_accum;
```
This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches.
The tests included are for asserting that we can declare these types.
Differential Revision: https://reviews.llvm.org/D46084
llvm-svn: 333814
Compiler crashes when omp simd is used in an OpenCL file:
clang -c -fopenmp omp_simd.cl
__kernel void test(global int *data, int size) {
#pragma omp simd
for (int i = 0; i < size; ++i) {
}
}
The problem seems to be the check added to verify block pointers have
initializers. An OMPCapturedExprDecl is created to capture ‘size’ but there is
no TypeSourceInfo.
The change just uses getType() directly.
Patch-By: mikerice
Differential Revision: https://reviews.llvm.org/D46667
llvm-svn: 333746
Ensure latest MPT decl has a MSInheritanceAttr when instantiating
templates, to avoid null MSInheritanceAttr deref in
CXXRecordDecl::getMSInheritanceModel().
See PR#37399 for repo / details.
Patch by Andrew Rogers!
Differential Revision: https://reviews.llvm.org/D46664
llvm-svn: 333680
Summary:
When a CXXRecordDecl under ClassTemplateDecl is imported, check
the templated record decl for similarity instead of the template.
Reviewers: a.sidorin
Reviewed By: a.sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47313
Patch by Balazs Keri!
llvm-svn: 333522
Summary:
ClassTemplateSpecialization is put in the wrong DeclContex if implicitly
instantiated. This patch fixes it.
Reviewers: a.sidorin, r.stahl, xazax.hun
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47058
llvm-svn: 333269
unusual types.
Following the observed behavior of GCC, we now return -1 for vector types
(along with all of our extensions that GCC doesn't support), and for atomic
types we classify the underlying type.
GCC appears to have changed its classification for function and array arguments
between version 5 and version 6. Previously it would classify them as pointers
in C and as functions or arrays in C++, but from version 6 onwards, it
classifies them as pointers. We now follow the more recent GCC behavior rather
than emulating what I can only assume to be a historical bug in their C++
support for this builtin.
Finally, no version of GCC that I can find has ever used the "method"
classification for C++ pointers to member functions. Instead, GCC classifies
them as record types, presumably reflecting an internal implementation detail,
but whatever the reason we now produce compatible results.
llvm-svn: 333126
Summary:
Currently we do not import the implicit CXXRecordDecl of a
ClassTemplateSpecializationDecl. This patch fixes it.
Reviewers: a.sidorin, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47057
llvm-svn: 333086
Summary:
We fail to import a `ClassTemplateDecl` if the "To" context already
contains a definition and then a forward decl. This is because
`localUncachedLookup` does not find the definition. This is not a
lookup error, the parser behaves differently than assumed in the
importer code. A `DeclContext` contains one DenseMap (`LookupPtr`)
which maps names to lists. The list is a special list `StoredDeclsList`
which is optimized to have one element. During building the initial
AST, the parser first adds the definition to the `DeclContext`. Then
during parsing the second declaration (the forward decl) the parser
again calls `DeclContext::addDecl` but that will not add a new element
to the `StoredDeclsList` rarther it simply overwrites the old element
with the most recent one. This patch fixes the error by finding the
definition in the redecl chain. Added tests for the same issue with
`CXXRecordDecl` and with `ClassTemplateSpecializationDecl`. These tests
pass and they pass because in `VisitRecordDecl` and in
`VisitClassTemplateSpecializationDecl` we already use
`D->getDefinition()` after the lookup.
Reviewers: a.sidorin, xazax.hun, szepet
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D46950
llvm-svn: 333082
If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
resources. It causes strange behavior from user viewpoint: compilation
of huge zero initialized arrays like:
char data_1[2147483648u] = { 0 };
consumes enormous amount of time and memory.
With this change codegen tries to determine if variable initializer is
equivalent to zero initializer. In this case variable value is not
constructed.
This change fixes PR18978.
Differential Revision: https://reviews.llvm.org/D46241
llvm-svn: 332847
MethodVFTableLocations in MigrosoftVTableContext contains canonicalized
decl. But, it's sometimes asked to lookup for non-canonicalized decl,
and that causes assertion failure, and compilation failure.
Fixes PR37481.
Patch by Taiju Tsuiki!
Differential Revision: https://reviews.llvm.org/D46929
llvm-svn: 332639
Summary:
Previously this triggered a -Wundefined-internal warning. But it's not
an undefined variable -- any variable of this form is a pointer to the
base of GPU core's shared memory.
Reviewers: tra
Subscribers: sanjoy, rsmith
Differential Revision: https://reviews.llvm.org/D46782
llvm-svn: 332621
E. g. use "10.11" instead of "10_11".
We are maintaining backward compatibility by parsing underscore-delimited version tuples but no longer keep track of the separator and using dot format for output.
Differential Revision: https://reviews.llvm.org/D46747
rdar://problem/39845032
llvm-svn: 332598
Summary:
Implicit CXXRecordDecl is not added to its DeclContext during import, but in
the original AST it is. This patch fixes this.
Reviewers: xazax.hun, a.sidorin, szepet
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D46958
llvm-svn: 332588
Summary:
The helper is used in clangd for documentation shown in code completion
and storing the docs in the symbols. See D45999.
This patch reuses the code of the Doxygen comment lexer, disabling the
bits that do command and html tag parsing.
The new helper works on all comments, including non-doxygen comments.
However, it does not understand or transform any doxygen directives,
i.e. cannot extract brief text, etc.
Reviewers: sammccall, hokein, ioeric
Reviewed By: ioeric
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D46000
llvm-svn: 332458
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
During import of a class template, lookup may find a forward
declaration and structural match falsely reports equivalency
between a forward decl and a definition. The result is that
some definitions are not imported if we had imported a forward
decl previously. This patch gives a fix.
Patch by Gabor Marton!
Differential Revision: https://reviews.llvm.org/D46353
llvm-svn: 332338
For example, given:
struct T1 {
struct T2 *p0;
};
-ast-print produced:
struct T1 {
struct T2;
struct T2 *p0;
};
Compiling that produces a warning that the first struct T2 declaration
does not declare anything.
Details:
A tag decl group is one or more decls that share a type specifier that
is a tag decl (that is, a struct/union/class/enum decl). Within
functions, the parser builds such a tag decl group as part of a
DeclStmt. However, in decl contexts, such as file scope or a member
list, the parser does not group together the members of a tag decl
group. Previously, detection of tag decl groups during printing was
implemented but only if the tag decl was unnamed. Otherwise, as in
the above example, the members of the group did not print together and
so sometimes introduced warnings.
This patch extends detection of tag decl groups in decl contexts to
any tag decl that is recorded in the AST as not free-standing.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D45465
llvm-svn: 332314
For example, given:
void fn() {
struct T *p0;
struct T { int i; } *p1;
}
-ast-print produced:
void fn() {
struct T { int i; } *p0;
struct T { int i; } *p1;
}
Compiling that fails with a redefinition error.
Given:
void fn() {
struct T *p0;
struct __attribute__((deprecated)) T *p1;
}
-ast-print dropped the attribute.
Details:
For a tag specifier (that is, struct/union/class/enum used as a type
specifier in a declaration) that was also a tag declaration (that is,
first occurrence of the tag) or tag redeclaration (that is, later
occurrence that specifies attributes or a member list), clang printed
the tag specifier as either (1) the full tag definition if one
existed, or (2) the first tag declaration otherwise. Redefinition
errors were sometimes introduced, as in the first example above. Even
when that was impossible because no member list was ever specified,
attributes were sometimes lost, thus changing semantics and
diagnostics, as in the second example above.
This patch fixes a major culprit for these problems. It does so by
creating an ElaboratedType with a new OwnedDecl member wherever an
occurrence of a tag type is a (re)declaration of that tag type.
PrintingPolicy's IncludeTagDefinition used to trigger printing of the
member list, attributes, etc. for a tag specifier by using a tag
(re)declaration selected as described above. Now, it triggers the
same thing except it uses the tag (re)declaration stored in the
OwnedDecl. Of course, other tooling can now make use of the new
OwnedDecl as well.
Also, to be more faithful to the original source, this patch
suppresses printing of attributes inherited from previous
declarations.
Reviewed by: rsmith, aaron.ballman
Differential Revision: https://reviews.llvm.org/D45463
llvm-svn: 332281
These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering.
Updated the clang-extensions document.
Differential Revision: https://reviews.llvm.org/D46386
llvm-svn: 332193
Added string literal helper function to obtain the type
attributed by a constant address space.
Also fixed predefind __func__ expr to use the helper
to constract the string literal correctly.
Differential Revision: https://reviews.llvm.org/D46049
llvm-svn: 331877
Summary:
An _Atomic of an empty struct is pretty silly. In general we just widen empty
structs to hold a byte's worth of storage, and we represent size and alignment
as 0 internally and let LLVM figure out what to do. For _Atomic it's a bit
different: the memory model mandates concrete effects occur when atomic
operations occur, so in most cases actual instructions need to get emitted. It's
really not worth trying to optimize empty struct atomics by figuring out e.g.
that a fence would do, even though sane compilers should do optimize atomics.
Further, wg21.link/p0528 will fix C++20 atomics with padding bits so that
cmpxchg on them works, which means that we'll likely need to do the zero-init
song and dance for empty atomic structs anyways (and I think we shouldn't
special-case this behavior to C++20 because prior standards are just broken).
This patch therefore makes a minor change to r176658 "Promote atomic type sizes
up to a power of two": if the width of the atomic's value type is 0, just use 1
byte for width and leave alignment as-is (since it should never be zero, and
over-aligned zero-width structs are weird but fine).
This fixes an assertion:
(NumBits >= MIN_INT_BITS && "bitwidth too small"), function get, file ../lib/IR/Type.cpp, line 241.
It seems like this has run into other assertions before (namely the unreachable
Kind check in ImpCastExprToType), but I haven't reproduced that issue with
tip-of-tree.
<rdar://problem/39678063>
Reviewers: arphaman, rjmccall
Subscribers: aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D46613
llvm-svn: 331845
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
This patch addresses some mostly trivial post-commit review comments received
on r331677.
Additionally, this patch fixes an assertion in `getNarrowingKind` caused by
the use of an uninitialized value from `checkThreeWayNarrowingConversion`.
llvm-svn: 331707
In order to match our mangling scheme, use a different set of numbers for
decomposition declarations, and consider all binding names when forming the
numbering. This does not yet affect any mangled names we produce, because
local decomposition declarations can't yet have linkage, but a C++ standard
proposal to change that is currently being processed.
llvm-svn: 331692
Summary:
This patch tackles long hanging fruit for the builtin operator<=> expressions. It is currently needs some cleanup before landing, but I want to get some initial feedback.
The main changes are:
* Lookup, build, and store the required standard library types and expressions in `ASTContext`. By storing them in ASTContext we don't need to store (and duplicate) the required expressions in the BinaryOperator AST nodes.
* Implement [expr.spaceship] checking, including diagnosing narrowing conversions.
* Implement `ExprConstant` for builtin spaceship operators.
* Implement builitin operator<=> support in `CodeGenAgg`. Initially I emitted the required comparisons using `ScalarExprEmitter::VisitBinaryOperator`, but this caused the operand expressions to be emitted once for every required cmp.
* Implement [builtin.over] with modifications to support the intent of P0946R0. See the note on `BuiltinOperatorOverloadBuilder::addThreeWayArithmeticOverloads` for more information about the workaround.
Reviewers: rsmith, aaron.ballman, majnemer, rnk, compnerd, rjmccall
Reviewed By: rjmccall
Subscribers: rjmccall, rsmith, aaron.ballman, junbuml, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D45476
llvm-svn: 331677
The visit callback implementations for the 3 C++ AST Node added to the ASTImporter.
Differential Revision: https://reviews.llvm.org/D38845
llvm-svn: 331630
This implements the rule intended by the standard (see LWG 2358)
and the rule intended by the Itanium C++ ABI (see
https://github.com/itanium-cxx-abi/cxx-abi/pull/51), and makes
Clang match the behavior of GCC, ICC, and MSVC.
A pedantic reading of both the standard and the ABI indicate that Clang
is currently technically correct, but that's not worth much when it's
clear that the wording is wrong in both those places.
This is an ABI break for classes that derive from a class that is empty
other than one or more unnamed non-zero-length bit-fields. Such cases
are expected to be rare, but -fclang-abi-compat=6 restores the old
behavior just in case.
Differential Revision: https://reviews.llvm.org/D45174
llvm-svn: 331620
FunctionProtoType.
We previously re-evaluated the expression each time we wanted to know whether
the type is noexcept or not. We now evaluate the expression exactly once.
This is not quite "no functional change": it fixes a crasher bug during AST
deserialization where we would try to evaluate the noexcept specification in a
situation where we have not deserialized sufficient portions of the AST to
permit such evaluation.
llvm-svn: 331428
the method declaration is unavailable for an app extension platform
Rationale:
Classes are often shared between an app extension code and
non-app extension code. There's no way to remove the implementation
using preprocessor when building the app extension, so we should not warn here.
rdar://38150617
llvm-svn: 331421
Do early return if we can't import the found decl for a member expr.
This follows the pre-existing scheme, e.g with E->getMemberDecl().
E->getFoundDecl().getDecl() can be null when a member expression does
not involve lookup. It may involve a lookup in case of a using directive
which refers to a member function in a base class template.
We faced this assert during the CTU analysis of google::protobuf v3.5.2.
We tried hard to synthesize a minimal test example both by hand and by
executing creduce on multiple files. Unfortunately, we were unable to reduce
to such a minimal example, yet. Nevertheless, this fix solved the problem in
protobuf.
To reproduce the error one must execute the analyzer with
-Xclang -analyzer-config -Xclang experimental-enable-naive-ctu-analysis=true -Xclang -analyzer-config -Xclang ctu-dir=/path/to/ctu_dir
Patch by Gabor Marton!
Differential Revision: https://reviews.llvm.org/D46019
llvm-svn: 331344
Half-type mangling is accomplished following the method introduced by Erich
Keane for mangling _Float16. Updated the half.cl LIT test to cover this
particular case.
Patch By: vbridgers
Differential Revision: https://reviews.llvm.org/D46131
llvm-svn: 331263
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
Clang incorrectly applied the packed attribute to base classes. Per GCC's
documentation and as can be observed from its behavior, packed only applies to
members, not base classes.
This change is conditioned behind -fclang-abi-compat so that an ABI break can
be avoided by users if desired.
Differential Revision: https://reviews.llvm.org/D46218
llvm-svn: 331136
We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.
Differential revision: https://reviews.llvm.org/D45451
llvm-svn: 331098
There are only a few cases of importing a frienddecl which is currently supported.
This patch aims to improve the friend import process.
Set FriendObjectKind in case of decls, insert friend into the friend chain
correctly, checks structurally equivalent in a more advanced manner.
Test cases added as well.
llvm-svn: 330847
This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly.
See the test file to get a sense of the basic parsing that this patch supports.
There is much more work to be done before concepts are usable...
Thanks Changyu!
llvm-svn: 330794
For example, given:
void fn() {
enum __attribute__((deprecated)) T *p;
}
-ast-print produced:
void fn() {
enum T __attribute__((deprecated(""))) *p;
}
-ast-print on that produced:
void fn() {
enum T *p __attribute__((deprecated("")));
}
The attribute is on enum T in the first case, but it's on p in the
other cases.
Details:
Within enum declarations, enum attributes were always printed after
the tag and any member list. When no member list was present but the
enum was a type specifier in a variable declaration, the attribute
then applied to the variable not the enum, changing the semantics.
This patch fixes that by always printing attributes between the enum's
keyword and tag, as clang already does for structs, unions, and
classes.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D45456
llvm-svn: 330722
This patch introduces the ability to test an arbitrary sequence of imports
between a given set of virtual source files. This should finally allow
us to write simple tests and fix annoying issues inside ASTImporter
that cause failures in CSA CTU. This is done by refactoring
ASTImporterTest functions and introducing `testImportSequence` facility.
As a side effect, `testImport` facility was generalized a bit more. It
should now allow import of non-decl AST nodes; however, there is still no
test using this ability.
As a "test for test", there is also a fix for import anonymous TagDecls
referred by typedef. Before this patch, the setting of typedef for anonymous
structure was delayed; however, this approach misses the corner case if
an enum constant is imported directly. In this patch, typedefs for
anonymous declarations are imported right after the anonymous declaration
is imported, without any delay.
Thanks to Adam Balogh for suggestions included into this patch.
Differential Revision: https://reviews.llvm.org/D44079
llvm-svn: 330704
This makes it return the right result in a couple of edge cases. The
wide versions always do the comparison on the underlying wchar_t type.
llvm-svn: 330656
Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.
This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953
Reviewers: rsmith, arphaman, doug.gregor
Reviewed By: doug.gregor
Subscribers: doug.gregor, cfe-commits
Differential Revision: https://reviews.llvm.org/D44670
llvm-svn: 330338
Enables _Float16 on Windows by creating a mangling
mechanism in MicrosoftMangle. It accomplishes this by
mangling as a structure type of __clang::_Float16, similar
to how Complex works.
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D45738
llvm-svn: 330225
As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033
Any usage of a builtin function that uses a va_list by reference
will cause an assertion when redeclaring it.
After discussion in the review, it was concluded that the correct
way of accomplishing this fix is to make attempts to redeclare certain
builtins an error. Unfortunately, doing this limitation for all builtins
is likely a breaking change, so this commit simply limits it to
types with custom type checking and those that take a reference.
Two tests needed to be updated to make this work.
Differential Revision: https://reviews.llvm.org/D45383
llvm-svn: 330160
Summary:
Clean carriage returns from lib/ and include/. NFC.
(I have to make this change locally in order for `git diff` to show sane output after I edit a file, so I might as well ask for it to be committed. I don't have commit privs myself.)
(Without this patch, `git rebase`ing any change involving SemaDeclCXX.cpp is a real nightmare. :( So while I have no right to ask for this to be committed, geez would it make my workflow easier if it were.)
Here's the command I used to reformat things. (Requires bash and OSX/FreeBSD sed.)
git grep -l $'\r' lib include | xargs sed -i -e $'s/\r//'
find lib include -name '*-e' -delete
Reviewers: malcolm.parsons
Reviewed By: malcolm.parsons
Subscribers: emaste, krytarowski, cfe-commits
Differential Revision: https://reviews.llvm.org/D45591
Patch by Arthur O'Dwyer.
llvm-svn: 330112
an APValue and retrieve it from map Temporaries.
The version number is needed when a single AST node is visited multiple
times and is used to create APValues that are required to be distinct
from each other (for example, MaterializeTemporaryExprs in default
arguments and VarDecls in loops).
rdar://problem/36505742
Differential Revision: https://reviews.llvm.org/D42776
llvm-svn: 329671
registers.
This patch fixes a bug in r328731 that caused structs transitively
containing __weak fields to be passed in registers. The patch replaces
the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates
whether the struct or structs containing the struct are forced to be
passed indirectly.
This reapplies r329617. r329617 didn't specify the underlying type for
enum ArgPassingKind, which caused regression tests to fail on a windows
bot.
rdar://problem/39194693
Differential Revision: https://reviews.llvm.org/D45384
llvm-svn: 329635
registers.
This patch fixes a bug in r328731 that caused structs transitively
containing __weak fields to be passed in registers. The patch replaces
the flag RecordDecl::CanPassInRegisters with a 2-bit enum that indicates
whether the struct or structs containing the struct are forced to be
passed indirectly.
rdar://problem/39194693
llvm-svn: 329617
Summary:
This change consolidates the always/never lists that may be provided to
clang to externally control which functions should be XRay instrumented
by imbuing attributes. The files follow the same format as defined in
https://clang.llvm.org/docs/SanitizerSpecialCaseList.html for the
sanitizer blacklist.
We also deprecate the existing `-fxray-instrument-always=` and
`-fxray-instrument-never=` flags, in favour of `-fxray-attr-list=`.
This fixes http://llvm.org/PR34721.
Reviewers: echristo, vlad.tsyrklevich, eugenis
Reviewed By: vlad.tsyrklevich
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D45357
llvm-svn: 329543
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
layout" rules.
The new rules say that a standard-layout struct has its first non-static
data member and all base classes at offset 0, and consider a class to
not be standard-layout if that would result in multiple subobjects of a
single type having the same address.
We track "is C++11 standard-layout class" separately from "is
standard-layout class" so that the ABIs that need this information can
still use it.
Differential Revision: https://reviews.llvm.org/D45176
llvm-svn: 329332
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).
Fixes PR18538.
Reviewers: rjmccall, rsmith, chandlerc
Reviewed By: rsmith, chandlerc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D45289
llvm-svn: 329300
Previously UnaryTransformType nodes were comparing the same node
for structural equivalence. This was due to a typo where T1 was
on both sides of the comparison. This patch corrects that typo.
Unfortunately I couldn't find a way to test this change. It seems
that currently UnaryTransform nodes are never actually checked
for equivalence, only their canonical types are.
None the less, this correction seemed appropriate.
llvm-svn: 329151
This reverts r328795 which introduced an issue with referencing __global__
function templates. More details in the original review D44747.
llvm-svn: 329099
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime. Add support for this. This allows the swift runtime to
be built for Windows again.
llvm-svn: 329025
This re-lands r328845 with fixes for crbug.com/827810.
The initial motiviation was to hoist MethodVFTableLocation to global
scope so it could be forward declared.
In this patch, I noticed that MicrosoftVTableContext uses some risky
patterns. It has methods that return references to data stored in
DenseMaps. I've made some of them return by value for trivial structs
and I've moved some things into separate allocations.
llvm-svn: 329007
commit 519b97132a4c960e8dedbfe4290d86970d92e995
Author: Richard Trieu <rtrieu@google.com>
Date: Sat Mar 24 00:52:44 2018 +0000
[ODRHash] Support pointer and reference types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328404 91177308-0d34-0410-b5e6-96231b3b80d8
As it's breaking some tests. I've communicated with Richard offline about testcases.
llvm-svn: 329001
This allows forward declaring it so that we can add it to
MicrosoftMangleContext::mangleVirtualMemPtrThunk without including
VTableBuilder.h. That saves a hashtable lookup when emitting virtual
member pointer functions.
It also shortens a really long type name. This struct has "VFtable" in
the name, so it seems pretty unlikely that someone will assume it is
generally useful for non-MS C++ ABI stuff.
llvm-svn: 328845
This patch sets target specific calling convention for CUDA kernels in IR.
Patch by Greg Rodgers.
Revised and lit test added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D44747
llvm-svn: 328795
ObjC and ObjC++ pass non-trivial structs in a way that is incompatible
with each other. For example:
typedef struct {
id f0;
__weak id f1;
} S;
// this code is compiled in c++.
extern "C" {
void foo(S s);
}
void caller() {
// the caller passes the parameter indirectly and destructs it.
foo(S());
}
// this function is compiled in c.
// 'a' is passed directly and is destructed in the callee.
void foo(S a) {
}
This patch fixes the incompatibility by passing and returning structs
with __strong or weak fields using the C ABI in C++ mode. __strong and
__weak fields in a struct do not cause the struct to be destructed in
the caller and __strong fields do not cause the struct to be passed
indirectly.
Also, this patch fixes the microsoft ABI bug mentioned here:
https://reviews.llvm.org/D41039?id=128767#inline-364710
rdar://problem/38887866
Differential Revision: https://reviews.llvm.org/D44908
llvm-svn: 328731
We were assuming that vbtable indices were assigned in layout order in
our comparison, which is not the case. When a virtual method, such as
the destructor, appears in multiple vftables, the vftable that appears
first in object layout order is the one that points to the main
implementation of that method. The later vftables use thunks.
In this layout, we adjusted "this" in the main implementation by the
amount that is appropriate for 'B' instead of 'A', even though the main
implementation is found in D's vftable for A:
struct A {
virtual ~A() {}
};
struct B {
virtual ~B() {}
};
struct C : virtual B {};
struct D : virtual A, C {};
D's layout looks like:
0 D subobject (empty)
0 C base suboject
8 A base subobject
16 B base subobject
With this fix, we correctly adjust by -8 in D's deleting destructor
instead of -16.
Fixes PR36921.
llvm-svn: 328723
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
Previously, anytime the result of the resume expression in
operator co_await was unused, a warning was generated. This
patch fixes the issue by only generating the unused result warning
if calling `await_resume()` would also generate a warning.
llvm-svn: 328602
If the link clause is used on the declare target directive, the object
should be linked on target or target data directives, not during the
codegen. Patch adds support for this clause.
llvm-svn: 328544
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
This recommits r327206, which was reverted because it caused
module-enabled builders to fail. I discovered that the
CXXRecordDecl::CanPassInRegisters flag wasn't being set correctly in
some cases after I moved it to RecordDecl.
Thanks to Eric Liu for helping me investigate the bug.
rdar://problem/33599681
https://reviews.llvm.org/D44095
llvm-svn: 327870
The patch adds nocf_check target independent attribute for disabling checks that were enabled by cf-protection flag.
The attribute can be appertained to functions and function pointers.
Attribute name follows GCC's similar attribute name.
Differential Revision: https://reviews.llvm.org/D41880
llvm-svn: 327768
More generally, this permits a template to be specialized in any scope in which
it could be defined, so this also supersedes DR44 and DR374 (the latter of
which we previously only implemented in C++11 mode onwards due to unclarity as
to whether it was a DR).
llvm-svn: 327705
Added initial codegen for device side of declarations inside `omp
declare target` construct + codegen for implicit `declare target`
functions, which are used in the target regions.
llvm-svn: 327636
This patch uses the infrastructure added in r326307 for enabling
non-trivial fields to be declared in C structs to allow __weak fields in
C structs in ARC.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44095
llvm-svn: 327206
Previously, iteration through nil objects which resulted from
objc-messages being set to nil were modeled incorrectly.
There are a couple of notes about this patch:
In principle, ExprEngineObjC might be left untouched IFF osx.loops
checker is enabled.
I however think that we should not do something
completely incorrect depending on what checkers are left on.
We should evaluate and potentially remove altogether the isConsumedExpr
performance heuristic, as it seems very fragile.
rdar://22205149
Differential Revision: https://reviews.llvm.org/D44178
llvm-svn: 326982
We already have a mangling for the __unaligned qualifier, we just have
to call Qualifiers::getFromCVRUMask instead of getFromCVRMask.
PR36638
llvm-svn: 326971
The original revert was done in r326869, since reverting r326602 broke
the test added by this.
The new test should be less dependent on r326602.
llvm-svn: 326872
The patch fixes a number of bugs related to parameter indexing in
attributes:
* Parameter indices in some attributes (argument_with_type_tag,
pointer_with_type_tag, nonnull, ownership_takes, ownership_holds,
and ownership_returns) are specified in source as one-origin
including any C++ implicit this parameter, were stored as
zero-origin excluding any this parameter, and were erroneously
printing (-ast-print) and confusingly dumping (-ast-dump) as the
stored values.
* For alloc_size, the C++ implicit this parameter was not subtracted
correctly in Sema, leading to assert failures or to silent failures
of __builtin_object_size to compute a value.
* For argument_with_type_tag, pointer_with_type_tag, and
ownership_returns, the C++ implicit this parameter was not added
back to parameter indices in some diagnostics.
This patch fixes the above bugs and aims to prevent similar bugs in
the future by introducing careful mechanisms for handling parameter
indices in attributes. ParamIdx stores a parameter index and is
designed to hide the stored encoding while providing accessors that
require each use (such as printing) to make explicit the encoding that
is needed. Attribute declarations declare parameter index arguments
as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This
patch rewrites all attribute arguments that are processed by
checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared
as [Variadic]ParamIdxArgument. The only exception is xray_log_args's
argument, which is encoded as a count not an index.
Differential Revision: https://reviews.llvm.org/D43248
llvm-svn: 326602
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc
comments or not.
2. "Maybe-doc" comments, like <, !, etc, are saved as such, instead of marking
them as ordinary comments. The maybe-doc type of comment is never saved
otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Subscribers: cfe-commits
llvm-svn: 326512
Original change:
[NFC] Move CommentOpts checks to the call sites that depend on it.
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc comments or not.
2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of marking them as ordinary comments. The maybe-doc type of comment is never saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
llvm-svn: 326508
When parsing comments, for example, for -Wdocumentation, slightly different
behaviour occurs when -fparse-all-comments is specified. However, these
differences are subtle:
1. All comments are saved during parsing, regardless of whether they are doc
comments or not.
2. "Maybe-doc" comments, like //<, //!, etc, are saved as such, instead of
marking them as ordinary comments. The maybe-doc type of comment is never
saved otherwise. (Warning on these is the impetus of -Wdocumentation.)
3. All comments are treated as doc comments in ASTContext, even if they are
ordinary.
This change moves the logic for checking CommentOptions.ParseAllComments closer
to where it has an effect. The overall logic is unchanged, but checks of the
ParseAllComments flag are now done where the effect will be clearer.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43663
llvm-svn: 326501
Make types with sizes that aren't a power of two an error (that can
be disabled) in structs with ms_struct layout, except on mingw where
the situation is quite likely to occur and GCC handles it silently.
Differential Revision: https://reviews.llvm.org/D43908
llvm-svn: 326476
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and
`dyn_cast`s for fun. This is a portion of what it found for clang; I
plan to do similar cleanups in LLVM and other subprojects when I find
time.
Because of the volume of changes, I explicitly avoided making any change
that wasn't highly local and obviously correct to me (e.g. we still have
a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading
is a thing and the cast<Bar> did actually change the type -- just up the
class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby,
in cases where it wasn't locally obvious what we were dealing with
before.
llvm-svn: 326416
ARC mode.
Declaring __strong pointer fields in structs was not allowed in
Objective-C ARC until now because that would make the struct non-trivial
to default-initialize, copy/move, and destroy, which is not something C
was designed to do. This patch lifts that restriction.
Special functions for non-trivial C structs are synthesized that are
needed to default-initialize, copy/move, and destroy the structs and
manage the ownership of the objects the __strong pointer fields point
to. Non-trivial structs passed to functions are destructed in the callee
function.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D41228
llvm-svn: 326307
Specifically, we would not properly parse these types within template arguments
(for non-type template parameters), and in tentative parses. Fixing both of
these essentially requires that we parse deduced template specialization types
as types in all contexts, even in template argument lists -- in particular,
tentative parsing may look ahead and annotate a deduced template specialization
type before we figure out that we're actually supposed to treat the tokens as a
template-name. We deal with this by simply permitting deduced template
specialization types when parsing template arguments, and converting them to
template template arguments.
llvm-svn: 326299
When targeting GNU/MinGW for i386, the size of the "long double" data
type is 12 bytes (while it is 8 bytes in MSVC). When building
with -mms-bitfields to have struct layouts match MSVC, data types
are laid out in a struct with alignment according to their size.
However, this doesn't make sense for the long double type, since
it doesn't match MSVC at all, and aligning to a non-power-of-2
size triggers other asserts later.
This matches what GCC does, aligning a long double to 4 bytes
in structs on i386 even when -mms-bitfields is specified.
This fixes asserts when using the max_align_t data type when
building for MinGW/i386 with the -mms-bitfields flag.
Differential Revision: https://reviews.llvm.org/D43734
llvm-svn: 326173
When indirect field is initialized with another field, you have
MemberExpr with CXXThisExpr that corresponds to the field's immediate
anonymous parent. But 'this' was referring to the non-anonymous parent.
So when we were building LValue Designator, it was incorrect as it had
wrong starting point. Usage of such designator would cause unexpected
APValue changes and crashes.
The fix is in adjusting 'this' for indirect fields from non-anonymous
parent to the field's immediate parent.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4985
rdar://problem/36359187
Reviewers: rsmith, efriedma
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple
Differential Revision: https://reviews.llvm.org/D42498
llvm-svn: 325997
Build the index off of DeclarationName instead of Decl pointers. When finding
an UnresolvedLookupExprClass, hash it as if it were a DeclRefExpr. This will
allow methods to be hashed.
llvm-svn: 325741
expressions, if their lifetime began during the evaluation of the expression.
This is technically not allowed in C++11, though we could consider permitting
it there too, as an extension.
llvm-svn: 325663
If the value returned by `malloc`, `calloc` or `realloc` is not checked
for null pointer, this change replaces them for `safe_malloc`,
`safe_calloc` or `safe_realloc`, which are defined in the namespace `llvm`.
These function report fatal error on out of memory.
In the plain C files, assertion statements are added to ensure that memory
is successfully allocated.
The aim of this change is to get better diagnostics of OOM on Windows.
Differential Revision: https://reviews.llvm.org/D43017
llvm-svn: 325661
This broke Clang bootstrap on Windows, PR36453.
> This handles them exactly the same way that we handle const integral
> static data members with inline definitions, which is what MSVC does.
>
> As a follow-up, now that we have a way to mark variables inline in the
> AST, we should consider marking them implicitly inline there instead of
> only treating them as inline in CodeGen. Unfortunately, this breaks a
> lot of dllimport test cases, so that is future work for now.
>
> Fixes PR36125.
llvm-svn: 325576
This handles them exactly the same way that we handle const integral
static data members with inline definitions, which is what MSVC does.
As a follow-up, now that we have a way to mark variables inline in the
AST, we should consider marking them implicitly inline there instead of
only treating them as inline in CodeGen. Unfortunately, this breaks a
lot of dllimport test cases, so that is future work for now.
Fixes PR36125.
llvm-svn: 325375
Summary:
-ast-print prints omp pragmas with a trailing space. While this
behavior is likely of little concern to most users, surely it's
unintentional, and it's annoying for some source-level work I'm
pursuing. This patch focuses on omp pragmas, but it also fixes
init_seg and loop hint pragmas because they share implementation.
The testing strategy here is to add usually just one '{{$}}' per
relevant -ast-print test file. This seems to achieve good code
coverage. However, this strategy is probably easy to forget as the
tests evolve. That's probably fine as this fix is far from critical.
The main goal of the testing is to aid the initial review.
This patch also adds a fixme for "#pragma unroll", which prints as
"#pragma unroll (enable)", which is invalid syntax.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: guansong, cfe-commits
Differential Revision: https://reviews.llvm.org/D43204
llvm-svn: 325145
This patch fixes clang to not consider braced initializers for
aggregate elements of arrays to be potentially dependent on the
indices of the initialized elements. Resolves bug 18978:
initialize a large static array = clang oom?
https://bugs.llvm.org/show_bug.cgi?id=18978
Differential Revision: https://reviews.llvm.org/D43187
llvm-svn: 325120
Summary:
This fixes a flaw in our AST: PR27098
MSVC always gives plain enums the underlying type 'int'. Clang does this
as well, but we claim the enum is "fixed", as if the user actually wrote
': int'. It means we end up emitting spurious -Wsign-compare warnings on
code like this:
enum Vals { E1, E2, E3 };
bool f(unsigned v1, Vals v2) {
return v1 == v2;
}
We think 'v2' can take on negative values because we think 'Vals' is
fixed. This fixes that.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43110
llvm-svn: 324913
Adjust the ObjC protocol conformance workaround to be more extensible.
Use a synthetic type for the protocol (`struct Protocol`). Embed this
within a reserved namespace to permit extending the extended pointer
type qualifiers similarly for ObjC lifetime qualifiers.
Introduce additional special handling for `__autoreleasing`, `__strong`,
and `__weak` Objective C lifetime qualifiers. We decorate these by
creating an artificial template type `Autoreleasing`, `Strong`, or
`Weak` in the `__ObjC` namespace. These are only considered in the
template type specialization and not the function parameter.
llvm-svn: 324701
Microsoft has reserved the identifier 'S' as the swift calling
convention. Decorate the symbols appropriately. This enables swift on
Windows.
llvm-svn: 324439
The 'trivial_abi' attribute can be applied to a C++ class, struct, or
union. It makes special functions of the annotated class (the destructor
and copy/move constructors) to be trivial for the purpose of calls and,
as a result, enables the annotated class or containing classes to be
passed or returned using the C ABI for the underlying type.
When a type that is considered trivial for the purpose of calls despite
having a non-trivial destructor (which happens only when the class type
or one of its subobjects is a 'trivial_abi' class) is passed to a
function, the callee is responsible for destroying the object.
For more background, see the discussions that took place on the mailing
list:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.htmlhttp://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043
rdar://problem/35204524
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 324269
Summary:
Clang incorrectly reports empty unions as having a unique object representation. However, this is not correct since `sizeof(EmptyUnion) == 1` AKA it has 8 bits of padding. Therefore it should be treated the same as an empty struct and report `false`.
@erichkeane also suggested this fix should be merged into the 6.0 release branch, so the initial release of `__has_unique_object_representations` is as bug-free as possible.
Reviewers: erichkeane, rsmith, aaron.ballman, majnemer
Reviewed By: erichkeane
Subscribers: cfe-commits, erichkeane
Differential Revision: https://reviews.llvm.org/D42863
llvm-svn: 324134
The patch ensures that a new storage unit is created when the new bitfield's
size is wider than the available bits.
rdar://36343145
Differential Revision: https://reviews.llvm.org/D42660
llvm-svn: 323921
Add support for mangling ObjC protocol conformances in MS ABI as if they are
COM interfaces. By diverging from the itanium mangling of `objc_protocol`
prefixed names, this approach allows for a semi-reasonable, albeit of
questionable sanity, undecoration via existing tooling. There is also the
possibility of adding an extension and taking part of the namespace to add the
conformance via the `L` and `Z` "modifiers", but the existing tooling would not
be able to properly undecorated the symbol even though incidentally `undname`
currently produces something legible while wine's implementation is not able to
cope with the extension.
This allows for the disambiguation of overloads where the parameter differs
only in the protocol conformance of the ObjC type, e.g.
```
@protocol P;
void f(std::vector<id>);
void f(std::vector<id<P>>);
```
which clang would previously fail due to the mangling being identical as the
protocol conformance was ignored.
llvm-svn: 323547
We can stash the cached transparent tag bit in existing pointer padding.
Everything coming out of ASTContext is always aligned to a multiple of
8, so we have 8 spare bits.
llvm-svn: 323528
Also, a number of style and bug fixes was done:
* ASTImporterTest: added sanity check for source node
* ExternalASTMerger: better lookup for template specializations
* ASTImporter: don't add templated declarations into DeclContext
* ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations
* ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc
Differential Revision: https://reviews.llvm.org/D42301
llvm-svn: 323519
We would previously treat `SEL` as a pointer-only type. This is not the
case. It should be treated similarly to `id` and `Class`. Add some
test cases to ensure that it will be properly handled as well.
llvm-svn: 323257
Rather than hardcode the pointerness of the `id` and `class` types,
handle them generically. This allows for the template type
specialization of `remove_pointer<id>` which would look through the `id`
type and deal with the `objc_object` structure without the pointer.
llvm-svn: 323241
We should (almost) never consider a device-side declaration to match a
library builtin functio. Otherwise clang may ignore the implementation
provided by the CUDA headers and emit clang's idea of the builtin.
Differential Revision: https://reviews.llvm.org/D42319
llvm-svn: 323239
Using a BlockDecl in a default member initializer causes it to be attached to
CXXMethodDecl without its access specifier being set. This prevents a crash
where getAccess is called on this BlockDecl, since that method expects any
Decl in CXXRecord scope to have an access specifier.
llvm-svn: 322984
Both are related to handling anonymous structures.
* clang didn't handle () around an anonymous struct variable.
* clang also crashed on syntax errors that could lead to other
syntactic constructs following the declaration of an
anonymous struct. While the code is invalid, that's not
a good reason to panic compiler.
Differential Revision: https://reviews.llvm.org/D41788
llvm-svn: 322742
Summary:
noload_lookups() was too lazy: in addition to avoiding external decls, it
avoided populating the lazy lookup structure for internal decls.
This is the right behavior for the existing callsite in ASTDumper, but I think
it's not a very useful default, so we populate it by default.
While here:
- remove an unused test file accidentally added in r322371.
- remove lookups_begin()/lookups_end() in favor of lookups().begin(), which is
more common and more efficient.
Reviewers: ilya-biryukov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D42077
llvm-svn: 322548
getAssociatedStmt() returns the outermost captured statement for the
OpenMP directive. It may return incorrect region in case of combined
constructs. Reworked the code to reduce the number of calls of
getAssociatedStmt() and used getInnermostCapturedStmt() and
getCapturedStmt() functions instead.
In case of firstprivate variables it may lead to an extra allocas
generation for private copies even if the variable is passed by value
into outlined function and could be used directly as private copy.
llvm-svn: 322393
In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.
llvm-svn: 322350
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
These just overloads for _Float128. They're supported by GCC 7 and used
by glibc. APFloat support is already there so just add the overloads.
__builtin_copysignf128
__builtin_fabsf128
__builtin_huge_valf128
__builtin_inff128
__builtin_nanf128
__builtin_nansf128
This is the same support that GCC has, according to the documentation,
but limited to _Float128.
llvm-svn: 321948
Attempting to recompute it are doomed to fail because the IDNS of a declaration
is not necessarily preserved across serialization and deserialization (in turn
because whether a friend declaration is visible depends on whether some prior
non-friend declaration exists).
llvm-svn: 321921
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
To remove exception specifications from types, the existing internal
ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places
otherwise unrelated to this change have been adapted to call it, too.
This is the cfe part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321859
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
llvm-svn: 321628
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.
Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614https://reviews.llvm.org/rC321615
llvm-svn: 321622
Erich Keane