This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303712 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a fix-it for the -Wunguarded-availability warning. This fix-it
is similar to the Swift one: it suggests that you wrap the statement in an
`if (@available)` check. The produced fixits are indented (just like the Swift
ones) to make them look nice in Xcode's fix-it preview.
rdar://31680358
Differential Revision: https://reviews.llvm.org/D32424
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302253 91177308-0d34-0410-b5e6-96231b3b80d8
blocks and lambdas
Prior to this commit Clang emitted the old "partial availability" warning for
expressions that referred to declarations that were not yet introduced in
blocks and lambdas that were not in a function/method. This commit ensures that
top-level blocks and lambdas use the new unguarded availability checks.
rdar://31835952
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301409 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this commit the external_source_symbol attribute wasn't supported by
#pragma clang attribute for the following two reasons:
- The Named attribute subject hasn't been supported by TableGen.
- There was no way to specify a subject match rule for #pragma clang attribute
that could operate on a set of attribute subjects (e.g. the ones that derive
from NamedDecl).
This commit fixes the two issues and thus adds external_source_symbol support to
#pragma clang attribute.
rdar://31169028
Differential Revision: https://reviews.llvm.org/D32176
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300712 91177308-0d34-0410-b5e6-96231b3b80d8
This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300556 91177308-0d34-0410-b5e6-96231b3b80d8
Some tests fail on the Windows buildbots. I will have to investigate more.
This commit reverts r300539, r300540 and r300542.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300543 91177308-0d34-0410-b5e6-96231b3b80d8
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300539 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch implements parsing of [[clang::suppress(rule, ...)]]
and [[gsl::suppress(rule, ...)]] attributes.
C++ Core Guidelines depend heavily on tool support for
rule enforcement. They also propose a way to suppress
warnings [1] which is by annotating any ancestor in AST
with the C++11 attribute [[gsl::suppress(rule1,...)]].
To have a mechanism to suppress non-C++ Core
Guidelines specific, an additional spelling of [[clang::suppress]]
is defined.
For example, to suppress the warning cppcoreguidelines-slicing,
one could do
```
[[clang::suppress("cppcoreguidelines-slicing")]]
void f() { ... code that does slicing ... }
```
or
```
void g() {
Derived b;
[[clang::suppress("cppcoreguidelines-slicing")]]
Base a{b};
[[clang::suppress("cppcoreguidelines-slicing")]] {
doSomething();
Base a2{b};
}
}
```
This parsing can then be used by clang-tidy, which includes multiple
C++ Core Guidelines rules, to suppress warnings (see
https://reviews.llvm.org/D24888).
For the exact naming of the rule in the attribute, there
are different possibilities, which will be defined in the
corresponding clang-tidy patch.
Currently, clang-tidy supports suppressing of warnings through "//
NOLINT" comments. There are some advantages that the attribute has:
- Suppressing specific warnings instead of all warnings
- Suppressing warnings in a block (namespace, function, compound
statement)
- Code formatting may split a statement into multiple lines,
thus a "// NOLINT" comment may be on the wrong line
I'm looking forward to your comments!
[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement
Reviewers: alexfh, aaron.ballman, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24886
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298880 91177308-0d34-0410-b5e6-96231b3b80d8
Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410
Differential Revision: https://reviews.llvm.org/D31245
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298634 91177308-0d34-0410-b5e6-96231b3b80d8
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298410 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds support for a new attribute that will be used to
distinguish between extensible and inextensible enums. There are three
main purposes of this attribute:
1. Give better control over when enum-related warnings are issued.
For example, in the code below, clang will not issue a -Wassign-enum
warning if the enum is marked "open":
enum __attribute__((enum_extensibility(closed))) EnumClosed {
B0 = 1, B1 = 10
};
enum __attribute__((enum_extensibility(open))) EnumOpen {
C0 = 1, C1 = 10
};
enum EnumClosed ec = 100; // warning issued
enum EnumOpen eo = 100; // no warning
2. Enable code-completion and debugging tools to offer better
suggestions.
3. Make it easier for swift's clang importer to determine which swift
type an enum should be mapped to.
For more details, see the discussion I started on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html
rdar://problem/12764379
rdar://problem/23145650
Differential Revision: https://reviews.llvm.org/D30766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298332 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Functions with the "xray_log_args" attribute will tell LLVM to emit a special
XRay sled for compiler-rt to copy any call arguments to your logging handler.
Reviewers: dberris
Reviewed By: dberris
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D29704
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296999 91177308-0d34-0410-b5e6-96231b3b80d8
and the nature of a declaration
This commit adds an external_source_symbol attribute to Clang. This attribute
specifies that a declaration originates from an external source and describes
the nature of that source. This attribute will be used to improve IDE features
like 'jump-to-definition' for mixed-language projects or project that use
auto-generated code.
rdar://30423368
Differential Revision: https://reviews.llvm.org/D29819
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@296649 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295686 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This teaches clang how to parse and lower the 'interrupt' and 'naked'
attributes.
This allows interrupt signal handlers to be written.
Reviewers: aaron.ballman
Subscribers: malcolm.parsons, cfe-commits
Differential Revision: https://reviews.llvm.org/D28451
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@294402 91177308-0d34-0410-b5e6-96231b3b80d8
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291418 91177308-0d34-0410-b5e6-96231b3b80d8
This is a recommit of r290149, which was reverted in r290169 due to msan
failures. msan was failing because we were calling
`isMostDerivedAnUnsizedArray` on an invalid designator, which caused us
to read uninitialized memory. To fix this, the logic of the caller of
said function was simplified, and we now have a `!Invalid` assert in
`isMostDerivedAnUnsizedArray`, so we can catch this particular bug more
easily in the future.
Fingers crossed that this patch sticks this time. :)
Original commit message:
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290297 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fails MSan when running test/CodeGen/object-size.c in
a confusing way. After some discussion with George, it isn't really
clear what is going on here. We can make the MSan failure go away by
testing for the invalid bit, but *why* things are invalid isn't clear.
And yet, other code in the surrounding area is doing precisely this and
testing for invalid.
George is going to take a closer look at this to better understand the
nature of the failure and recommit it, for now backing it out to clean
up MSan builds.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290169 91177308-0d34-0410-b5e6-96231b3b80d8
This patch does three things:
- Gives us the alloc_size attribute in clang, which lets us infer the
number of bytes handed back to us by malloc/realloc/calloc/any user
functions that act in a similar manner.
- Teaches our constexpr evaluator that evaluating some `const` variables
is OK sometimes. This is why we have a change in
test/SemaCXX/constant-expression-cxx11.cpp and other seemingly
unrelated tests. Richard Smith okay'ed this idea some time ago in
person.
- Uniques some Blocks in CodeGen, which was reviewed separately at
D26410. Lack of uniquing only really shows up as a problem when
combined with our new eagerness in the face of const.
Differential Revision: https://reviews.llvm.org/D14274
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290149 91177308-0d34-0410-b5e6-96231b3b80d8
Although not specifically mentioned in the documentation, MSVC accepts
__uuidof(…) and declspec(uuid("…")) attributes on enumeration types in
addition to structs/classes. This is meaningful, as such types *do* have
associated UUIDs in ActiveX typelibs, and such attributes are included
by default in the wrappers generated by their #import construct, so they
are not particularly unusual.
clang currently rejects the declspec with a –Wignored-attributes
warning, and errors on __uuidof() with “cannot call operator __uuidof on
a type with no GUID” (because it rejected the uuid attribute, and
therefore finds no value). This is causing problems for us while trying
to use clang-tidy on a codebase that makes heavy use of ActiveX.
I believe I have found the relevant places to add this functionality,
this patch adds this case to clang’s implementation of these MS
extensions. patch is against r285994 (or actually the git mirror
80464680ce).
Both include an update to test/Parser/MicrosoftExtensions.cpp to
exercise the new functionality.
This is my first time contributing to LLVM, so if I’ve missed anything
else needed to prepare this for review just let me know!
__uuidof: https://msdn.microsoft.com/en-us/library/zaah6a61.aspx
declspec(uuid("…")): https://msdn.microsoft.com/en-us/library/3b6wkewa.aspx
#import: https://msdn.microsoft.com/en-us/library/8etzzkb6.aspx
Reviewers: aaron.ballman, majnemer, rnk
Differential Revision: https://reviews.llvm.org/D26846
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289567 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds an objc_subclassing_restricted attribute into clang. This
attribute acts similarly to 'final' - Objective-C classes with this attribute
can't be subclassed. However, @interface declarations that have
objc_subclassing_restricted but don't have @implementation are allowed to
inherit other @interface declarations with objc_subclassing_restricted. This is
needed to describe the Swift class hierarchy in clang while making sure that
the Objective-C classes cannot subclass the Swift classes.
This attribute is already implemented in a fork of clang that's used for Swift
(https://github.com/apple/swift-clang) and this patch moves that code to the
upstream clang repository.
rdar://28937548
Differential Revision: https://reviews.llvm.org/D25993
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285391 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285098 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r285007 and reapply r284990, with a fix for the
opencl test that I broke. Original commit message follows:
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@285019 91177308-0d34-0410-b5e6-96231b3b80d8
These new builtins support a mechanism for logging OS events, using a
printf-like format string to specify the layout of data in a buffer.
The _buffer_size version of the builtin can be used to determine the size
of the buffer to allocate to hold the data, and then __builtin_os_log_format
can write data into that buffer. This implements format checking to report
mismatches between the format string and the data arguments. Most of this
code was written by Chris Willmore.
Differential Revision: https://reviews.llvm.org/D25888
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@284990 91177308-0d34-0410-b5e6-96231b3b80d8
Also add a test that we disallow
__constant__ __shared__ int x;
because it's possible to break this without breaking
__shared__ __constant__ int x;
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D25125
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282985 91177308-0d34-0410-b5e6-96231b3b80d8
__attribute__((amdgpu_flat_work_group_size(<min>, <max>))) - request minimum and maximum flat work group size
__attribute__((amdgpu_waves_per_eu(<min>[, <max>]))) - request minimum and/or maximum waves per execution unit
Differential Revision: https://reviews.llvm.org/D24513
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282371 91177308-0d34-0410-b5e6-96231b3b80d8
This mostly behaves cl.exe's behavior, even though clang-cl is stricter in some
corner cases and more lenient in others (see the included test).
To make the uuid declared previously here diagnostic work correctly, tweak
stripTypeAttributesOffDeclSpec() to keep attributes in the right order.
https://reviews.llvm.org/D24469
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281367 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280525 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.
Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.
This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.
```c++
// -std=c++14
#define SAFE_STATIC __attribute__((require_constant_initialization)) static
struct T {
constexpr T(int) {}
~T();
};
SAFE_STATIC T x = {42}; // OK.
SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
// copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.
Reviewers: majnemer, rsmith, aaron.ballman
Subscribers: jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D23385
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@280516 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Based on a patch by Michael Mueller.
This attribute specifies that a function can be hooked or patched. This
mechanism was originally devised by Microsoft for hotpatching their
binaries (which they're constantly updating to stay ahead of crackers,
script kiddies, and other ne'er-do-wells on the Internet), but it's now
commonly abused by Windows programs that want to hook API functions. It
is for this reason that this attribute was added to GCC--hence the name,
`ms_hook_prologue`.
Depends on D19908.
Reviewers: rnk, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D19909
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278050 91177308-0d34-0410-b5e6-96231b3b80d8
This means that a function marked with an availability attribute can safely
refer to a declaration that is greater than the deployment target, but less then
or equal to the context availability without -Wpartial-availability firing.
Differential revision: https://reviews.llvm.org/D22697
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277058 91177308-0d34-0410-b5e6-96231b3b80d8
-fxray-instrument: enables XRay annotation of IR
-fxray-instruction-threshold: configures the threshold for function size (looking at IR instructions), and allow LLVM to decide whether to add the nop sleds later on in the process.
Also implements the related xray_always_instrument and xray_never_instrument function attributes.
Patch by Dean Michael Berris.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275330 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Create a new Frontend LangOpt to specify the renderscript language. It
is enabled by the "-x renderscript" option from the driver.
Add a "kernel" function attribute only for RenderScript (an "ignored
attribute" warning is generated otherwise).
Make the NativeHalfType and NativeHalfArgsAndReturns LangOpts be implied
by the RenderScript LangOpt.
Reviewers: rsmith
Subscribers: cfe-commits, srhines
Differential Revision: http://reviews.llvm.org/D21198
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272342 91177308-0d34-0410-b5e6-96231b3b80d8
The layout_version attribute is pretty straightforward: use the layout
rules from version XYZ of MSVC when used like
struct __declspec(layout_version(XYZ)) S {};
The empty_bases attribute is more interesting. It tries to get the C++
empty base optimization to fire more often by tweaking the MSVC ABI
rules in subtle ways:
1. Disable the leading and trailing zero-sized object flags if a class
is marked __declspec(empty_bases) and is empty.
This means that given:
struct __declspec(empty_bases) A {};
struct __declspec(empty_bases) B {};
struct C : A, B {};
'C' will have size 1 and nvsize 0 despite not being annotated
__declspec(empty_bases).
2. When laying out virtual or non-virtual bases, disable the injection
of padding between classes if the most derived class is marked
__declspec(empty_bases).
This means that given:
struct A {};
struct B {};
struct __declspec(empty_bases) C : A, B {};
'C' will have size 1 and nvsize 0.
3. When calculating the offset of a non-virtual base, choose offset zero
if the most derived class is marked __declspec(empty_bases) and the
base is empty _and_ has an nvsize of 0.
Because of the ABI rules, this does not mean that empty bases
reliably get placed at offset 0!
For example:
struct A {};
struct B {};
struct __declspec(empty_bases) C : A, B { virtual ~C(); };
'C' will be pointer sized to account for the vfptr at offset 0.
'A' and 'B' will _not_ be at offset 0 despite being empty!
Instead, they will be located right after the vfptr.
This occurs due to the interaction betweeen non-virtual base layout
and virtual function pointer injection: injection occurs after the
nv-bases and shifts them down by the size of a pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270457 91177308-0d34-0410-b5e6-96231b3b80d8
When inferring availability attributes for tvos, watchos from ios, we
use the same source location and set the implicit bit to true.
So when emitting diagnostics on inferred attributes, we have a source
location.
rdar://25893544
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268793 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes, the declaration we found has inherited availability
attributes, attaching the note to it does not tell us where the
availability attributes are in the source.
Go through the redecl chain to find the declaration with actual
availability attributes.
rdar://25221771
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268786 91177308-0d34-0410-b5e6-96231b3b80d8
The 'nodebug' attribute had hand-coded constraints; replace those with
a Subjects line in Attr.td.
Also add a missing test to verify the attribute is okay on an
Objective-C method.
Differential Revision: http://reviews.llvm.org/D19689
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268065 91177308-0d34-0410-b5e6-96231b3b80d8
It makes compiler-rt tests fail if the gold plugin is enabled.
Revert "Rework interface for bitset-using features to use a notion of LTO visibility."
Revert "Driver: only produce CFI -fvisibility= error when compiling."
Revert "clang/test/CodeGenCXX/cfi-blacklist.cpp: Exclude ms targets. They would be non-cfi."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267871 91177308-0d34-0410-b5e6-96231b3b80d8
Bitsets, and the compiler features they rely on (vtable opt, CFI),
only have visibility within the LTO'd part of the linkage unit. Therefore,
only enable these features for classes with hidden LTO visibility. This
notion is based on object file visibility or (on Windows)
dllimport/dllexport attributes.
We provide the [[clang::lto_visibility_public]] attribute to override the
compiler's LTO visibility inference in cases where the class is defined
in the non-LTO'd part of the linkage unit, or where the ABI supports
calling classes derived from abstract base classes with hidden visibility
in other linkage units (e.g. COM on Windows).
If the cross-DSO CFI mode is enabled, bitset checks are emitted even for
classes with public LTO visibility, as that mode uses a separate mechanism
to cause bitsets to be exported.
This mechanism replaces the whole-program-vtables blacklist, so remove the
-fwhole-program-vtables-blacklist flag.
Because __declspec(uuid()) now implies [[clang::lto_visibility_public]], the
support for the special attr:uuid blacklist entry is removed.
Differential Revision: http://reviews.llvm.org/D18635
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267784 91177308-0d34-0410-b5e6-96231b3b80d8
The objc_runtime_visible attribute deals with an odd corner case where
a particular Objective-C class is known to the Objective-C runtime
(and, therefore, accessible by name) but its symbol has been hidden
for some reason. For such classes, teach CodeGen to use
objc_lookUpClass to retrieve the Class object, rather than referencing
the class symbol directly.
Classes annotated with objc_runtime_visible have two major limitations
that fall out from places where Objective-C metadata needs to refer to
the class (or metaclass) symbol directly:
* One cannot implement a subclass of an objc_runtime_visible class.
* One cannot implement a category on an objc_runtime_visible class.
Implements rdar://problem/25494092.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265201 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)).
This was commited in r263687 and reverted in 263752 due to misaligned
access.
rdar://20588929
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263958 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds a named argument to AvailabilityAttr, while r263652 adds an
optional string argument to __attribute__((deprecated)). This enables the
compiler to provide Fix-Its for deprecated declarations.
rdar://20588929
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263687 91177308-0d34-0410-b5e6-96231b3b80d8
Till now, preserve_mostcc/preserve_allcc calling convention attributes were only
available at the LLVM IR level. This patch adds attributes for
preserve_mostcc/preserve_allcc calling conventions to the C/C++ front-end.
The code was mostly written by Juergen Ributzka.
I just added support for the AArch64 target and tests.
Differential Revision: http://reviews.llvm.org/D18025
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263647 91177308-0d34-0410-b5e6-96231b3b80d8
Original patch by Stefan Bühler http://reviews.llvm.org/D12834
Difference between original and this one:
- fixed all comments in original code review
- added more tests, all new diagnostics now covered by tests
- moved abi_tag on re-declaration checks to Sema::mergeDeclAttributes
where they actually may work as designed
- clang-format + other stylistic changes
Mangle part will be sent for review as a separate patch.
Differential Revision: http://reviews.llvm.org/D17567
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263015 91177308-0d34-0410-b5e6-96231b3b80d8
exactly the same as clang's existing [[clang::fallthrough]] attribute, which
has been updated to have the same semantics. The one significant difference
is that [[fallthrough]] is ill-formed if it's not used immediately before a
switch label (even when -Wimplicit-fallthrough is disabled). To support that,
we now build a CFG of any function that uses a '[[fallthrough]];' statement
to check.
In passing, fix some bugs with our support for statement attributes -- in
particular, diagnose their use on declarations, rather than asserting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262881 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
OpenCL access qualifiers are now not only used for image types, refine it to avoid misleading,
Add semacheck for OpenCL access qualifier as well as test caees.
Reviewers: pekka.jaaskelainen, Anastasia, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D16040
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261961 91177308-0d34-0410-b5e6-96231b3b80d8
Use "strict" instead of "nopartial". Also make strictly not-introduced
share the same diagnostics as Obsolete and Unavailable.
rdar://23791325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261512 91177308-0d34-0410-b5e6-96231b3b80d8
Clang implements an enable_if attribute as an extension. Hook up `-Wpedantic`
to issue an extension usage warning when __enable_if__ is used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261192 91177308-0d34-0410-b5e6-96231b3b80d8
Alex Lorenz