- 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
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199378 91177308-0d34-0410-b5e6-96231b3b80d8
consumable objects. These are useful for implementing error codes that
must be checked. Patch also includes some significant refactoring, which was
necesary to implement the new behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199169 91177308-0d34-0410-b5e6-96231b3b80d8
Since this warning was generalized, it was also given a sensible warning group flag and the corresponding test was updated to reflect this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198053 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes <rdar://problem/15584219> and <rdar://problem/12241361>.
This change looks large, but all it does is reuse and consolidate
the delayed diagnostic logic for deprecation warnings with unavailability
warnings. By doing so, it showed various inconsistencies between the
diagnostics, which were close, but not consistent. It also revealed
some missing "note:"'s in the deprecated diagnostics that were showing
up in the unavailable diagnostics, etc.
This change also changes the wording of the core deprecation diagnostics.
Instead of saying "function has been explicitly marked deprecated"
we now saw "'X' has been been explicitly marked deprecated". It
turns out providing a bit more context is useful, and often we
got the actual term wrong or it was not very precise
(e.g., "function" instead of "destructor"). By just saying the name
of the thing that is deprecated/deleted/unavailable we define
this issue away. This diagnostic can likely be further wordsmithed
to be shorter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197627 91177308-0d34-0410-b5e6-96231b3b80d8
That's a mouthful, and not necessarily the final name. This also
reflects a semantic change where this attribute is now on the
protocol itself instead of a class. This attribute will require
that a protocol, when adopted by a class, is explicitly implemented
by the class itself (instead of walking the super class chain).
Note that this attribute is not "done". This should be considered
a WIP.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196955 91177308-0d34-0410-b5e6-96231b3b80d8
which specifies couple of (optional) method selectors
for bridging a CFobject to or from an ObjectiveC
object. This is wip. // rdsr://15499111
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196408 91177308-0d34-0410-b5e6-96231b3b80d8
designated initializers of an interface.
If the interface declaration does not have methods marked as designated
initializers then the interface inherits the designated initializers of
its super class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196315 91177308-0d34-0410-b5e6-96231b3b80d8
I have disabled some attribute subject lines on purpose in Attr.td;
this part is a WIP with the goal being to restore those subjects
incrementally. By commenting them out, it leaves the original behavior
the same as before for those attributes and so those are not
functionality changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195841 91177308-0d34-0410-b5e6-96231b3b80d8
look at the attribute spelling instead. The 'ownership_*' attributes should
probably be split into separate *Attr classes, but that's more than I wanted to
do here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195805 91177308-0d34-0410-b5e6-96231b3b80d8
This is still an experimental attribute, but I wanted it in tree
for review. It may still get yanked.
This attribute can only be applied to a class @interface, not
a class extension or category. It does not change the type
system rules for Objective-C, but rather the implementation checking
for Objective-C classes that explicitly conform to a protocol.
During protocol conformance checking, clang recursively searches
up the class hierarchy for the set of methods that compose
a protocol. This attribute will cause the compiler to not consider
the methods contributed by a super class, its categories, and those
from its ancestor classes. Thus this attribute is used to force
subclasses to redeclare (and hopefully re-implement) methods if
they decide to explicitly conform to a protocol where some of those
methods may be provided by a super class.
This attribute intentionally leaves out properties, which are associated
with state. This attribute only considers methods (at least right now)
that are non-property accessors. These represent methods that "do something"
as dictated by the protocol. This may be further refined, and this
should be considered a WIP until documentation gets written or this
gets removed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195533 91177308-0d34-0410-b5e6-96231b3b80d8
whose semantic is currently identical to objc_bridge,
but their differences may manifest down the road with
further enhancements. // rdar://15498044
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195376 91177308-0d34-0410-b5e6-96231b3b80d8
After implementing this patch, a few concerns about the language
feature itself emerged in my head that I had previously not considered.
I want to resolve those design concerns first before having
a half-designed language feature in the tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195328 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is to allow a class to stipulate that its methods (and those
of its parents) cannot be used for protocol conformance in a subclass.
A subclass is then explicitly required to re-implement those methods
of they are present in the class marked with this attribute.
Currently the attribute can only be applied to an @interface, and
not a category or class extension. This is by design. Unlike
protocol conformance, where a category can add explicit conformance
of a protocol to class, this anti-conformance really needs to be
observed uniformly by all clients of the class. That's because
the absence of the attribute implies more permissive checking of
protocol conformance.
This unfortunately required changing method lookup in ObjCInterfaceDecl
to take an optional protocol parameter. This should not slow down
method lookup in most cases, and is just used for protocol conformance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195323 91177308-0d34-0410-b5e6-96231b3b80d8
that teaches the compiler about a subset of toll-free
bridging semantics. This is wip. // rdar://15454846
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194633 91177308-0d34-0410-b5e6-96231b3b80d8
into a separate "parse an attribute that takes a type argument" codepath. This
results in both codepaths being a lot cleaner and simpler, and fixes some bugs
where the type argument handling bled into the expression argument handling and
caused us to both accept invalid and reject valid attribute arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193731 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r193161.
It broke
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
Looks like we have to fix pr17639 first :-(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193162 91177308-0d34-0410-b5e6-96231b3b80d8
names. For example, with this patch we now reject
void f1(void) __attribute__((alias("g1")));
This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193161 91177308-0d34-0410-b5e6-96231b3b80d8
ResolveSingleFunctionTemplateSpecialization() returns 0 and doesn't emit diags
unless the expression has template-ids, so we must null check the result.
Also add a better diag noting which overloads are causing the problem.
Reviewed by Aaron Ballman.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193055 91177308-0d34-0410-b5e6-96231b3b80d8
This attribute allows users to use a modified C or C++ function as an ARM
exception-handling function and, with care, to successfully return control to
user-space after the issue has been dealt with.
rdar://problem/14207019
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191769 91177308-0d34-0410-b5e6-96231b3b80d8
of ObjectiveC properties to mean annotation of
NS_RETURNS_INNER_POINTER on its synthesized getter.
This also facilitates more migration to properties when
methods are annotated with NS_RETURNS_INNER_POINTER.
// rdar://14990439
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191009 91177308-0d34-0410-b5e6-96231b3b80d8
Fix for PR16752. Second commit.
PR16752: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth methods. Methods asks target for proper type for given bit width.
2. Fix handleModeAttr according to new methods in TargetInfo.
Fixes:
1st Commit (Done): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Current): Fix SemaDeclAttr, handleModeAttr function.
Also test/Sema/attr-mode.c was fixed. 'XC' mode test was disabled for PPC64 machines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190926 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a couple of latent crashes for invalid attributes and also adds a
fixit hint to turn identifiers into string literals if one was expected. It then
proceeds recovery as if the identifier was a literal. Diagnostic locations are
also changed to point at the literal instead of the attribute if the error
concerns the argument. PR17175.
For example:
hidden.c:1:40: error: 'visibility' attribute requires a string
extern int x __attribute__((visibility(hidden)));
^
" "
hidden.c:2:29: error: visibility does not match previous declaration
extern int x __attribute__((visibility("default")));
^
hidden.c:1:29: note: previous attribute is here
extern int x __attribute__((visibility(hidden)));
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190699 91177308-0d34-0410-b5e6-96231b3b80d8
PR16752: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth methods. Methods asks target for proper type for given bit width.
2. Fix handleModeAttr according to new methods in TargetInfo.
Fixes:
1st Commit (Done): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Current): Fix SemaDeclAttr, handleModeAttr function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190391 91177308-0d34-0410-b5e6-96231b3b80d8
This information is used for return states and pass-by-value parameter
states.
Patch by Chris Wailes.
Review by DeLesley Hutchins and Aaron Ballman.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190116 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by chris.wailes@gmail.com
Functions can now declare what state the consumable type the are returning will
be in. This is then used on the caller side and checked on the callee side.
Constructors now use this attribute instead of the 'consumes' attribute.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189843 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by chris.wailes@gmail.com
Adds the 'consumable' attribute that can be attached to classes. This replaces
the previous method of scanning a class's methods to see if any of them have
consumed analysis attributes attached to them. If consumed analysis attributes
are attached to methods of a class that isn't marked 'consumable' a warning
is generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189702 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch we would warn and drop the attribute in
extern const char test3[] __attribute__((used)) = "";
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188588 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewed by delesley, dblaikie.
Add the annotations and code needed to support a basic 'consumed' analysis.
Summary:
This new analysis is based on academic literature on linear types. It tracks
the state of a value, either as unconsumed, consumed, or unknown. Methods are
then annotated as CallableWhenUnconsumed, and when an annotated method is
called while the value is in the 'consumed' state a warning is issued. A value
may be tested in the conditional statement of an if-statement; when this occurs
we know the state of the value in the different branches, and this information
is added to our analysis. The code is still highly experimental, and the names
of annotations or the algorithm may be subject to change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188206 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure we can properly generate code when the UUID has curly braces
on it, strip the curly braces at the sema layer.
This fixes PR16813.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188061 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith