Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
The right shift operator was not seen as a valid operator in a fold expression, which is PR32563.
Patch by Nicolas Lesser ("Blitz Rakete")!
llvm-svn: 317032
Extend ExprInspection checker to make it possible to dump the issue hash of
arbitrary expressions. This change makes it possible to make issue hash related
tests more concise and also makes debugging issue hash related problems easier.
Differential Revision: https://reviews.llvm.org/D38844
llvm-svn: 316899
Summary:
Clang typically warns that in the following class hierarchy, 'A' is
inaccessible because there is no series of casts that the user can
write to access it unambiguously:
struct A { };
struct B : A { };
struct C : A, B { };
MSVC allows the user to convert from C* to A*, though, and we've
encountered this issue in the latest Windows SDK headers.
This patch allows this conversion when -fms-compatibility is set and
adds a warning for it under -Wmicrosoft-inaccessible-base.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39389
llvm-svn: 316807
Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.
This patch also sets the 'default' for this checking to
'supported', since only X86 has implemented the support
for checking valid CPU names and Feature Names.
One test was changed to i686, since it uses a lakemont,
which would otherwise be prohibited in x86_64.
Differential Revision: https://reviews.llvm.org/D39357
llvm-svn: 316783
This commit changes the way that the refactoring operation classes are
structured:
- Users have to call `initiate` instead of constructing an instance of the
class. The `initiate` is now supposed to have custom initiation logic, and
you don't need to subclass the builtin requirements.
- A new `describe` function returns a structure with the id, title and the
description of the refactoring operation.
The refactoring action classes are now placed into one common place in
RefactoringActions.cpp instead of being separate.
Differential Revision: https://reviews.llvm.org/D38985
llvm-svn: 316780
It looks like at one time Options.td was in alphabetical order, but that looks to have long been broken. The result is that it all the no- x86 options got separated from their other friends for no good reason.
This patch puts them all together in one place with the no- paired with its none negated version.
I've kept all the SSE and AVX/AVX512 bits together since they represent a somewhat linear progression of features. The rest I just put in alphabetical order after.
Differential Revision: https://reviews.llvm.org/D39341
llvm-svn: 316705
Changes all existing attributes that currently use GNU<"attr"> and CXX11<"clang", "attr> spellings to instead use the Clang<"attr"> spelling.
No additional tests are necessary because the existing tests already use both spellings for the attributes converted to the new spelling. No functional changes are expected.
llvm-svn: 316658
Summary:
This defines a `clang::tooling::ToolExecutor` interface that can be extended to support different execution plans including standalone execution on a given set of TUs or parallel execution on all TUs in a codebase.
In order to enable multiprocessing execution, tool actions are expected to output result into a `ToolResults` interface provided by executors. The `ToolResults` interface abstracts how results are stored e.g. in-memory for standalone executions or on-disk for large-scale execution.
New executors can be registered as `ToolExecutorPlugin`s via the `ToolExecutorPluginRegistry`. CLI tools can use `createExecutorFromCommandLineArgs` to create a specific registered executor according to the command-line arguments.
This patch also implements `StandaloneToolExecutor` which has the same behavior as the current `ClangTool` interface, i.e. execute frontend actions on a given set of TUs. At this point, it's simply a wrapper around `ClangTool` at this point.
This is still experimental but expected to replace the existing `ClangTool` interface so that specific tools would not need to worry about execution.
Reviewers: klimek, arphaman, hokein, sammccall
Reviewed By: klimek
Subscribers: cfe-commits, djasper, mgorny, omtcyfz
Differential Revision: https://reviews.llvm.org/D34272
llvm-svn: 316653
https://bugs.llvm.org/show_bug.cgi?id=33904
Happens when static function is accessed via the class variable. That leads to incorrect overloads number because the variable is considered as the first argument.
struct Bar {
static void foo(); static void foo(int);
};
int main() {
Bar b;
b.foo(/*complete here*/); // did not work before
Bar::foo(/*complete here*/); // worked fine
}
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D36390
llvm-svn: 316646
Summary:
CUDA 9's minimum sm is sm_30.
Ideally we should also make sm_30 the default when compiling with CUDA
9, but that seems harder than it should be.
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D39109
llvm-svn: 316611
This commit adds an initial, skeleton outline of the "extract function"
refactoring. The extracted function doesn't capture variables / rewrite code
yet, it just basically does a simple copy-paste.
The following initiation rules are specified:
- extraction can only be done for executable code in a function/method/block.
This means that you can't extract a global variable initialize into a function
right now.
- simple literals and references are not extractable.
This commit also adds support for full source ranges to clang-refactor's test
mode.
Differential Revision: https://reviews.llvm.org/D38982
llvm-svn: 316465
With enabled CINDEXTEST_CODE_COMPLETE_PATTERNS env option (which enables
IncludeCodePatterns in completion options) code completion after colon
currently suggests access modifiers with 2 completion chunks which is
incorrect.
Example:
class A : <Cursor>B
{
}
Currently we get 'NotImplemented:{TypedText public}{Colon :} (40)'
but the correct line is just 'NotImplemented:{TypedText public} (40)'
The fix introduces more specific scope that occurs between ':' and '{'
It allows us to determine when we don't need to add ':' as a second
chunk to the public/protected/private access modifiers.
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D38618
llvm-svn: 316436
Summary: This returns error instead of exiting the program in case of error.
Reviewers: klimek, hokein
Reviewed By: hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39042
llvm-svn: 316433
Allow Obj-C ivars with incomplete array type but only as the last ivar.
Also add a requirement for ivars that contain a flexible array member to
be at the end of class too. It is possible to add in a subclass another
ivar at the end but we'll emit a warning in this case. Also we'll emit a
warning if a variable sized ivar is declared in class extension or in
implementation because subclasses won't know they should avoid adding
new ivars.
In ARC incomplete array objects are treated as __unsafe_unretained so
require them to be marked as such.
Prohibit synthesizing ivars with flexible array members because order of
synthesized ivars is not obvious and tricky to control. Spelling out
ivar explicitly gives control to developers and helps to avoid surprises
with unexpected ivar ordering.
For C and C++ changed diagnostic to tell explicitly a field is not the
last one and point to the next field. It is not as useful as in Obj-C
but it is an improvement and it is consistent with Obj-C. For C for
unions emit more specific err_flexible_array_union instead of generic
err_field_incomplete.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38773
llvm-svn: 316381
This is for consistency with lld-link, see https://reviews.llvm.org/D38972
Also give --version a help text so it shows up in --help / /? output (for
both clang-cl and regular clang).
llvm-svn: 316335
In order to identify the copy deduction candidate, I considered two approaches:
- attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution.
- using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides
After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union.
Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added.
References:
See https://bugs.llvm.org/show_bug.cgi?id=34970
See http://wg21.link/p0620r0
llvm-svn: 316292
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
llvm-svn: 316245
GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330
An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html
Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.
Differential Revision: https://reviews.llvm.org/D37954
llvm-svn: 316193
consecutive statements
This commit adds a CodeRangeASTSelection value to the refactoring library. This
value represents a set of selected statements in one body of code.
Differential Revision: https://reviews.llvm.org/D38835
llvm-svn: 316104
This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"
The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The
-mhvx flag adds the target-feature "+hvxv{hvx_version}"
The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.
The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"
The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag
The macro HVX_LENGTH is defined and is set to the length of the vector.
Eg: #define HVX_LENGTH 64
The macro HVX_ARCH is defined and is set to the version of the HVX.
Eg: #define HVX_ARCH 62
Differential Revision: https://reviews.llvm.org/D38852
llvm-svn: 316102
George Karpenkov