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
An optional nopartial can be placed after the platform name.
int bar() __attribute__((availability(macosx,nopartial,introduced=10.12))
When deploying back to a platform version prior to when the declaration was
introduced, with 'nopartial', Clang emits an error specifying that the function
is not introduced yet; without 'nopartial', the behavior stays the same: the
declaration is `weakly linked`.
A member is added to the end of AttributeList to save the location of the
'nopartial' keyword. A bool member is added to AvailabilityAttr.
The diagnostics for 'nopartial' not-yet-introduced is handled in the same way as
we handle unavailable cases.
Reviewed by Doug Gregor and Jordan Rose.
rdar://23791325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261163 91177308-0d34-0410-b5e6-96231b3b80d8
Storing std::strings in attributes simply doesn't work, we never call
the destructor. Use an array of StringRefs instead of std::strings and
copy the data into memory taken from the ASTContext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260831 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by H.J. Lu
```
typedef unsigned int gcc_word __attribute__((mode(word)));
```
and
```
typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
```
define the largest unsigned integer types which can be stored in a
general purpose register, which may not be the pointer type. For x32,
they aren't pointer nor unsigned long. We should
1. Make getUnwindWordWidth and getRegisterWidth virtual,
2. Override them for x32, similar to hasInt128Type.
3. Use getRegisterWidth for __attribute__((mode(word)));
This fixes PR 24706.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D16779
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259383 91177308-0d34-0410-b5e6-96231b3b80d8
Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches
a point where the representation is required to be known. However,
*pointers* to member pointers may exist without knowing the pointee
type's representation. In these cases, we synthesize an opaque LLVM
type for the pointee type.
However, we can be in a situation where the underlying member pointer's
representation became known mid-way through the program. To account for
this, we attempted to manicure CodeGen's type-cache so that we can
replace the opaque member pointer type with the real deal while leaving
the pointer types unperturbed. This, unfortunately, is a problematic
approach to take as we will violate CodeGen's invariants.
These violations are mostly harmless but let's do the right thing
instead: invalidate the type-cache if a member pointer's LLVM
representation changes.
This fixes PR26313.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258839 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Warn for NVCC compatibility if you declare a static member function or
inline function as __global__.
Reviewers: tra
Subscribers: jhen, echristo, cfe-commits
Differential Revision: http://reviews.llvm.org/D16261
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258263 91177308-0d34-0410-b5e6-96231b3b80d8
Allow "mode" attribute to be applied to VarDecl, not ValueDecl (which includes FunctionDecl and EnumConstantDecl), emit an error if this attribute is used with function declarations and enum constants.
Differential Revision: http://reviews.llvm.org/D16112
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257868 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute may be attached to a function definition and instructs the backend to generate appropriate function entry/exit code so that
it can be used directly as an interrupt handler.
The IRET instruction, instead of the RET instruction, is used to return from interrupt or exception handlers. All registers, except for the EFLAGS register which is restored by the IRET instruction, are preserved by the compiler.
Any interruptible-without-stack-switch code must be compiled with -mno-red-zone since interrupt handlers can and will, because of the hardware design, touch
the red zone.
interrupt handler must be declared with a mandatory pointer argument:
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame) {
...
}
and user must properly define the structure the pointer pointing to.
exception handler:
The exception handler is very similar to the interrupt handler with a different mandatory function signature:
#ifdef __x86_64__
typedef unsigned long long int uword_t;
#else
typedef unsigned int uword_t;
#endif
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame, uword_t error_code) {
...
}
and compiler pops the error code off stack before the IRET instruction.
The exception handler should only be used for exceptions which push an error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
Differential Revision: http://reviews.llvm.org/D15709
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257867 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r254143 which introduces a crash on the following input:
f(char *);
g(char *);
#pragma weak f = g
int g(char *p) {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254605 91177308-0d34-0410-b5e6-96231b3b80d8
This CL is for discussion how to better fix bit-filed layout compatibility issue with GCC (see PR25575 for test case and more details). Current clang behavior is compatible with GCC 4.1-4.3 series but it was fixed in 4.4+. Ignoring packed attribute looks very odd and because it was also fixed in GCC 4.4+, it makes sense also fix it in clang.
Differential Revision: http://reviews.llvm.org/D14872
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254596 91177308-0d34-0410-b5e6-96231b3b80d8
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch adds support for the interrupt attribute for mips32r2+.
Patch by Simon Dardis.
Reviewers: dsanders, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D10802
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254205 91177308-0d34-0410-b5e6-96231b3b80d8
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252986 91177308-0d34-0410-b5e6-96231b3b80d8
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252648 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252369 91177308-0d34-0410-b5e6-96231b3b80d8
Fake arguments are automatically handled for serialization, cloning,
and other representational tasks, but aren't included in pretty-printing
or parsing (should we eventually ever automate that).
This is chiefly useful for attributes that can be written by the
user, but which are also frequently synthesized by the compiler,
and which we'd like to remember details of the synthesis for.
As a simple example, use this to narrow the cases in which we were
generating a specialized note for implicitly unavailable declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251469 91177308-0d34-0410-b5e6-96231b3b80d8
allow them to be written in certain kinds of user declaration and
diagnose on the use-site instead.
Also, improve and fix some diagnostics relating to __weak and
properties.
rdar://23228631
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251384 91177308-0d34-0410-b5e6-96231b3b80d8
When an Objective-C method implements a protocol requirement, do not
inherit any availability information from the protocol
requirement. Rather, check that the implementation is not less
available than the protocol requirement, as we do when overriding a
method that has availability. Fixes rdar://problem/22734745.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248949 91177308-0d34-0410-b5e6-96231b3b80d8
Don't use the spelling of the alignment attribute to determine whether
or not an alignment amount makes sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243233 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us pass functors (and lambdas) without void * tricks. On the
downside we can't pass CXXRecordDecl's Find* members (which are now type
safe) to lookupInBases directly, but a lambda trampoline is a small
price to pay. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243217 91177308-0d34-0410-b5e6-96231b3b80d8
Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work when using the
Itanium ABI, where the class layout for complex class hierarchies is
stored in the vtable. It might be possible to honor the novtable
attribute in some simple cases and either report an error or ignore
it in more complex situations, but it’s not clear if that would be
worthwhile. There is also value in having a simple and predictable
behavior, so this changes clang to simply ignore novtable when not using
the Microsoft C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242730 91177308-0d34-0410-b5e6-96231b3b80d8
The attribute '__declspec(noalias)' communicates that the function only
accesses memory pointed to by its pointer-typed arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242728 91177308-0d34-0410-b5e6-96231b3b80d8
can be different from the normal variable maximum.
Add an error diagnostic for when TLS variables exceed maximum TLS alignment.
Currenty only PS4 sets an explicit maximum TLS alignment.
Patch by Charles Li!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242198 91177308-0d34-0410-b5e6-96231b3b80d8
Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.
This feature can be tested for using __has_feature(cf_returns_on_parameters).
This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
refer to "property" instead of "method" in the error message.
rdar://problem/18742441
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240185 91177308-0d34-0410-b5e6-96231b3b80d8
Since we're ignoring the tune= and fpmath= attributes go ahead
and add a warning alerting people to the fact that we're going
to ignore that part of it during code generation and tie it to
the attribute warning set.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239583 91177308-0d34-0410-b5e6-96231b3b80d8
Modeled after the gcc attribute of the same name, this feature
allows source level annotations to correspond to backend code
generation. In llvm particular parlance, this allows the adding
of subtarget features and changing the cpu for a particular function
based on source level hints.
This has been added into the existing support for function level
attributes without particular verification for any target outside
of whether or not the backend will support the features/cpu given
(similar to section, etc).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239579 91177308-0d34-0410-b5e6-96231b3b80d8
- Changed CUDALaunchBounds arguments from integers to Expr* so they can
be saved in AST for instantiation.
- Added support for template instantiation of launch_bounds attrubute.
- Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo::
SetTargetAttributes() where it can be done after template instantiation.
- Added a warning on negative launch_bounds arguments.
- Amended test cases.
Differential Revision: http://reviews.llvm.org/D8985
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235452 91177308-0d34-0410-b5e6-96231b3b80d8
attribute to be placed on Objective-C pointer typedef
to make them strong enough so on their "new" method
family no attempt is made to override these
types. rdar://20255473
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235128 91177308-0d34-0410-b5e6-96231b3b80d8
A simple case of asserting isFunctionOrMethod when we should have
asserted isFunctionOrMethodOrBlock.
This fixes PR23117.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234297 91177308-0d34-0410-b5e6-96231b3b80d8
A dependent alignment attribute (like __attribute__((aligned(...))) or
__declspec(align(...))) on a non-dependent typedef or using declaration
poses a considerable challenge: the type is _not_ dependent, the size
_may_ be dependent if the type is used as an array type, the alignment
_is_ dependent.
It is reasonable for a compiler to be able to query the size and
alignment of a complete type. Let's help that become an invariant.
This fixes PR22042.
Differential Revision: http://reviews.llvm.org/D8693
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234280 91177308-0d34-0410-b5e6-96231b3b80d8
deterministically.
This fixes a latent issue where even Clang's Sema (and diagnostics) were
non-deterministic in the face of this pragma. The fix is super simple --
just use a MapVector so we track the order in which these are parsed (or
imported). Especially considering how rare they are, this seems like the
perfect tradeoff. I've also simplified the client code with judicious
use of auto and range based for loops.
I've added some pretty hilarious code to my stress test which now
survives the binary diff without issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233261 91177308-0d34-0410-b5e6-96231b3b80d8
This warns when using decls that are not available on all deployment targets.
For example, a call to
- (void)ppartialMethod __attribute__((availability(macosx,introduced=10.8)));
will warn if -mmacosx-version-min is set to less than 10.8.
To silence the warning, one has to explicitly redeclare the method like so:
@interface Whatever(MountainLionAPI)
- (void)ppartialMethod;
@end
This way, one cannot accidentally call a function that isn't available
everywhere. Having to add the redeclaration will hopefully remind the user
to add an explicit respondsToSelector: call as well.
Some projects build against old SDKs to get this effect, but building against
old SDKs suppresses some bug fixes -- see http://crbug.com/463171 for examples.
The hope is that SDK headers are annotated well enough with availability
attributes that new SDK + this warning offers the same amount of protection
as using an old SDK.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232750 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly short-circuits some conditionals. Adds target validation of
sections passed to these pragmas.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231317 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC doesn't warn on this. Users are expected to apply the WINAPI macro
to functions passed by pointer to the Win32 API, and this macro expands
to __stdcall. This means we end up with a lot of useless noisy warnings
about ignored calling conventions when compiling code with clang for
Win64.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230668 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new __freebsd_kprintf__ format string type, which enables
checking when used in __attribute__((format(...))) attributes. It can
check the FreeBSD kernel specific %b, %D, %r and %y specifiers, using
existing diagnostic messages. Also adds test cases for all these
specifiers.
Differential Revision: http://reviews.llvm.org/D7154
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229921 91177308-0d34-0410-b5e6-96231b3b80d8
Un-parameterize the warning as there is exactly one attribute added in C++14.
Partially addresses post-commit review comments from Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229636 91177308-0d34-0410-b5e6-96231b3b80d8
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229447 91177308-0d34-0410-b5e6-96231b3b80d8
__declspec(restrict) and __attribute(malloc) are both handled
identically by clang: they are allowed to the noalias LLVM attribute.
Seeing as how noalias models the C99 notion of 'restrict', rename the
internal clang attribute to Restrict from Malloc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228120 91177308-0d34-0410-b5e6-96231b3b80d8
It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual function tables.
This commit implements this feature in clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227796 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
Reviewers: jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7206
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227362 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type. Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'? It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226653 91177308-0d34-0410-b5e6-96231b3b80d8
Things that are OK:
extern int var1 __attribute((alias("v1")));
static int var2 __attribute((alias("v2")));
Things that are not OK:
int var3 __attribute((alias("v3")));
extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
struct S { static int var5 __attribute((alias("v5"))); };
This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
no reason to reject it.
This partially fixes PR22217.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226436 91177308-0d34-0410-b5e6-96231b3b80d8
conflicting attribute, warn about the conflict and pick a "winning"
attribute to preserve, instead of emitting an error. This matches the
behavior when the conflicting attributes are on different declarations.
Along the way I discovered that conflicts involving __forceinline were
reported as 'always_inline' (alternate spelling, same attribute) so
fixed that up to report the attribute as spelled in the source.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225813 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::handleAnnotateAttr expects that some basic validation is done on
the given AttributeList. However, ProcessAccessDeclAttributeList called
it directly. Instead, pass the list to ProcessDeclAttribute.
This fixes PR21847.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224204 91177308-0d34-0410-b5e6-96231b3b80d8
Eventually we'll diagnose them on different declarations, but let's
get this part out of the way first.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223985 91177308-0d34-0410-b5e6-96231b3b80d8
Placing the attribute after the kernel keyword would incorrectly
reject the attribute, so use the smae workaround that other
kernel only attributes use.
Also add a FIXME because there are two different phrasings now
for the same error, althoug amdgpu_num_[sv]gpr uses a consistent one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223490 91177308-0d34-0410-b5e6-96231b3b80d8
This is a performance hint that can be applied to kernels
to attempt to limit the number of used registers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223384 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute serves as a hint to improve warnings about the ranges of
enumerators used as flag types. It currently has no working C++ implementation
due to different semantics for enums in C++. For more explanation, see the docs
and testcases.
Reviewed by Aaron Ballman.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222906 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221154 91177308-0d34-0410-b5e6-96231b3b80d8
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220573 91177308-0d34-0410-b5e6-96231b3b80d8
Did a bit of drive-by reformatting as well since it required rearranging some other static functions in the file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219795 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the align_value attribute. This attribute is supported by
Intel's compiler (versions 14.0+), and several of my HPC users have requested
support in Clang. It specifies an alignment assumption on the values to which a
pointer points, and is used by numerical libraries to encourage efficient
generation of vector code.
Of course, we already have an aligned attribute that can specify enhanced
alignment for a type, so why is this additional attribute important? The
problem is that if you want to specify that an input array of T is, say,
64-byte aligned, you could try this:
typedef double aligned_double attribute((aligned(64)));
void foo(aligned_double *P) {
double x = P[0]; // This is fine.
double y = P[1]; // What alignment did those doubles have again?
}
the access here to P[1] causes problems. P was specified as a pointer to type
aligned_double, and any object of type aligned_double must be 64-byte aligned.
But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes
undefined behavior. Getting round this problem requires a lot of awkward
casting and hand-unrolling of loops, all of which is bad.
With the align_value attribute, we can accomplish what we'd like in a well
defined way:
typedef double *aligned_double_ptr attribute((align_value(64)));
void foo(aligned_double_ptr P) {
double x = P[0]; // This is fine.
double y = P[1]; // This is fine too.
}
This attribute does not create a new type (and so it not part of the type
system), and so will only "propagate" through templates, auto, etc. by
optimizer deduction after inlining. This seems consistent with Intel's
implementation (thanks to Alexey for confirming the various Intel-compiler
behaviors).
As a final note, I would have chosen to call this aligned_value, not
align_value, for better naming consistency with the aligned attribute, but I
think it would be more useful to users to adopt Intel's name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218910 91177308-0d34-0410-b5e6-96231b3b80d8
In addition to __builtin_assume_aligned, GCC also supports an assume_aligned
attribute which specifies the alignment (and optional offset) of a function's
return value. Here we implement support for the assume_aligned attribute by making
use of the @llvm.assume intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218500 91177308-0d34-0410-b5e6-96231b3b80d8
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217349 91177308-0d34-0410-b5e6-96231b3b80d8
the no-arguments case. Don't expand this to an __attribute__((nonnull(A, B,
C))) attribute, since that does the wrong thing for function templates and
varargs functions.
In passing, fix a grammar error in the diagnostic, a crash if
__attribute__((nonnull(N))) is applied to a varargs function,
a bug where the same null argument could be diagnosed multiple
times if there were multiple nonnull attributes referring to it,
and a bug where nonnull attributes would not be accumulated correctly
across redeclarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216520 91177308-0d34-0410-b5e6-96231b3b80d8
Updating the diagnostics in the launch_bounds test since they have been improved in that case. Adding a test for nonnull since it has little test coverage, but has truly variadic arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214407 91177308-0d34-0410-b5e6-96231b3b80d8
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213167 91177308-0d34-0410-b5e6-96231b3b80d8
Also document that the function is a "best-effort" facility to extract source
ranges from limited AST type location info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212174 91177308-0d34-0410-b5e6-96231b3b80d8
It's true the MSVC doesn't warn about dllimport when applied to e.g. a typedef,
but that applies to dllexport too. I'd like us to be consistent, and I think
the right thing to do is to warn.
The original test that came with implementing the old behaviour doesn't provide
a good motivation, and it said it was checking that we're not repoting an *error*,
which is still true since this is just a warning.
There are plenty of tests e.g. in Sema/dllimport.c to check that we do warn
about dllimport on non functions or variables.
Differential Revision: http://reviews.llvm.org/D3832
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209546 91177308-0d34-0410-b5e6-96231b3b80d8
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209217 91177308-0d34-0410-b5e6-96231b3b80d8
Downgraded the capability diagnostics from error to warning to match the desired behavior, and updated the existing test cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204350 91177308-0d34-0410-b5e6-96231b3b80d8
initializers; but only those declared in class extensions
(not in implementations). // rdar://16305347
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203954 91177308-0d34-0410-b5e6-96231b3b80d8
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203012 91177308-0d34-0410-b5e6-96231b3b80d8
Upgrades the warning to an error and clarifies the message by treating the
definition as error instead of the attribute.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202300 91177308-0d34-0410-b5e6-96231b3b80d8
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202131 91177308-0d34-0410-b5e6-96231b3b80d8
The following attributes have been (silently) deprecated, with their replacements listed:
lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability
There are no functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201585 91177308-0d34-0410-b5e6-96231b3b80d8
Allowing alignment past this point causes wrap around within clang.
N.B. GCC has the same restriction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201254 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to r199467, __attribute__((nonnull)) (without arguments) can apply
directly to parameters, instead of being applied to the whole function.
However, the old form of nonnull (with an argument index) could also apply
to the arguments of function and block pointers, and both of these can be
passed as parameters.
Now, if 'nonnull' with an argument is found on a parameter, /and/ the
parameter is a function or block pointer, it is handled the old way.
PR18795
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201162 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a notion of a 'current representation method' for
pointers-to-members.
When starting out, this is set to 'best case' (representation method is
chosen by examining the class, selecting the smallest representation
that would work given the class definition or lack thereof).
This pragma allows the translation unit to dictate exactly what
representation to use, similar to how the inheritance model keywords
operate.
N.B. PCH support is forthcoming.
Differential Revision: http://llvm-reviews.chandlerc.com/D2723
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201105 91177308-0d34-0410-b5e6-96231b3b80d8
If we are in the middle of defining the class, don't attempt to
validate previously annotated declarations. We may not have seen base
specifiers or virtual method declarations yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200959 91177308-0d34-0410-b5e6-96231b3b80d8
We would previously allow inappropriate inheritance keywords to appear
on class declarations. We would also allow inheritance keywords on
templates which were not fully specialized; this was divergent from
MSVC.
Differential Revision: http://llvm-reviews.chandlerc.com/D2585
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200423 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute is supported by GCC. More generally it should
probably be a type attribute, but this behavior matches 'nonnull'.
This patch does not include warning logic for checking if a null
value is returned from a function annotated with this attribute.
That will come in subsequent patches.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199626 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the following syntax:
void baz(__attribute__((nonnull)) const char *str);
instead of:
void baz(const char *str) __attribute__((nonnull(1)));
This also extends to Objective-C methods.
The checking logic in Sema is not as clean as I would like. Effectively
now we need to check both the FunctionDecl/ObjCMethodDecl and the parameters,
so the point of truth is spread in two places, but the logic isn't that
cumbersome.
Implements <rdar://problem/14691443>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199467 91177308-0d34-0410-b5e6-96231b3b80d8
Erik Pilkington