Summary:
This attribute allows excluding a member of a class template from being part
of an explicit template instantiation of that class template. This also makes
sure that code using such a member will not take for granted that an external
instantiation exists in another translation unit. The attribute was discussed
on cfe-dev at [1] and is primarily motivated by the removal of always_inline
in libc++ to control what's part of the ABI (see links in [1]).
[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html
rdar://problem/43428125
Reviewers: rsmith
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51789
llvm-svn: 343790
Fix code for constant evaluation of __builtin_memcpy() and
__builtin_memmove() that would attempt to divide by zero when given two
pointers to an incomplete array.
Differential Revision: https://reviews.llvm.org/D51855
llvm-svn: 343761
Summary:
For types deduced from typedef's and typeof's, don't warn for duplicate
declaration specifiers in C90 unless -pedantic.
Create a third diagnostic type for duplicate declaration specifiers.
Previously, we had an ExtWarn and a Warning. This change adds a third,
Extension, which only warns when -pedantic is set, staying silent
otherwise.
Fixes PR32985.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D52849
llvm-svn: 343740
Summary: Its job is covered by -ast-dump. The option is rarely used and lacks many AST nodes which will lead to llvm_unreachable() crash.
Reviewers: rsmith, arphaman
Reviewed By: rsmith
Subscribers: jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D52529
llvm-svn: 343660
Because all our languages are C-based, there's no reason to
enable this checker only on UNIX targets.
Patch by Donát Nagy!
Differential Revision: https://reviews.llvm.org/D52722
llvm-svn: 343632
This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original
options as aliases. When -fgpu-rdc is off,
clang will assume the device code in each translation unit does not call
external functions except those in the device library, therefore it is possible
to compile the device code in each translation unit to self-contained kernels
and embed them in the host object, so that the host object behaves like
usual host object which can be linked by lld.
The benefits of this feature is: 1. allow users to create static libraries which
can be linked by host linker; 2. amortized device code linking time.
This patch modifies HIP action builder to insert actions for linking device
code and generating HIP fatbin, and pass HIP fatbin to host backend action.
It extracts code for constructing command for generating HIP fatbin as
a function so that it can be reused by early finalization. It also modifies
codegen of HIP host constructor functions to embed the device fatbin
when it is available.
Differential Revision: https://reviews.llvm.org/D52377
llvm-svn: 343611
Summary:
Some macros are used in the body of function, and actually contain the trailing semicolon: they should thus be automatically followed by a new line, and not get merged with the next line. This is for example the case with Qt's Q_UNUSED macro:
void foo(int a, int b) {
Q_UNUSED(a)
return b;
}
This patch deals with these cases by introducing a new option to specify list of statement macros. This re-uses the system already in place for foreach macros, to ensure there is no impact on performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: acoomans, mgrang, alexfh, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33440
llvm-svn: 343602
Summary:
Several improvements in preparation for the new backends.
Refactoring:
- Removed duplicated methods `fromBoolean`, `fromAPSInt`, `fromInt` and `fromAPFloat`. The methods `mkBoolean`, `mkBitvector` and `mkFloat` are now used instead.
- The names of the functions that convert BVs to FPs were swapped (`mkSBVtoFP`, `mkUBVtoFP`, `mkFPtoSBV`, `mkFPtoUBV`).
- Added a couple of comments in function calls.
Crosscheck encoding:
- Changed how constraints are encoded in the refutation manager so it doesn't start with (false OR ...). This change introduces one duplicated line (see file `BugReporterVisitors.cpp`, the `SMTConv::getRangeExpr is called twice, so I can remove this change if the duplication is a problem.
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D52365
llvm-svn: 343581
Move the bit-fields of FunctionProtoType into FunctionTypeBitfields.
This cuts the size of FunctionProtoType by a pointer. Additionally use
llvm::TrailingObjects instead of manually doing the casts + arithmetic.
This patch is bigger then what could be expected for the following reasons:
1. As discussed before in D50631 it would be nice if there was some space left
in FunctionTypeBitfields for future additions. This patch introduces an
extra structure FunctionTypeExtraBitfields which is supposed to hold
uncommon bits and is stored in a trailing object. The number of exception
types NumExceptions is moved to this struct. As of this patch this trailing
struct will only be allocated if we have > 0 types in a dynamic exception
specification.
2. TrailingObjects cannot handle repeated types. Therefore the QualType
representing an exception type is wrapped in a struct ExceptionType.
The ExceptionType * is then reinterpret_cast'd to QualType *.
3. TrailingObjects needs the definition of the various trailing classes.
Therefore ExtParameterInfo, ExceptionType and FunctionTypeExtraBitfields
are put in FunctionType.
Differential Revision: https://reviews.llvm.org/D52738
Reviewed By: rjmccall
llvm-svn: 343579
Summary:
In clangd we had a new type of completion suggestions for cpp
class/struct/unions that will show override signatures for virtual methods in
base classes. This patch implements it in sema because it is hard to deduce more
info about completion token outside of Sema and handle itchy cases.
See the patch D50898 for more info on the functionality.
In addition to above patch this one also converts the suggestion into a
CK_Pattern with whole insertion text as the name of the suggestion and factors
out CodeCompletionString generation for declerations so that it can be re-used
by others.
Reviewers: ioeric, ilya-biryukov
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52225
llvm-svn: 343568
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
This reapplies r343518 after fixing a use-after-free bug in function
Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after
it was popped and deleted.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 343542
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
This reapplies r341754, which was reverted in r341757 because it broke a
couple of bots. r341754 was calling markEscapingByrefs after the call to
PopFunctionScopeInfo, which caused the popped function scope to be
cleared out when the following code was compiled, for example:
$ cat test.m
struct A {
id data[10];
};
void foo() {
__block A v;
^{ (void)v; };
}
This commit calls markEscapingByrefs before calling PopFunctionScopeInfo
to prevent that from happening.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 343518
There are a few leftovers of rC343147 that are not (\w+)\.begin but in
the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them
to use the container form in this commit. The 12 occurrences have been
inspected manually for safety.
llvm-svn: 343425
Currently, ProgramPoint::dump calls the out-of-line function ProgramPoint::print. This causes
libraries which include ProgramPoint.h to become dependent on libclangAnalysis, which in turn
causes missing symbol link error when building with -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_MODULES=ON.
The breakage was introduced in r343160.
This patch fixes the issues by moving ProgramPoint::dump's declaration out of line.
llvm-svn: 343420
Previously we documented GNU binutils and glibc versions required for
ifunc support, but our own lld linker and FreeBSD's rtld also support
ifuncs.
Differential Revision: https://reviews.llvm.org/D52696
llvm-svn: 343408
Previously we supported these in C++, ObjC, and C with -fms-extensions.
rdar://43831380
Differential revision: https://reviews.llvm.org/D52339
llvm-svn: 343360
Dumping graphs instead of opening them is often very useful,
e.g. for transfer or converting to SVG.
Basic sanity check for generated exploded graphs.
Differential Revision: https://reviews.llvm.org/D52637
llvm-svn: 343352
render the function deleted instead of rendering the program ill-formed.
This change also adds an enabled-by-default warning for the case where
an explicitly-defaulted special member function of a non-template class
is implicitly deleted by the type checking rules. (This fires either due
to this language change or due to pre-C++20 reasons for the member being
implicitly deleted). I've tested this on a large codebase and found only
bugs (where the program means something that's clearly different from
what the programmer intended), so this is enabled by default, but we
should revisit this if there are problems with this being enabled by
default.
llvm-svn: 343285
When looking for the bclib Clang considered the default library
path first while it preferred directories in LIBRARY_PATH when
constructing the invocation of nvlink. The latter actually makes
more sense because during development it allows using a non-default
runtime library. So change the search for the bclib to start
looking in directories given by LIBRARY_PATH.
Additionally add a new option --libomptarget-nvptx-path= which
will be searched first. This will be handy for testing purposes.
Differential Revision: https://reviews.llvm.org/D51686
llvm-svn: 343230
We don't expect useful value there unless it's "ambiguous".
However we use read it for copying and moving, so we need either init the field
add login to avoid reading invalid values. Such reads trigger ubsan errors.
llvm-svn: 343150
Previously we used a select and the zero_undef=true intrinsic. In -O2 this pattern will get optimized to zero_undef=false. But in -O0 this optimization won't happen. This results in a compare and cmov being wrapped around a tzcnt/lzcnt instruction.
By using the zero_undef=false intrinsic directly without the select, we can improve the -O0 codegen to just an lzcnt/tzcnt instruction.
Differential Revision: https://reviews.llvm.org/D52392
llvm-svn: 343126
Add support for OMP5.0 requires directive and unified_address clause.
Patches to follow will include support for additional clauses.
Differential Revision: https://reviews.llvm.org/D52359
llvm-svn: 343063
Combine the two constructor overrides into a single ArrayRef constructor
to allow easier brace initializations and simplify how the respective field
is used internally.
Differential Revision: https://reviews.llvm.org/D51390
llvm-svn: 343037
When a checker maintains a program state trait that isn't a simple list/set/map, but is a combination of multiple lists/sets/maps (eg., a multimap - which may be implemented as a map from something to set of something), ProgramStateManager only contains the factory for the trait itself. All auxiliary lists/sets/maps need a factory to be provided by the checker, which is annoying.
So far two checkers wanted a multimap, and both decided to trick the
ProgramStateManager into keeping the auxiliary factory within itself
by pretending that it's some sort of trait they're interested in,
but then never using this trait but only using the factory.
Make this trick legal. Define a convenient macro.
One thing that becomes apparent once all pieces are put together is that
these two checkers are in fact using the same factory, because the type that
identifies it, ImmutableMap<const MemRegion *, ImmutableSet<SymbolRef>>,
is the same. This situation is different from two checkers registering similar
primitive traits.
Differential Revision: https://reviews.llvm.org/D51388
llvm-svn: 343035
Summary:
Making X[8-15,18] registers call-saved is used to support
CONFIG_ARM64_LSE_ATOMICS in Linux kernel.
Signed-off-by: Tri Vo <trong@android.com>
Reviewers: srhines, nickdesaulniers, javed.absar
Reviewed By: nickdesaulniers
Subscribers: kristof.beyls, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D52399
llvm-svn: 342990
This provides better help text in "clang-cl /?".
Also it cleans things up a bit: previously "/Od" could be handled either
as a separate flag aliased to "-O0", or by the main optimization flag
processing in TranslateOptArg. With this patch, all the flags get
aliased back to /O so they're handled by TranslateOptArg.
Thanks to Nico for the idea!
Differential revision: https://reviews.llvm.org/D52266
llvm-svn: 342977
Summary:
This is useful when derived file systems want to override some calls
and still proxy other calls.
Reviewers: ilya-biryukov, sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52462
llvm-svn: 342976
When embedding bitcode, only a subset of the arguments should be recorded into
the bitcode compilation commandline. The frontend job is split into two jobs,
one which will generate the bitcode. Ensure that the arguments for the
compilation to bitcode is properly stripped so that the embedded arguments are
the permitted subset.
llvm-svn: 342929
for loop if both members exist.
This resolves a DR whereby an errant 'begin' or 'end' member in a base
class could result in a derived class not being usable as a range with
non-member 'begin' and 'end'.
llvm-svn: 342925
This patch is a band-aid. A proper solution would be too change
trackNullOrUndefValue to only try to dereference the pointer when it is
relevant to the problem.
Differential Revision: https://reviews.llvm.org/D52435
llvm-svn: 342920
Added
__builtin_vsx_scalar_extract_expq
__builtin_vsx_scalar_insert_exp_qp
Builtins should behave the same way as in GCC.
Differential Revision: https://reviews.llvm.org/D48184
llvm-svn: 342911
Discussed on cfe-commits (Week-of-Mon-20180820), this change leads to
the generation of invalid IR for OpenCL without giving an error.
Therefore, the conclusion was to revert.
llvm-svn: 342885
Currently, attributes from previous declarations ('inherited attributes')
are added to the end of a declaration's list of attributes. Before
r338800, the attribute list was in reverse. r338800 changed the order
of non-inherited (parsed from the current declaration) attributes, but
inherited attributes are still appended to the end of the list.
This patch appends inherited attributes after other inherited
attributes, but before any non-inherited attribute. This is to make the
order of attributes in the AST correspond to the order in the source
code.
Differential Revision: https://reviews.llvm.org/D50214
llvm-svn: 342861
r341994 caused clangAnalysis to pull all of the AST matchers
library into clang. Due to inline key functions in the headers,
importing the AST matchers library gives a link dependency on the
AST matchers (and thus the AST), which clang should not
have.
This patch works around the issues by excluding the offending
libclangAnalysis header in the modulemap.
llvm-svn: 342827
This can be used to detect whether the code is being built with UBSan using
the __has_feature(undefined_behavior_sanitizer) predicate.
Differential Revision: https://reviews.llvm.org/D52386
llvm-svn: 342793
Not used productively, so no observable functional change.
Note that printSCFG doesn't yet work reliably, it seems to crash
sometimes.
llvm-svn: 342790
Previously clang considered function variants from both sides of
compilation and that resulted in picking up wrong deallocation function.
Differential Revision: https://reviews.llvm.org/D51808
llvm-svn: 342749
Some bots are complaining about missing parentheses in assertions added in
r342729: [AST] Various optimizations + refactoring in DeclarationName(Table)
llvm-svn: 342735
I originally added this enum to avoid including Basic/IdentifierTable.h
in AST/DeclBase.h. However I did not realise it is already included
transitively by AST/DeclarationName.h. Therefore remove this enum and
explicitly include Basic/IdentifierTable.h
llvm-svn: 342731
Introduce the following optimizations in DeclarationName(Table):
1. Store common kinds inline in DeclarationName instead of
DeclarationNameExtra. Currently the kind of C++ constructor, destructor,
conversion function and overloaded operator names is stored in
DeclarationNameExtra. Instead store it inline in DeclarationName.
To do this align IdentifierInfo, CXXSpecialName, DeclarationNameExtra
and CXXOperatorIdName to 8 bytes so that we can use the lower 3 bits of
DeclarationName::Ptr. This is already the case on 64 bits archs anyway.
This also allow us to remove DeclarationNameExtra from CXXSpecialName
and CXXOperatorIdName, which shave off a pointer from CXXSpecialName.
2. Synchronize the enumerations DeclarationName::NameKind,
DeclarationName::StoredNameKind and Selector::IdentifierInfoFlag.
This makes DeclarationName::getNameKind much more efficient since we can
replace the switch table by a single comparison and an addition.
3. Put the overloaded operator names inline in DeclarationNameTable to remove
an indirection. This increase the size of DeclarationNameTable a little
bit but this is not important since it is only used in ASTContext, and
never copied nor moved from. This also get rid of the last dynamic
allocation in DeclarationNameTable.
Altogether these optimizations cut the run time of parsing all of Boost by
about 0.8%. While we are at it, do the following NFC modifications:
1. Put the internal classes CXXSpecialName, CXXDeductionGuideNameExtra,
CXXOperatorIdName, CXXLiteralOperatorIdName and DeclarationNameExtra
in a namespace detail since these classes are only meant to be used by
DeclarationName and DeclarationNameTable. Make this more explicit by making
the members of these classes private and friending DeclarationName(Table).
2. Make DeclarationName::getFETokenInfo a non-template since every users are
using it to get a void *. It was supposed to be used with a type to avoid
a subsequent static_cast.
3. Change the internal functions DeclarationName::getAs* to castAs* since when
we use them we already know the correct kind. This has no external impact
since all of these are private.
Reviewed By: erichkeane, rjmccall
Differential Revision: https://reviews.llvm.org/D52267
llvm-svn: 342729
Summary:
Add a test and ensure that we propagate the
-fxray-instrumentation-bundle flag from the driver invocation to the
-cc1 options.
Reviewers: mboerger, tejohnson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52342
llvm-svn: 342715
Add a warning if a parameter with a named address space is passed
to a to_addr builtin.
For example:
int i;
to_private(&i); // generate warning as conversion from private to private is redundant.
Patch by Alistair Davies.
Differential Revision: https://reviews.llvm.org/D51411
llvm-svn: 342638
unsigned long long builtin_unpack_vector_int128 (vector int128_t, int);
vector int128_t builtin_pack_vector_int128 (unsigned long long, unsigned long long);
Builtins should behave the same way as in GCC.
Patch By: wuzish (Zixuan Wu)
Differential Revision: https://reviews.llvm.org/D52074
llvm-svn: 342614
Summary:
When thread safety annotations are used without capability arguments,
they are assumed to apply to `this` instead. So we warn when either
`this` doesn't exist, or the class is not a capability type.
This is based on earlier work by Josh Gao that was committed in r310403,
but reverted in r310698 because it didn't properly work in template
classes. See also D36237.
The solution is not to go via the QualType of `this`, which is then a
template type, hence the attributes are not known because it could be
specialized. Instead we look directly at the class in which we are
contained.
Additionally I grouped two of the warnings together. There are two
issues here: the existence of `this`, which requires us to be a
non-static member function, and the appropriate annotation on the class
we are contained in. So we don't distinguish between not being in a
class and being static, because in both cases we don't have `this`.
Fixes PR38399.
Reviewers: aaron.ballman, delesley, jmgao, rtrieu
Reviewed By: delesley
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51901
llvm-svn: 342605
This adds a preprocessor callback for the `__has_include` and
`__has_include_next` directives.
Successful checking for the presence of a header should add it to the list of
header dependencies so this overrides the callback in the dependency scanner.
Patch by Pete Cooper with some additions by me.
rdar://problem/39545636
Differential Revision: https://reviews.llvm.org/D30882
llvm-svn: 342517
* Create a USR for the occurrences of the 'module' symbol kind
* Record module references for each identifier in an import declaration
llvm-svn: 342484
Summary: Also added unit tests for the index library; lit+c-index-test is painful...
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D52098
llvm-svn: 342451
Summary:
The dir component ("somedir" in #include <somedir/fo...>) is considered fixed.
We append "foo" to each directory on the include path, and then list its files.
Completions are of the forms:
#include <somedir/fo^
foo.h>
fox/
The filter is set to the filename part ("fo"), so fuzzy matching can be
applied to the filename only.
No fancy scoring/priorities are set, and no information is added to
CodeCompleteResult to make smart scoring possible. Could be in future.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52076
llvm-svn: 342449
Fixes a number of issues:
- Global variables are not used for communication
- Trait should be defined on a graph, not on a node
- Defining the trait on a graph allows us to use a correct allocator,
no longer crashing while printing trimmed graphs
Differential Revision: https://reviews.llvm.org/D52183
llvm-svn: 342413
Summary:
Merged the recently added `err_attribute_argument_negative` diagnostic
with existing `err_attribute_requires_positive_integer` diagnostic:
the former allows only strictly positive integer, while the latter
also allows zero.
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51853
llvm-svn: 342367
This can be used to detect whether the code is being built with XRay
instrumentation using the __has_feature(xray_instrument) predicate.
Differential Revision: https://reviews.llvm.org/D52159
llvm-svn: 342358
Move declarations for OMPClauseReader, OMPClauseWriter to ASTReader.h
and ASTWriter.h and move implementation to ASTReader.cpp and
ASTWriter.cpp. This change helps generalize the serialization of
OpenMP clauses and will be used in the future implementation of new
OpenMP directives (e.g. requires).
Patch by Patrick Lyster
Differential Revision: https://reviews.llvm.org/D52097
llvm-svn: 342322
The generated identifier is stable across multiple runs,
and can be a great visualization or debugging aide.
Differential Revision: https://reviews.llvm.org/D52113
llvm-svn: 342315
Those are not created in the allocator.
Since they are created fairly rarely, a counter overhead should not
affect the memory consumption.
Differential Revision: https://reviews.llvm.org/D51827
llvm-svn: 342314
The generated identifiers are stable across multiple runs, and can be a
great debug or visualization aid.
Differential Revision: https://reviews.llvm.org/D51822
llvm-svn: 342309
Summary:
We used to treat an `Expr` mutated whenever it's passed as non-const
reference argument to a function. This results in false positives in
cases like this:
```
int x;
std::vector<int> v;
v.emplace_back(x); // `x` is passed as non-const reference to `emplace_back`
```
In theory the false positives can be suppressed with
`v.emplace_back(std::as_const(x))` but that's considered overly verbose,
inconsistent with existing code and spammy as diags.
This diff handles such cases by following into the function definition
and see whether the argument is mutated inside.
Reviewers: lebedev.ri, JonasToth, george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D52008
llvm-svn: 342271
Summary:
Most callers I can find are using only `getName()`. Type is used by the
recursive iterator.
Now we don't have to call stat() on every listed file (on most platforms).
Exceptions are e.g. Solaris where readdir() doesn't include type information.
On those platforms we'll still stat() - see D51918.
The result is significantly faster (stat() can be slow).
My motivation: this may allow us to improve clang IO on large TUs with long
include search paths. Caching readdir() results may allow us to skip many stat()
and open() operations on nonexistent files.
Reviewers: bkramer
Subscribers: fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D51921
llvm-svn: 342232
There is a bit of code at the end of AddDeclaration that should be run on
every exit of the function. However, there was an early exit beforehand
that could be triggered, which causes a small amount of data to skip the
hashing, leading to false positive mismatch. Use a separate function so
that this code is always run.
llvm-svn: 342199
Summary:
When someone writes
#include "<some_file>"
or
#include " some_file "
the compiler returns "file not fuond..." with fonts and quotes that may
make it hard to see there are excess quotes or surprising bytes in the
filename. Assuming that files are usually logically named and start and
end with an alphanumeric character, we can check for the file's
existence by stripping the non-alphanumeric leading or trailing
characters. If the file is found, emit a non-fatal error with a
FixItHint.
Patch by Christy Lee!
Reviewers: aaron.ballman, erikjv, rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, xbolva00, sammccall, modocache, erikjv, aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D51333
llvm-svn: 342177
Previously, both types (plus the future target-clones) of
multiversioning had a separate ResolverOption structure and emission
function. This patch combines the two, at the expense of a slightly
more expensive sorting function.
llvm-svn: 342152
declare reduction.
If the declare reduction construct with the non-dependent type is
defined in the template construct, the compiler might crash on the
template instantition. Reworked the whole instantiation scheme for the
declare reduction constructs to fix this problem correctly.
llvm-svn: 342151
Summary: Reserving registers x1-7 is used to support CONFIG_ARM64_LSE_ATOMICS in Linux kernel. This change adds support for reserving registers x1 through x7.
Reviewers: javed.absar, efriedma, nickdesaulniers, srhines, phosek
Reviewed By: nickdesaulniers
Subscribers: manojgupta, jfb, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D48581
llvm-svn: 342100
hidden definition with a would-be-parsed redefinition.
This permits a bunch of cleanups. In particular, we no longer need to
take merged definitions into account when checking declaration
visibility, only when checking definition visibility, which makes
certain visibility checks take linear instead of quadratic time.
We could also now remove the UPD_DECL_EXPORTED update record and track
on each declaration whether it was demoted from a definition (as we
already do for variables), but I'm not doing that in this patch to keep
the changes here simpler.
llvm-svn: 342018
Summary:
This is 1/2 of moving ExprMutationAnalyzer from clangtidy to
clang/Analysis.
This diff along simply copies the ExprMutationAnalyzer over with trivial
modifications (e.g. include path, namespace)
2/2 will migrate existing usage of ExprMutationAnalyzer and remove the
original copy inside clangtidy.
Reviewers: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits, JonasToth
Differential Revision: https://reviews.llvm.org/D51948
llvm-svn: 341994
With clang-cl, when the user specifies /Yc or /Yu without a filename
the compiler uses a #pragma hdrstop in the main source file to
determine the end of the PCH. If a header is specified with /Yc or
/Yu #pragma hdrstop has no effect.
The optional #pragma hdrstop filename argument is not yet supported.
Differential Revision: https://reviews.llvm.org/D51391
llvm-svn: 341963
Summary:
The new matchers can be used to check if an expression is type-, value- or instantiation-dependent
in a templated context.
These matchers are used in a clang-tidy check and generally useful as the
problem of unresolved templates occurs more often in clang-tidy and they
provide an easy way to check for this issue.
Reviewers: aaron.ballman, alexfh, klimek
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51880
llvm-svn: 341958
Summary:
Factors out member decleration gathering and uses it in parsing to call signature
help. Doesn't support signature help for base class constructors, the code was too
coupled with diagnostic handling, but still can be factored out but just needs
more afford.
Reviewers: sammccall, ilya-biryukov, ioeric
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51917
llvm-svn: 341949
Summary:
And add an option to disable this behavior. The option is only used in
AllTUsExecutor to avoid races when running concurrently on multiple
threads.
This fixes PR38869 introduced by r340937.
Reviewers: ioeric, steveire
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51864
llvm-svn: 341910
Fix a bug in the deserialization of IMPORTS section and allow for
imported modules to also be printed with -module-file-info.
rdar://problem/43867753
llvm-svn: 341902
When defined in NSObject, +new will call -init. If -init has been marked
unavailable, diagnose uses of +new.
rdar://18335828
Differential revision: https://reviews.llvm.org/D51189
llvm-svn: 341874
Summary:
_Atomic and __sync_* operations are implicitly sequentially-consistent. Some
codebases want to force explicit usage of memory order instead. This warning
allows them to know where implicit sequentially-consistent memory order is used.
The warning isn't on by default because _Atomic was purposefully designed to
have seq_cst as the default: the idea was that it's the right thing to use most
of the time. This warning allows developers who disagree to enforce explicit
usage instead.
A follow-up patch will take care of C++'s std::atomic. It'll be different enough
from this patch that I think it should be separate: for C++ the atomic
operations all have a memory order parameter (or two), but it's defaulted. I
believe this warning should trigger when the default is used, but not when
seq_cst is used explicitly (or implicitly as the failure order for cmpxchg).
<rdar://problem/28172966>
Reviewers: rjmccall
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51084
llvm-svn: 341860
This change allows usage of -march when using the clang-cl driver. This is similar to MSVC's /arch; however -march can target precisely all supported CPUs, while /arch has a more restricted set.
Differential Revision: https://reviews.llvm.org/D51806
llvm-svn: 341847
Summary:
Currently CodeCompleteCall only gets called after a comma or parantheses. This
patch makes sure it is called even at the cases like:
```foo(1^);```
Reviewers: ilya-biryukov, ioeric, hokein
Reviewed By: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D51038
llvm-svn: 341824
New check added to the checker which checks whether iterator parameters of template functions typed by the same template parameter refer to the same container.
Differential Revision: https://reviews.llvm.org/D32845
llvm-svn: 341790
match when checking for redeclaration of a function template.
This properly handles differences in deduced return types, particularly
when performing redeclaration checks for a friend function template.
llvm-svn: 341778
Add the capability to nest multiple declare target directives
- including header files within a declare target region.
Differential Revision: https://reviews.llvm.org/D51378
Patch by Patrick Lyster
llvm-svn: 341766
from those that aren't.
This patch changes the way __block variables that aren't captured by
escaping blocks are handled:
- Since non-escaping blocks on the stack never get copied to the heap
(see https://reviews.llvm.org/D49303), Sema shouldn't error out when
the type of a non-escaping __block variable doesn't have an accessible
copy constructor.
- IRGen doesn't have to use the specialized byref structure (see
https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a
non-escaping __block variable anymore. Instead IRGen can emit the
variable as a normal variable and copy the reference to the block
literal. Byref copy/dispose helpers aren't needed either.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D51564
llvm-svn: 341754
The "derived" symbols indicate children fields of a larger symbol.
As parents do not have pointers to their children, the garbage
collection algorithm the analyzer currently uses adds such symbols into
a "postponed" category, and then keeps running through the worklist
until the fixed point is reached.
The current patch rectifies that by instead using a helper map which
stores pointers from parents to children, so that no fixed point
calculation is necessary.
The current patch yields ~5% improvement in running time on sqlite.
Differential Revision: https://reviews.llvm.org/D51397
llvm-svn: 341722
Summary:
Code completion in clang is actually a mix of two features:
- Code completion is a familiar feature. Results are exposed via the
CodeCompleteConsumer::ProcessCodeCompleteResults callback.
- Signature help figures out if the current expression is an argument of
some function call and shows corresponding signatures if so.
Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates.
This patch refactors the implementation to untangle those two from each
other and makes some naming tweaks to avoid confusion when reading the
code.
The refactoring is required for signature help fixes, see D51038.
The only intended behavior change is the order of callbacks.
ProcessOverloadCandidates is now called before ProcessCodeCompleteResults.
Reviewers: sammccall, kadircet
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51782
llvm-svn: 341660
Boilerplate code for using KMSAN instrumentation in Clang.
We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::KernelMemory, which, along with
SanitizerKind::Memory, maps to the memory_sanitizer feature.
KMSAN is only supported on x86_64 Linux.
It's incompatible with other sanitizers, but supports code coverage
instrumentation.
llvm-svn: 341641
A node is considered to be trivial if it only has one successor, one
predecessor, and a state equal to the predecessor.
Can drastically (> 2x) reduce the size of the generated exploded
graph.
Differential Revision: https://reviews.llvm.org/D51665
llvm-svn: 341616
Ubigraph project has been dead since about 2008, and to the best of my
knowledge, no one was using it.
Previously, I wasn't able to launch the existing binary at all.
Differential Revision: https://reviews.llvm.org/D51655
llvm-svn: 341601
Namely, print the likely macro name when it's used, and include the actual
computed sizes in the diagnostic message, which are sometimes not obvious.
rdar://43909200
Differential revision: https://reviews.llvm.org/D51697
llvm-svn: 341566
Summary:
Negative arguments in kernel attributes are silently bitcast'ed to
unsigned, for example:
__attribute__((reqd_work_group_size(1, -1, 1)))
__kernel void k() {}
is a complete equivalent of:
__attribute__((reqd_work_group_size(1, 4294967294, 1)))
__kernel void k() {}
This is likely an error, so the patch forbids negative arguments in
several OpenCL attributes. Users who really want 4294967294 can still
use it as an unsigned representation.
Reviewers: Anastasia, yaxunl, bader
Reviewed By: Anastasia, yaxunl, bader
Subscribers: bader, cfe-commits
Differential Revision: https://reviews.llvm.org/D50259
llvm-svn: 341539
destructors.
We previously tried to patch up the exception specification after
completing the class, which went wrong when the exception specification
was needed within the class body (in particular, by a friend
redeclaration of the destructor in a nested class). We now mark the
destructor as having a not-yet-computed exception specification
immediately after creating it.
This requires delaying various checks against the exception
specification (where we'd previously have just got the wrong exception
specification, and now find we have an exception specification that we
can't compute yet) when those checks fire while the class is being
defined.
This also exposed an issue that we were missing a CodeSynthesisContext
for computation of exception specifications (otherwise we'd fail to make
the module containing the definition of the class visible when computing
its members' exception specs). Adding that incidentally also gives us a
diagnostic quality improvement.
This has also exposed an pre-existing problem: making the exception
specification evaluation context a non-SFINAE context (as it should be)
results in a bootstrap failure; PR38850 filed for this.
llvm-svn: 341499
This is a warning about using 'assign' instead of 'unsafe_unretained'
in Objective-C property declarations. It's off by default because there
isn't consensus in the Objective-C steering group that this is the right
thing to do, but we're nonetheless okay with adding it because there's a
substantial pool of Objective-C programmers who will appreciate the warning.
Patch by Alfred Zien!
llvm-svn: 341489
Summary:
This provides information about the macro definition. For example, it
can be used to compute macro USRs.
Reviewers: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51675
llvm-svn: 341476
Summary:
We previously disallowed use of undocumented attributes with #pragma clang
attribute, but the justification for doing so was weak and it prevented many
reasonable use cases.
Reviewers: aaron.ballman, arphaman
Subscribers: cfe-commits, rnk, benlangmuir, dexonsmith, erik.pilkington
Differential Revision: https://reviews.llvm.org/D51507
llvm-svn: 341437
Summary:
Added support of creating a hardlink from one file to another file.
After a hardlink is added between two files, both file will have the same:
1. UniqueID (inode)
2. Size
3. Buffer
This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs.
Patch by Utkarsh Saxena!
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51359
llvm-svn: 341366
Load Hardening.
Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.
Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.
While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.
This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.
Differential Revision: https://reviews.llvm.org/D51157
llvm-svn: 341363
These aren't documented in the Intel Intrinsics Guide, but are supported by gcc and icc.
Includes these intrinsics:
_ktestc_mask8_u8, _ktestz_mask8_u8, _ktest_mask8_u8
_ktestc_mask16_u8, _ktestz_mask16_u8, _ktest_mask16_u8
_ktestc_mask32_u8, _ktestz_mask32_u8, _ktest_mask32_u8
_ktestc_mask64_u8, _ktestz_mask64_u8, _ktest_mask64_u8
llvm-svn: 341265
This adds:
_cvtmask8_u32, _cvtmask16_u32, _cvtmask32_u32, _cvtmask64_u64
_cvtu32_mask8, _cvtu32_mask16, _cvtu32_mask32, _cvtu64_mask64
_load_mask8, _load_mask16, _load_mask32, _load_mask64
_store_mask8, _store_mask16, _store_mask32, _store_mask64
These are currently missing from the Intel Intrinsics Guide webpage.
llvm-svn: 341251
This adds the following intrinsics:
_kshiftli_mask8
_kshiftli_mask16
_kshiftli_mask32
_kshiftli_mask64
_kshiftri_mask8
_kshiftri_mask16
_kshiftri_mask32
_kshiftri_mask64
llvm-svn: 341234
Summary:
Added option -gline-directives-only to support emission of the debug directives
only. It behaves very similar to -gline-tables-only, except that it sets
llvm debug info emission kind to
llvm::DICompileUnit::DebugDirectivesOnly.
Reviewers: echristo
Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D51177
llvm-svn: 341212
Summary:
Instead of listing all the spellings (including attribute namespaces) in
the section heading, only list the actual attribute names there, and
list the spellings in the supported syntaxes table.
This allows us to properly describe things like [[fallthrough]], for
which we allow a clang:: prefix in C++ but not in C, and AlwaysInline,
which has one spelling as a GNU attribute and a different spelling as a
keyword, without needing to repeat the syntax description in the
documentation text.
Sample rendering: https://pste.eu/p/T1ZV.html
Reviewers: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51473
llvm-svn: 341097
how we parse source code.
Instead of implicitly opting all undocumented attributes out of '#pragma
clang attribute' support, explicitly opt them all out and remove the
documentation check from TableGen.
(No new attributes should be added without documentation, so this has
little chance of backsliding. We already support the pragma on one
undocumented attribute, so we don't even want to enforce our old
"rule".)
No functionality change intended.
llvm-svn: 341009
Introduce a new MemRegion sub-class, CXXDerivedObjectRegion, which is
the opposite of CXXBaseObjectRegion, to represent such casts. Such region is
a bit weird because it is by design bigger than its super-region.
But it's not harmful when it is put on top of a SymbolicRegion
that has unknown extent anyway.
Offset computation for CXXDerivedObjectRegion and proper modeling of casts
still remains to be implemented.
Differential Revision: https://reviews.llvm.org/D51191
llvm-svn: 340984
The analyzer doesn't make use of them anyway and they seem to have
pretty weird AST from time to time, so let's just skip them for now.
Fixes a crash reported as pr37769.
Differential Revision: https://reviews.llvm.org/D50855
llvm-svn: 340977
Summary:
Resolve all relative paths before running the tool instead.
This fixes the usage of ClangTool in AllTUsExecutor. The executor will
try running multiple ClangTool instances in parallel with compile
commands that usually have the same working directory.
Changing working directory is a global operation, so we end up
changing working directory in the middle of running other actions,
which leads to spurious compile errors.
Reviewers: ioeric, sammccall
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51407
llvm-svn: 340937
This adds the following intrinsics:
_kadd_mask64
_kadd_mask32
_kadd_mask16
_kadd_mask8
These are missing from the Intel Intrinsics Guide, but are implemented by both gcc and icc.
llvm-svn: 340879
We add check for invalidation of iterators. The only operation we handle here
is the (copy) assignment.
Differential Revision: https://reviews.llvm.org/D32747
llvm-svn: 340805
Currently an address_space is stored in a qualifier. This makes any type
declared with an address_space attribute in the form
`__attribute__((address_space(1))) int 1;` be wrapped in an AttributedType.
This is for a later patch where if `address_space` is declared in a macro,
any diagnostics that would normally print the address space will instead dump
the macro name. This will require saving any macro information in the
AttributedType.
Differential Revision: https://reviews.llvm.org/D51229
llvm-svn: 340765
This also adds a second intrinsic name for the 16-bit mask versions.
These intrinsics match gcc and icc. They just aren't published in the Intel Intrinsics Guide so I only recently found they existed.
llvm-svn: 340719
Summary:
Used in clangd's symbol builder to optimize for the common
shared-memory executor case.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D51164
llvm-svn: 340599
Summary:
This patch implements a new cache for the result of SMT queries; with this patch the regression tests are 25% faster.
It's implemented as a `llvm::DenseMap` where the key is the hash of the set of the constraints in a state.
There is still one method that does not use the cache, `getSymVal`, because it needs to get a symbol interpretation from the SMT, which is not cached yet.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50773
llvm-svn: 340535
Summary:
With this patch, the SMT backend is almost completely detached from the CSA.
Unfortunate consequence is that we missed the `ConditionTruthVal` from the CSA and had to use `Optional<bool>`.
The Z3 solver implementation is still in the same file as the `Z3ConstraintManager`, in `lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp` though, but except for that, the SMT API can be moved to anywhere in the codebase.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50772
llvm-svn: 340534
Summary:
By making SMTConstraintManager a template and passing the SMT constraint type and expr, we can further move code from the Z3ConstraintManager class to the generic SMT constraint Manager.
Now, each SMT specific constraint manager only needs to implement the method `bool canReasonAbout(SVal X) const`.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50770
llvm-svn: 340533
Summary: There is no reason to have a base class for a context anymore as each SMT object carries a reference to the specific solver context.
Reviewers: NoQ, george.karpenkov, hiraditya
Reviewed By: hiraditya
Subscribers: hiraditya, xazax.hun, szepet, a.sidorin, Szelethus
Differential Revision: https://reviews.llvm.org/D50768
llvm-svn: 340532
subtarget features for indirect calls and indirect branches.
This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.
I've continued to use subtarget features for now as they continue to
seem the best fit given the lack of other retpoline like constructs so
far.
The LLVM side is pretty simple. I'd like to eventually get rid of the
old feature, but not sure what backwards compatibility issues that will
cause.
This does remove the "implies" from requesting an external thunk. This
always seemed somewhat questionable and is now clearly not desirable --
you specify a thunk the same way no matter which set of things are
getting retpolines.
I really want to keep this nicely isolated from end users and just an
LLVM implementation detail, so I've moved the `-mretpoline` flag in
Clang to no longer rely on a specific subtarget feature by that name and
instead to be directly handled. In some ways this is simpler, but in
order to preserve existing behavior I've had to add some fallback code
so that users who relied on merely passing -mretpoline-external-thunk
continue to get the same behavior. We should eventually remove this
I suspect (we have never tested that it works!) but I've not done that
in this patch.
Differential Revision: https://reviews.llvm.org/D51150
llvm-svn: 340515
Previously we only used target triple as provided which matches the
GCC behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.
Unfortunatelly, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should also check the normalized
triple when constructing paths for multiarch runtimes.
Differential Revision: https://reviews.llvm.org/D50547
llvm-svn: 340471
constants by default when there is no optimization.
GCC's option -fno-keep-static-consts can be used to not emit
unused static constants.
In Clang, since default behavior does not keep unused static constants,
-fkeep-static-consts can be used to emit these if required. This could be
useful for producing identification strings like SVN identifiers
inside the object file even though the string isn't used by the program.
Differential Revision: https://reviews.llvm.org/D40925
llvm-svn: 340439
Summary:
`CallDecription` can only handle function for the time being. If we want to match c++ method, we can only use method name to match and can't improve the matching accuracy through the qualifiers.
This patch add the support for `QualifiedName` matching to improve the matching accuracy.
Reviewers: xazax.hun, NoQ, george.karpenkov, rnkovacs
Reviewed By: xazax.hun, NoQ, rnkovacs
Subscribers: Szelethus, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits, MTC
Differential Revision: https://reviews.llvm.org/D48027
llvm-svn: 340407
Summary:
Currently there are several issues with the import of class template
specializations. (1) Different TUs may have class template specializations
with the same template arguments, but with different set of instantiated
MethodDecls and FieldDecls. In this patch we provide a fix to merge these
methods and fields. (2) Currently, we search the partial template
specializations in the set of simple specializations and we add partial
specializations as simple specializations. This is bad, this patch fixes it.
Reviewers: a_sidorin, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D50451
llvm-svn: 340402
Set __mips_fpr to 0 if o32 ABI is used with either -mfpxx
or none of -mfp32, -mfpxx, -mfp64 being specified.
Introduce additional checks:
-mfpxx is only to be used in conjunction with the o32 ABI.
report an error when incompatible options are provided.
Formerly no errors were raised when combining n32/n64 ABIs
with -mfp32 and -mfpxx.
There are other cases when __mips_fpr should be set to 0
that are not covered, ex. using o32 on a mips64 cpu
which is valid but not supported in the backend as of yet.
Differential Revision: https://reviews.llvm.org/D50557
llvm-svn: 340391
This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a
specific static or thread duration variable shouldn't have it's destructor
registered, and is the default in -fno-c++-static-destructors mode.
always_destroy is the opposite, and is the default in -fc++-static-destructors
mode.
A variable whose destructor is disabled (either because of
-fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of
the destructor, so we don't do any access checking or mark it referenced. We
also don't emit -Wexit-time-destructors for these variables.
rdar://21734598
Differential revision: https://reviews.llvm.org/D50994
llvm-svn: 340306
Summary:
r306722 introduced a new note called note_silence_unligned_allocation_unavailable
where I believe what was meant is note_silence_aligned_allocation_unavailable.
Reviewers: ahatanak
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51043
llvm-svn: 340288
Turns out it can't be removed from the analyzer since it relies on CallEvent.
Moving to staticAnalyzer/core
Differential Revision: https://reviews.llvm.org/D51023
llvm-svn: 340247
Summary:
We decided to revert this from i64 to i32 in Nov 28 CG meeting. Fixes
PR38632.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51013
llvm-svn: 340235
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
This reinstates r339623, reverted in r339638, with a fix to not fail
template instantiation if we instantiate a QualType with no associated
type source information and we encounter an AttributedType.
llvm-svn: 340215
This changes the current default behavior (from emitting pubnames by
default, to not emitting them by default) & moves to matching GCC's
behavior* with one significant difference: -gno(-gnu)-pubnames disables
pubnames even in the presence of -gsplit-dwarf (though -gsplit-dwarf
still by default enables -ggnu-pubnames). This allows users to disable
pubnames (& the new DWARF5 accelerated access tables) when they might
not be worth the size overhead.
* GCC's behavior is that -ggnu-pubnames and -gpubnames override each
other, and that -gno-gnu-pubnames and -gno-pubnames act as synonyms and
disable either kind of pubnames if they come last. (eg: -gpubnames
-gno-gnu-pubnames causes no pubnames (neither gnu or standard) to be
emitted)
llvm-svn: 340206
Summary: unique_ptr makes the ownership clearer than a raw pointer container.
Reviewers: Eugene.Zelenko, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50945
llvm-svn: 340198
This is a partial retry of rL340137 (reverted at rL340138 because of gcc host compiler crashing)
with 1 change:
Remove the changes to make microsoft builtins also use the LLVM intrinsics.
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops) that we want to replicate, we can change the names.
The funnel shift intrinsics were added here:
https://reviews.llvm.org/D49242
With improved codegen in:
https://reviews.llvm.org/rL337966https://reviews.llvm.org/rL339359
And basic IR optimization added in:
https://reviews.llvm.org/rL338218https://reviews.llvm.org/rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340141
This patch fixes definitions of vld and vst NEON intrinsics so
that we only define them if half-precision arithmetic is
supported on the target platform, as prescribed in ACLE 2.0.
Differential Revision: https://reviews.llvm.org/D49075
llvm-svn: 340140
This is a retry of rL340135 (reverted at rL340136 because of gcc host compiler crashing)
with 2 changes:
1. Move the code into a helper to reduce code duplication (and hopefully work-around the crash).
2. The original commit had a formatting bug in the docs (missing an underscore).
Original commit message:
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate,
we can change the names.
The funnel shift intrinsics were added here:
https://reviews.llvm.org/D49242
With improved codegen in:
https://reviews.llvm.org/rL337966https://reviews.llvm.org/rL339359
And basic IR optimization added in:
https://reviews.llvm.org/rL338218https://reviews.llvm.org/rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340137
This exposes the LLVM funnel shift intrinsics as more familiar bit rotation functions in clang
(when both halves of a funnel shift are the same value, it's a rotate).
We're free to name these as we want because we're not copying gcc, but if there's some other
existing art (eg, the microsoft ops that are modified in this patch) that we want to replicate,
we can change the names.
The funnel shift intrinsics were added here:
D49242
With improved codegen in:
rL337966
rL339359
And basic IR optimization added in:
rL338218
rL340022
...so these are expected to produce asm output that's equal or better to the multi-instruction
alternatives using primitive C/IR ops.
In the motivating loop example from PR37387:
https://bugs.llvm.org/show_bug.cgi?id=37387#c7
...we get the expected 'rolq' x86 instructions if we substitute the rotate builtin into the source.
Differential Revision: https://reviews.llvm.org/D50924
llvm-svn: 340135
ARCMigrator is using code from RetainCountChecker, which is a layering
violation (and it also does it badly, by using a different header, and
then relying on implementation being present in a header file).
This change splits up RetainSummaryManager into a separate library in
lib/Analysis, which can be used independently of a checker.
Differential Revision: https://reviews.llvm.org/D50934
llvm-svn: 340114
expression
Clang emits invalid protocol metadata when a @protocol expression is used with a
forward-declared protocol. The protocol metadata is missing protocol conformance
list of the protocol since we don't have access to the definition of it in the
compiled translation unit. The linker then might end up picking the invalid
metadata when linking which will lead to incorrect runtime protocol conformance
checks.
This commit makes sure that Clang fails to compile code that uses a @protocol
expression with a forward-declared protocol. This ensures that Clang does not
emit invalid protocol metadata. I added an extra assert in CodeGen to ensure
that this kind of issue won't happen in other places.
rdar://32787811
Differential Revision: https://reviews.llvm.org/D49462
llvm-svn: 340102
A lot of code in RetainCountChecker deals with GC mode.
Given that GC mode is deprecated, Apple does not ship runtime for it,
and modern compiler toolchain does not support it, it makes sense to
remove the code dealing with it in order to aid understanding of
RetainCountChecker.
Differential Revision: https://reviews.llvm.org/D50747
llvm-svn: 340091
r337619 added __shiftleft128 / __shiftright128 as functions in intrin.h.
Microsoft's STL plans on using these functions, and they're using intrin0.h
which just has declarations of built-ins to not pull in the huge intrin.h
header in the standard library headers. That requires that these functions are
real built-ins.
https://reviews.llvm.org/D50907
llvm-svn: 340048
Summary:
Empty preamble is valid for source file which doesn't have any
preprocessor and #includes.
This patch makes clang treat an empty preamble as a normal preamble.
Check: ninja check-clang
A testcase is added in https://reviews.llvm.org/D50627.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50628
llvm-svn: 340029
- Add a command line options -msign-return-address to enable return address
signing
- Armv8.3a added instructions to sign the return address to help mitigate
against ROP attacks
- This patch adds command line options to generate function attributes that
signal to the back whether return address signing instructions should be
added
Differential revision: https://reviews.llvm.org/D49793
llvm-svn: 340019
The TagDecl *OwnedTagDecl in ElaboratedType is quite commonly
null (at least when parsing all of Boost, it is non-null for only about 600
of the 66k ElaboratedType). Therefore we can save a pointer in the
common case by storing it as a trailing object, and storing a bit in the
bit-fields of Type indicating when the pointer is null.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D50715
llvm-svn: 339862
The bit-fields of Type have enough space for the member
unsigned NumArgs of SubstTemplateTypeParmPackType.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50713
llvm-svn: 339861
The bit-fields of `Type` have enough space for the member
`unsigned NumArgs` of `DependentTemplateSpecializationType`.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50712
llvm-svn: 339860
The bit-fields of `Type` have enough space for
the `unsigned NumExpansions` of `PackExpansionType`
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50711
llvm-svn: 339789
Type has enough space for two members of
TemplateSpecializationType. Mechanical patch.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50643
llvm-svn: 339787
Once CFG-side support for argument construction contexts landed in r338436,
the analyzer could make use of them to evaluate argument constructors properly.
When evaluated as calls, constructors of arguments now use the variable region
of the parameter as their target. The corresponding stack frame does not yet
exist when the parameter is constructed, and this stack frame is created
eagerly.
Construction of functions whose body is unavailable and of virtual functions
is not yet supported. Part of the reason is the analyzer doesn't consistently
use canonical declarations o identify the function in these cases, and every
re-declaration or potential override comes with its own set of parameter
declarations. Also it is less important because if the function is not
inlined, there's usually no benefit in inlining the argument constructor.
Differential Revision: https://reviews.llvm.org/D49443
llvm-svn: 339745
information is then discarded with a warning to the user that we don't
support it.
This patch gets us one step closer by getting the info down into the
AST in most cases.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D49865
llvm-svn: 339693
This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid
in some way, but we put a lot of work into accepting it, and I'm sure
rejecting it was not an intended consequence of this refactoring. :)
llvm-svn: 339638
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
llvm-svn: 339623
Multiversioned member functions inside of a template type were
not properly being emitted. The solution to this is to simply
ensure that their bodies are correctly evaluated/assigned during
template instantiation.
llvm-svn: 339597
The current static_assert only checks that ObjCObjectTypeBitfields
fits into an unsigned. However it turns out that FunctionTypeBitfields
do not currently fits into an unsigned. Therefore the anonymous
union containing the bit-fields always use 8 bytes instead of 4.
This patch removes the lone misguided static_assert and systematically
checks the size of each bit-field.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50630
llvm-svn: 339582
Summary:
This is for use by clang-tidy's bugprone-use-after-move check -- see
corresponding clang-tidy patch at https://reviews.llvm.org/D49910.
Reviewers: aaron.ballman, rsmith
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49911
llvm-svn: 339569
Summary:
This change is to support a new fature in clangd, tests will be send toclang-tools-extra with that change.
Unittests are included in: https://reviews.llvm.org/D50449
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D50443
llvm-svn: 339540
This form makes more sense (it is a range over constant arguments) and is most consistent with const_arg_iterator (there are zero instances of arg_const_iterator).
llvm-svn: 339527
Clang generates copy and dispose helper functions for each block literal
on the stack. Often these functions are equivalent for different blocks.
This commit makes changes to merge equivalent copy and dispose helper
functions and reduce code size.
To enable merging equivalent copy/dispose functions, the captured object
infomation is encoded into the helper function name. This allows IRGen
to check whether an equivalent helper function has already been emitted
and reuse the function instead of generating a new helper function
whenever a block is defined. In addition, the helper functions are
marked as linkonce_odr to enable merging helper functions that have the
same name across translation units and marked as unnamed_addr to enable
the linker's deduplication pass to merge functions that have different
names but the same content.
rdar://problem/42640608
Differential Revision: https://reviews.llvm.org/D50152
llvm-svn: 339438
Summary:
Introduces funclet-based unwinding for Objective-C and fixes an issue
where global blocks can't have their isa pointers initialised on
Windows.
After discussion with Dustin, this changes the name mangling of
Objective-C types to prevent a C++ catch statement of type struct X*
from catching an Objective-C object of type X*.
Reviewers: rjmccall, DHowett-MSFT
Reviewed By: rjmccall, DHowett-MSFT
Subscribers: mgrang, mstorsjo, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D50144
llvm-svn: 339428
This patch fixes a wrong type bug inside ParsedAttr::TypeTagForDatatypeData.
The details to the best of my knowledge are as follow. The incredible thing
is that everything works out just fine by chance due to a sequence of lucky
coincidences in the layout of various types.
The struct ParsedAttr::TypeTagForDatatypeData contains among other things
a ParsedType *MatchingCType, where ParsedType is just OpaquePtr<QualType>.
However the member MatchingCType is initialized in the constructor for
type_tag_for_datatype attribute as follows:
new (&ExtraData.MatchingCType) ParsedType(matchingCType);
This results in the ParsedType being constructed in the location of the
ParsedType * Later ParsedAttr::getMatchingCType do return
*getTypeTagForDatatypeDataSlot().MatchingCType; which instead of
dereferencing the ParsedType * will dereference the QualType inside
the ParsedType. Now this QualType in this case contains no qualifiers
and therefore is a valid Type *. Therefore getMatchingCType returns a
Type or at least the stuff that is in the first sizeof(void*) bytes of it,
But it turns out that Type inherits from ExtQualsCommonBase and that the
first member of ExtQualsCommonBase is a const Type *const BaseType. This
Type * in this case points to the original Type pointed to by the
QualType and so everything works fine even though all the types were wrong.
This bug was only found because I changed the layout of Type,
which obviously broke all of this long chain of improbable events.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50532
llvm-svn: 339423
This extension emits the guard cf table without inserting the
instrumentation. Currently that's what clang-cl does with /guard:cf
anyway, but this allows a user to request that explicitly.
Differential Revision: https://reviews.llvm.org/D50513
llvm-svn: 339420
r339380 changed the trailing types of ParsedAttr to use llvm::TrailingObjects.
However, it did not copy over one of the size attributes, causing a too
small allocation for this object. The error was detected with
AddressSanitizer use-after-poison
llvm-svn: 339409
As sent on cfe-commits:
"You need to use "friend TrailingObjects;" here, not
"friend class TrailingObjects;", to avoid breaking MSVC
(which doesn't implement injected-class-names quite according to spec)."
llvm-svn: 339389
As suggested in the post-commit review for D50531,
change from the templatized TrailingObjects friend declaration
to a version referring to the base.
llvm-svn: 339382
ParsedAttr is using a hand-rolled trailing-objects
implementation that gets cleaned up quite a bit by
just using llvm::TrailingObjects. This is a large
TrailingObjects list, but most things are length '0'.
Differential Revision: https://reviews.llvm.org/D50531
llvm-svn: 339380
As a part of attempting to clean up the way attributes are
printed, this patch adds an operator << to the diagnostics/
partialdiagnostics so that ParsedAttr can be sent directly.
This patch also rewrites a large amount* of the times when
ParsedAttr was printed using its IdentifierInfo object instead
of being printed itself.
*"a large amount" == "All I could find".
llvm-svn: 339344
gcc defines an intrinsic called __builtin_clrsb which counts the number of extra sign bits on a number. This is equivalent to counting the number of leading zeros on a positive number or the number of leading ones on a negative number and subtracting one from the result. Since we can't count leading ones we need to invert negative numbers to count zeros.
This patch will cause the builtin to be expanded inline while gcc uses a call to a function like clrsbdi2 that is implemented in libgcc. But this is similar to what we already do for popcnt. And I don't think compiler-rt supports clrsbdi2.
Differential Revision: https://reviews.llvm.org/D50168
llvm-svn: 339282
Summary:
When checking a class or function the described class or function template
is checked too.
Split StructuralEquivalenceContext::Finish into multiple functions.
Improved test with symmetric check, added new tests.
Reviewers: martong, a.sidorin, a_sidorin, bruno
Reviewed By: martong, a.sidorin
Subscribers: rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D49223
llvm-svn: 339256
Summary:
At equality check of fields without name the index of fields is compared.
At determining the index of a field all fields of the parent context
should be loaded from external source to find the field at all.
Reviewers: a.sidorin, a_sidorin, r.stahl
Reviewed By: a.sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49796
llvm-svn: 339226
declare target.
According to OpenMP 5.0, variables captured in lambdas in declare target
regions must be considered as implicitly declare target.
llvm-svn: 339152
It now actually produces a signed APSInt when the QualType passed into it is
signed, which is what any caller would expect.
Fixes a couple of crashes.
Differential Revision: https://reviews.llvm.org/D50363
llvm-svn: 339088
The change in the AST in r338135 caused us to accidentally support
inlining constructors of operator implicit arguments. Previously they were
hard to support because they were treated as arguments in expressions
but not in declarations, but now they can be transparently treated as
simple temporaries.
Add tests and comments to explain how it now works.
Differential Revision: https://reviews.llvm.org/D49627
llvm-svn: 339087
Some checkers require ASTContext. Having it in the constructor saves a
lot of boilerplate of having to pass it around.
Differential Revision: https://reviews.llvm.org/D50111
llvm-svn: 339079
DeclarationNameTable currently hold 3 "void *" to
FoldingSet<CXXSpecialName>, FoldingSet<CXXLiteralOperatorIdName>
and FoldingSet<CXXDeductionGuideNameExtra>.
CXXSpecialName, CXXLiteralOperatorIdName and
CXXDeductionGuideNameExtra are private classes holding extra
information about a "special" declaration name and are in
AST/DeclarationName.cpp. The original intent seems to have
been to keep these classes private and only expose
DeclarationNameExtra and DeclarationName (the code dates from
2008 and has not been significantly changed since).
However this make the code less straightforward than necessary
because of the need to have "void *" in DeclarationNameTable
(with 1 of 3 comments wrong) and to manually allocate/deallocate
the FoldingSets.
Moreover removing the extra indirections reduce the run-time of
an fsyntax-only on all of Boost by 2.3% which is not totally
unexpected given how frequently this data structure is used
(especially for C++).
A concern raised by erichkeane during the review was that
including Type.h would increase the compile time unreasonably.
However test builds (both clean and incremental) showed that
this patch did not result in any compile time increase.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50261
llvm-svn: 339030
This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values.
Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum.
Differential Revision: https://reviews.llvm.org/D48661
llvm-svn: 339028
- Print negative numbers correctly
- Handle APInts of different sizes
- Add formal unit tests for FixedPointValueToString
- Add tests for checking correct printing when padding is set
- Restrict to printing in radix 10 since that's all we need for now
Differential Revision: https://reviews.llvm.org/D49945
llvm-svn: 339026
Move the enum { ObjCMethodFamilyBitWidth = 4 } to the top of
the class. For some dark reason having the enum between the
bitfields breaks the packing with gcc version 7.3-win32 20180312.
Reported by: Abramo Bagnara (by email)
llvm-svn: 339017
These forward declarations for various classes in the Type
hierarchy are not needed since they are all forward declared
systematically a few lines below.
llvm-svn: 338966
__builtin_memmove (in non-type-punning cases).
This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.
__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.
This reinstates r338455, reverted in r338602, with a fix to avoid trying
to constant-evaluate a memcpy call if either pointer operand has an
invalid designator.
llvm-svn: 338941
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
Clang format got the best of me... it introduced spaces around something
in a table-genned file, so it was interpreted as an array and not a
code block.
llvm-svn: 338889
Add a comment in ObjCMethodDecl and ObjCContainerDecl stating that
we store some bits in ObjCMethodDeclBits and ObjCContainerDeclBits.
This was missed by the recent move in
r338641 : [AST][4/4] Move the bit-fields from ObjCMethodDecl
and ObCContainerDecl into DeclContext
llvm-svn: 338888
Factored out from https://reviews.llvm.org/D49729
following @erichkeane comments.
* Add missing classes in the list of classes
deriving directly from DeclContext.
* Move the friend declarations together and
add a comment for why they are required.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D49790
llvm-svn: 338887
Summary:
This adds support to libclang for reading the flag_enum attribute.
This also bumps CINDEX_VERSION_MINOR for this patch series.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49635
llvm-svn: 338820
Summary: This allows libclang to access the actual names of property setters and getters without needing to go through the indexer API. Usually default names are used, but the property can specify a different name.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49634
llvm-svn: 338816
Summary:
Having access to implicit attributes is sometimes useful so users of libclang don't have to duplicate some of the logic in sema.
This depends on D49081 since it also adds a CXTranslationUnit flag.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49631
llvm-svn: 338815
Summary:
This adds support to libclang for identifying ObjC related attributes that don't take arguments.
All attributes but NSObject and NSConsumed are tested.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49127
llvm-svn: 338813
Summary:
This patch adds a clang-c API for querying the nullability of an AttributedType.
The test here also tests D49081
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49082
llvm-svn: 338809
Summary:
This patch adds support to the libclang API for identifying AttributedTypes in CXTypes and reading the modified type that the type points to. Currently AttributedTypes are skipped. This patch continues to skip AttributedTypes by default, but adds a parsing option to CXTranslationUnit to include AttributedTypes.
This patch depends on D49066 since it also adds a CXType.
Testing will be added in another patch which depends on this one.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49081
llvm-svn: 338808
Summary:
This patch adds support to the libclang API for identifying ObjCTypeParams in CXTypes.
This patch depends on D49063 since both patches add new values to CXTypeKind.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49066
llvm-svn: 338807
Summary: This patch adds support to the clang-c API for identifying ObjCObjects in CXTypes, enumerating type args and protocols on ObjCObjectTypes, and retrieving the base type of ObjCObjectTypes. Currently only ObjCInterfaceTypes are exposed, which do not have type args or protocols.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49063
llvm-svn: 338804
Recommit of r335084 after revert in r335516.
... 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 order, and therefore printed in the wrong order in
-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 effect, especially on
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 attributes' order was changed instead.
This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. 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 reverse. 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.
Differential Revision: https://reviews.llvm.org/D48100
llvm-svn: 338800
We can't read a deduced return type until we are sure that the types referred
to by it are not in the middle of being loaded. So defer all reading of such
deduced return types until the end of the recursive deserialization step.
Also, when we load a function type that has a deduced return type, update all
other redeclarations of the function to have that deduced return type.
llvm-svn: 338798
The way address space declarations for builtins currently work
is nearly useless. The code assumes the address spaces used for
builtins is a confusingly named "target address space" from user
code using __attribute__((address_space(N))) that matches
the builtin declaration. There's no way to use this to declare
a builtin that returns a language specific address space.
The terminology used is highly cofusing since it has nothing
to do with the the address space selected by the target to use
for a language address space.
This feature is essentially unused as-is. AMDGPU and NVPTX
are the only in-tree targets attempting to use this. The AMDGPU
builtins certainly do not behave as intended (i.e. all of the
builtins returning pointers can never compile because the numbered
address space never matches the expected named address space).
The NVPTX builtins are missing tests for some, and the others
seem to rely on an implicit addrspacecast.
Change the used address space for builtins based on a target
hook to allow using a language address space for a builtin.
This allows the same builtin declaration to be used for multiple
languages with similarly purposed address spaces (e.g. the same
AMDGPU builtin can be used in OpenCL and CUDA even though the
constant address spaces are arbitarily different).
This breaks the possibility of using arbitrary numbered
address spaces alongside the named address spaces for builtins.
If this is an issue we probably need to introduce another builtin
declaration character to distinguish language address spaces from
so-called "target address spaces".
llvm-svn: 338707
DeclContext has a little less than 8 bytes free due to the alignment
requirements on 64 bits archs. This set of patches moves the
bit-fields from classes deriving from DeclContext into DeclContext.
On 32 bits archs this increases the size of DeclContext by 4 bytes
but this is balanced by an equal or larger reduction in the size
of the classes deriving from it.
On 64 bits archs the size of DeclContext stays the same but
most of the classes deriving from it shrink by 8/16 bytes.
(-print-stats diff here https://reviews.llvm.org/D49728)
When doing an -fsyntax-only on all of Boost this result
in a 3.6% reduction in the size of all Decls and
a 1% reduction in the run time due to the lower cache
miss rate.
For now CXXRecordDecl is not touched but there is
an easy 6 (if I count correctly) bytes gain available there
by moving some bits from DefinitionData into the free
space of DeclContext. This will be the subject of another patch.
This patch sequence also enable the possibility of refactoring
FunctionDecl: To save space some bits from classes deriving from
FunctionDecl were moved to FunctionDecl. This resulted in a
lot of stuff in FunctionDecl which do not belong logically to it.
After this set of patches however it is just a simple matter of
adding a SomethingDeclBitfields in DeclContext and moving the
bits to it from FunctionDecl.
This first patch introduces the anonymous union in DeclContext
and all the *DeclBitfields classes holding the bit-fields, and moves
the bits from TagDecl, EnumDecl and RecordDecl into DeclContext.
This patch is followed by https://reviews.llvm.org/D49732,
https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734.
Differential Revision: https://reviews.llvm.org/D49729
Patch By: bricci
llvm-svn: 338630
It caused asserts during Chromium builds, see reply on the cfe-commits thread.
> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.
llvm-svn: 338602
This adds support for the unroll_and_jam pragma, to go with the recently
added unroll and jam pass. The name of the pragma is the same as is used
in the Intel compiler, and most of the code works the same as for unroll.
#pragma clang loop unroll_and_jam has been separated into a different
patch. This part adds #pragma unroll_and_jam with an optional count, and
#pragma no_unroll_and_jam to disable the transform.
Differential Revision: https://reviews.llvm.org/D47267
llvm-svn: 338566
Summary:
rC337815 / D49508 had to cannibalize one bit of `CastExprBitfields::BasePathSize` in order to squeeze `PartOfExplicitCast` boolean.
That reduced the maximal value of `PartOfExplicitCast` from 9 bits (~512) down to 8 bits (~256).
Apparently, that mattered. Too bad there weren't any tests.
It caused [[ https://bugs.llvm.org/show_bug.cgi?id=38356 | PR38356 ]].
So we need to increase `PartOfExplicitCast` back at least to 9 bits, or a bit more.
For obvious reasons, we can't do that in `CastExprBitfields` - that would blow up the size of every `Expr`.
So we need to either just add a variable into the `CastExpr` (as done here),
or use `llvm::TrailingObjects`. The latter does not seem to be straight-forward.
Perhaps, that needs to be done not for the `CastExpr` itself, but for all of it's `final` children.
Reviewers: rjmccall, rsmith, erichkeane
Reviewed By: rjmccall
Subscribers: bricci, hans, cfe-commits, waddlesplash
Differential Revision: https://reviews.llvm.org/D50050
llvm-svn: 338489
Newly added methods allow reasoning about the stack frame of the call (as
opposed to the stack frame on which the call was made, which was always
available) - obtain the stack frame context, obtain parameter regions - even if
the call is not going to be (or was not) inlined, i.e. even if the analysis
has never actually entered the stack frame.
Differential Revision: https://reviews.llvm.org/D49715
llvm-svn: 338474
This patch adds support for a new attribute, [[clang::lifetimebound]], that
indicates that the lifetime of a function result is related to one of the
function arguments. When walking an initializer to make sure that the lifetime
of the initial value is at least as long as the lifetime of the initialized
object, we step through parameters (including the implicit object parameter of
a non-static member function) that are marked with this attribute.
There's nowhere to write an attribute on the implicit object parameter, so in
lieu of that, it may be applied to a function type (where it appears
immediately after the cv-qualifiers and ref-qualifier, which is as close to a
declaration of the implicit object parameter as we have). I'm currently
modeling this in the AST as the attribute appertaining to the function type.
Differential Revision: https://reviews.llvm.org/D49922
llvm-svn: 338464
__builtin_memmove (in non-type-punning cases).
This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.
__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.
llvm-svn: 338455
This is a refactoring patch; no functional change intended.
The common part of ConstructionContextLayer and ConstructedObjectKey is
factored out into a new structure, ConstructionContextItem.
Various sub-kinds of ConstructionContextItem are enumerated in order to
provide richer information about construction contexts.
Differential Revision: https://reviews.llvm.org/D49210.
llvm-svn: 338439
In r330377 and r338425 we have already identified what constitutes function
argument constructors and added stubs in order to prevent confusing them
with other temporary object constructors.
Now we implement a ConstructionContext sub-class to carry all the necessary
information about the construction site, namely call expression and argument
index.
On the analyzer side, the patch interacts with the recently implemented
pre-C++17 copy elision support in an interesting manner. If on the CFG side we
didn't find a construction context for the elidable constructor, we build
the CFG as if the elidable constructor is not elided, and the non-elided
constructor within it is a simple temporary. But the same problem may occur
in the analyzer: if the elidable constructor has a construction context but
the analyzer doesn't implement such context yet, the analyzer should also
try to skip copy elision and still inline the non-elided temporary constructor.
This was implemented by adding a "roll back" mechanism: when elision fails,
roll back the changes and proceed as if it's a simple temporary. The approach
is wonky, but i'm fine with that as long as it's merely a defensive mechanism
that should eventually go away once all construction contexts become supported.
Differential Revision: https://reviews.llvm.org/D48681.
llvm-svn: 338436
Like any normal funciton, Objective-C message can return a C++ object
in Objective-C++. Such object would require a construction context.
This patch, therefore, is an extension of r327343 onto Objective-C++.
Differential Revision: https://reviews.llvm.org/D48608
llvm-svn: 338426
Any of these template argument kinds can be represented with an expression, so
accept them in this constructor.
Patch by Balaji Iyer!
rdar://41459965
Differential revision: https://reviews.llvm.org/D49766
llvm-svn: 338338
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
unsigned char store = 0;
bool consume(unsigned int val);
void test(unsigned long val) {
if (consume(val)) {
// the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
// If their bit widths are different on this platform, the implicit
// truncation happens. And if that `unsigned long` had a value bigger
// than UINT_MAX, then you may or may not have a bug.
// Similarly, integer addition happens on `int`s, so `store` will
// be promoted to an `int`, the sum calculated (0+768=768),
// and the result demoted to `unsigned char`, and stored to `store`.
// In this case, the `store` will still be 0. Again, not always intended.
store = store + 768; // before addition, 'store' was promoted to int.
}
// But yes, sometimes this is intentional.
// You can either make the conversion explicit
(void)consume((unsigned int)val);
// or mask the value so no bits will be *implicitly* lost.
(void)consume((~((unsigned int)0)) & val);
}
```
Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.
The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.
The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ
Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.
As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.
One thing i know isn't handled is bitfields.
This is a clang part.
The compiler-rt part is D48959.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)
Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane
Reviewed By: rsmith, vsk, erichkeane
Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D48958
llvm-svn: 338288
All use cases of DeclRegion actually have ValueDecl there,
and getting the name from declaration comes in very handy.
Differential Revision: https://reviews.llvm.org/D49998
llvm-svn: 338286
The "Procedure Call Procedure Call Standard for the ARM® Architecture"
(https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that
composite types are passed according to their "natural alignment", i.e. the
alignment before alignment adjustment on the entire composite is applied.
The same applies for AArch64 ABI.
Clang, however, used the adjusted alignment.
GCC already implements the ABI correctly. With this patch Clang becomes
compatible with GCC and passes such arguments in accordance with AAPCS.
Differential Revision: https://reviews.llvm.org/D46013
llvm-svn: 338279
CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__
function, only __shared__ variables or variables without any device
memory qualifiers may be declared with static storage class.
It is unclear how a function-scope non-const static variable
without device memory qualifier is implemented, therefore only static
const variable without device memory qualifier is allowed, which
can be emitted as a global variable in constant address space.
Currently clang only allows function-scope static variable with
__shared__ qualifier.
This patch also allows function-scope static const variable without
device memory qualifier and emits it as a global variable in constant
address space.
Differential Revision: https://reviews.llvm.org/D49931
llvm-svn: 338188
Some functions/classes have renamed while the comments still use the old names. Delete them per coding style.
Also some whitespace cleanup.
llvm-svn: 338183
Summary:
This patch allows the parsing of a postfix expression involving a fold expression, which is legal as a fold-expression is a primary-expression.
See also https://llvm.org/pr38282
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49848
llvm-svn: 338170
Summary:
Some targets support only default set of the debug options and do not
support additional debug options, like NVPTX target. Patch introduced
virtual function supportsDebugInfoOptions() that can be overloaded
by the toolchain, checks if the target supports some debug
options and emits warning when an unsupported debug option is
found.
Reviewers: echristo
Subscribers: aprantl, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D49148
llvm-svn: 338155
ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher
is required to support it.
Adding a hasDeclaration support as well, as it's not very useful without
it.
Differential Revision: https://reviews.llvm.org/D49701
llvm-svn: 338140
ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher
is required to support it.
Adding a hasDeclaration support as well, as it's not very useful without
it.
Differential Revision: https://reviews.llvm.org/D49701
llvm-svn: 338137
Summary:
As discussed in IRC with @rsmith, it is slightly not good to keep that in the `CastExpr` itself:
Given the explicit cast, which is represented in AST as an `ExplicitCastExpr` + `ImplicitCastExpr`'s,
only the `ImplicitCastExpr`'s will be marked as `PartOfExplicitCast`, but not the `ExplicitCastExpr` itself.
Thus, it is only ever `true` for `ImplicitCastExpr`'s, so we don't need to write/read/dump it for `ExplicitCastExpr`'s.
We don't need to worry that we write the `PartOfExplicitCast` in PCH after `CastExpr::path_iterator`,
since the `ExprImplicitCastAbbrev` is only used when the `NumBaseSpecs == 0`, i.e. there is no 'path'.
Reviewers: rsmith, rjmccall, erichkeane, aaron.ballman
Reviewed By: rsmith, erichkeane
Subscribers: vsk, cfe-commits, rsmith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D49838
llvm-svn: 338108
Clang already has L__FUNCTION__ as a workaround for dealing with
pre-processor code that expects to be able to do L##__FUNCTION__ in a
macro. This patch implements the same logic for __FUNCSIG__.
Fixes PR38295.
llvm-svn: 338083
Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64.
For example, small structs with non-trivial copy constructors or virtual
function tables are passed indirectly. Currently, they are passed in registers
when compiled with clang.
Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar
Reviewed By: rnk, mstorsjo
Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D49770
llvm-svn: 338076
Check each case value in turn while parsing it, performing the
conversion to the switch type within the context of the expression
itself. This will become necessary in order to properly handle cleanups
for temporaries created as part of the case label (in an upcoming
patch). For now it's just good hygiene.
This necessitates moving the checking for the switch condition itself to
earlier, so that the destination type is available when checking the
case labels.
As a nice side-effect, we get slightly improved diagnostic quality and
error recovery by separating the case expression checking from the case
statement checking and from tracking whether there are discarded case
labels.
llvm-svn: 338056
Thomas Lively