| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
it affects only the return value, not any arguments. In turn, asking for a function or method result type should not require a function prototype either, so getFunctionOrMethodResultType has been relaxed.
llvm-svn: 212827
|
|
|
|
| |
llvm-svn: 212442
|
|
|
|
|
|
|
| |
Also document that the function is a "best-effort" facility to extract source
ranges from limited AST type location info.
llvm-svn: 212174
|
|
|
|
| |
llvm-svn: 211648
|
|
|
|
| |
llvm-svn: 211647
|
|
|
|
|
|
|
| |
property accessor methods which have become deprecated
or available. // rdar://15951801
llvm-svn: 211039
|
|
|
|
|
|
| |
patch. NFC.
llvm-svn: 210795
|
|
|
|
|
|
|
| |
for function/methods returning block in MRR mode as well.
// rdar://17259812
llvm-svn: 210706
|
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 209546
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 209217
|
|
|
|
|
|
|
|
|
| |
This is a GNU attribute that allows split stacks to be turned off on a
per-function basis.
Differential Revision: http://reviews.llvm.org/D3817
llvm-svn: 209167
|
|
|
|
|
|
| |
Patch by Pedro Ferreira!
llvm-svn: 209127
|
|
|
|
|
|
|
|
| |
This is a step towards handling these attributes on classes (PR11170).
Differential Revision: http://reviews.llvm.org/D3772
llvm-svn: 208925
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
|
|
| |
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3551
llvm-svn: 207734
|
|
|
|
|
|
| |
involving capabilities, the semantics for attributes now looks through the types of the constituent parts of a capability expression instead of at the aggregate expression type.
llvm-svn: 205629
|
|
|
|
|
|
| |
on a function.
llvm-svn: 205255
|
|
|
|
|
|
| |
as a structure declaration. This allows for C code to use Boolean expressions on a capability as part of another attribute. Eg) __attribute__((requires_capability(!SomeCapability)))
llvm-svn: 204657
|
|
|
|
|
|
|
|
| |
unlock_function attributes with the acquire_capability and release_capability attributes. The old spellings will continue to work, but the underlying semantic attributes have been replaced.
Downgraded the capability diagnostics from error to warning to match the desired behavior, and updated the existing test cases.
llvm-svn: 204350
|
|
|
|
|
|
| |
param_type_end() with iterator_range param_types(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204045
|
|
|
|
|
|
|
| |
initializers; but only those declared in class extensions
(not in implementations). // rdar://16305347
llvm-svn: 203954
|
|
|
|
|
|
| |
specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203474
|
|
|
|
|
|
| |
rdar://16264844
llvm-svn: 203372
|
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
|
|
| |
switch statement, so now there is only one style used in this block of code, instead of three or more styles.
No functional change intended.
llvm-svn: 203120
|
|
|
|
|
|
| |
inconsistent, making this hard to see.
llvm-svn: 203079
|
|
|
|
|
|
|
|
| |
is being annotated. There are currently only two supported names: mutex and role. Adding functionality to check for the capability name and diagnose when it's unexpected.
Note that for backwards compatibility, an unnamed capability will default to being a "mutex." This allows the deprecated lockable attribute to continue to function.
llvm-svn: 203012
|
|
|
|
|
|
|
| |
Upgrades the warning to an error and clarifies the message by treating the
definition as error instead of the attribute.
llvm-svn: 202300
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 202131
|
|
|
|
| |
llvm-svn: 201947
|
|
|
|
|
|
|
|
| |
that the optimizer does not duplicate code.
Patch thanks to Marcello Maggioni!
llvm-svn: 201941
|
|
|
|
|
|
| |
handleObjCSuppresProtocolAttr().
llvm-svn: 201922
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation' can only be applied to protocol definitions.
llvm-svn: 201899
|
|
|
|
|
|
|
|
| |
management: asserting a capability is held, acquiring a capability and releasing a capability. Also includes some skeleton documentation for these new attributes.
This functionality should be considered a WIP.
llvm-svn: 201890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality) and I have agreed to start migrating from lock-specific terminology to "capability"-specific terminology. This opens the door for future threading-related analysis passes so that a common nomenclature can be used.
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.
llvm-svn: 201585
|
|
|
|
|
|
|
|
| |
Allowing alignment past this point causes wrap around within clang.
N.B. GCC has the same restriction.
llvm-svn: 201254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 201162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 201105
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 200959
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 200423
|
|
|
|
|
|
|
|
| |
the diagnostic only when subsequent alignments are more strict than the alignment required by the first field.
Fixes PR15134
llvm-svn: 200277
|
|
|
|
|
|
|
|
| |
Follow up to r200082.
Spotted by Dmitri
llvm-svn: 200105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 200082
|
|
|
|
|
|
| |
Cleanup only.
llvm-svn: 199773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 199686
|
|
|
|
| |
llvm-svn: 199671
|
|
|
|
|
|
| |
are the same between the two attributes).
llvm-svn: 199666
|
|
|
|
|
|
| |
longer required -- we can just pass in the attribute directly.
llvm-svn: 199664
|