Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
This implementation doesn't warn on anything that GCC doesn't warn on with the
exception of templates specializations (GCC doesn't warn, Clang does). The
specific skipped cases (boolean, constant expressions, enums) are open for
debate/adjustment if anyone wants to demonstrate that GCC is being overly
conservative here. The only really obvious false positive I found was in the
Clang regression suite's MPI test - apparently MPI uses specific flag values in
pointer constants. (eg: #define FOO (void*)~0)
llvm-svn: 166039
-The front-end now builds a single assembly string and feeds it to the
AsmParser. The front-end iterates on a per statement basis by calling the
ParseStatement() function. Please note, the calling of ParseStatement() and
and any notion of MCAsmParsedOperands will be sunk into the MC layer in the
near future. I plan to expose more basic APIs such as getClobbers, etc.
-The enumeration of the AsmString expressions have been reworked to use SMLocs
rather than assembly Pieces, which were being parsed in the front-end.
-The test case, t8(), was modified due to r129223. I'll have to find a way to
work around things such as these.
Sorry for the large commit, but breaking this in multiple smaller commits proved
too irritating.
llvm-svn: 165957
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
This only applies if the type has a name. (we could potentially do something
crazy with decltype in C++11 to qualify members of unnamed types but that
seems excessive)
It might be nice to also suggest a fixit for "&this->i", "&foo->i",
and "&foo.i" but those expressions produce 'bound' member functions that have
a different AST representation & make error recovery a little trickier. Left
as future work.
llvm-svn: 165763
now unused static helper function.
The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.
llvm-svn: 165751
This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.
<rdar://problem/12437490>
llvm-svn: 165719
Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.
This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.
<rdar://problem/12407765>
llvm-svn: 165718
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
Old algorithm:
1. See if the name looks like a getter or setter.
2. Use the name to look up a property in the current ObjCContainer
and all its protocols.
3. If the current container is an interface, also look in all categories
and superclasses (and superclass categories, and so on).
New algorithm:
1. See if the method is marked as a property accessor. If so, look through
all properties in the current container and find one that has a matching
selector.
2. Find all overrides of the method using ObjCMethodDecl's
getOverriddenMethods. This collects methods in superclasses and protocols
(as well as superclass categories, which isn't really necessary), and
checks if THEY are accessors. This part is not done recursively, since
getOverriddenMethods is already recursive.
This lets us handle getters and setters that do not match the property
names.
llvm-svn: 165627
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
write out the macro history for that macro. Similarly, we need to cope
with reading a macro definition that has been #undef'd.
Take advantage of this new ability so that global code-completion
results can refer to #undef'd macros, rather than losing them
entirely. For multiply defined/#undef'd macros, we will still get the
wrong result, but it's better than getting no result.
llvm-svn: 165502
This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.
(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)
llvm-svn: 165283
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
For GNU attributes, instead of reusing attribute source
location for the scope location, use SourceLocation() since
GNU attributes don not have scope tokens.
llvm-svn: 165234
- General C++11 attributes were previously parsed and ignored. Now they are parsed and stored in AST.
- Add support to parse arguments of attributes that in 'gnu' namespace.
- Differentiate unknown attributes and known attributes that can't be applied to statements when emitting diagnostic.
llvm-svn: 165082
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
Also applies to -Wnonnull, -Wtype-safety, and -Wnon-pod-varargs.
All of these can be better checked at instantiation time.
This change does not actually affect regular CallExpr function calls,
since the checks there only happen after overload resolution.
However, it will affect Objective-C method calls.
<rdar://problem/12373934>
llvm-svn: 164984
-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.
llvm-svn: 164951
Summary:
When issuing a diagnostic message for the -Wimplicit-fallthrough diagnostics, always try to find the latest macro, defined at the point of fallthrough, which is immediately expanded to "[[clang::fallthrough]]", and use it's name instead of the actual sequence.
Known issues:
* uses PP.getSpelling() to compare macro definition with a string (anyone can suggest a convenient way to fill a token array, or maybe lex it in runtime?);
* this can be generalized and used in other similar cases, any ideas where it should reside then?
Reviewers: doug.gregor, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D50
llvm-svn: 164858
New output:
warning: weak property may be unpredictably set to nil
note: property declared here
note: assign the value to a strong variable to keep the object alive
during use
<rdar://problem/12277204>
llvm-svn: 164857
The infrastructure for -Warc-repeated-use-of-weak got a little too heavy
to leave sitting at the top of Sema.cpp.
No functionality change.
llvm-svn: 164856
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
llvm-svn: 164855
The motivating example:
if (self.weakProp)
use(self.weakProp);
As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:
id tmp = self.weakProp;
if (tmp)
use(tmp);
The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.
The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak
values.
Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.
The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.
Part of <rdar://problem/12280249>
llvm-svn: 164854
This checker is annotation driven. It checks that the annotated
invalidation method accesses all ivars of the enclosing objects that are
objects of type, which in turn contains an invalidation method.
This is driven by
__attribute((annotation("objc_instance_variable_invalidator")).
llvm-svn: 164716
where an attribute is attached to a forward declaration of a template function,
and refers to parameters of that declaration, but is then inherited by the
definition of that function. When the definition is instantiated, the
parameter references need to be remapped.
llvm-svn: 164710
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.
I would appreciate if someone would double-check that we get the mangling
correct with this patch.
llvm-svn: 164658
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
llvm-svn: 164656
If an MS-style inline asm is matched to multiple instructions, e.g., with a
a WAIT-prefix, then we need to examine the operands of the last instruction
instruction, not the prefix instruction.
llvm-svn: 164608
into the enclosing scope; this is a more accurate model but is
(I believe) unnecessary in my test case due to other flaws.
However, one of those flaws is now intentional: blocks which
appear in return statements can be trivially observed to not
extend in lifetime past the return, and so we can allow a jump
past them. Do the necessary magic in IR-generation to make
this work.
llvm-svn: 164589
function being instantiated. An error recovery codepath was recursively
performing name lookup (and triggering an unbounded stack of template
instantiations which blew out the stack before hitting the depth limit).
Patch by Wei Pan!
llvm-svn: 164586
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
but can be dereferenced to form an expression which does have viable begin/end
functions, then typo-correct the range, even if something else goes wrong with
the statement (such as inaccessible begin/end or the wrong type of loop
variable).
In order to ensure we recover correctly and produce any followup diagnostics in
this case, redo semantic analysis on the for-range statement outside of the
diagnostic trap, after issuing the typo-correction.
llvm-svn: 164323
This is some really old code (took me a while to find the test cases) & the
diagnostic text is slightly incorrect (it should really only apply to
re/declarations/, redefinitions are an error regardless of whether the types
match). Not sure if anyone cares about it, though.
For now this just makes the diagnostic more clear in less obvious cases where
the type of a declaration might not be explicitly written (eg: because it
uses decltype)
llvm-svn: 164313
definition info; it needs to be there because the mangler needs to
access it before we're finished defining the lambda class.
PR12808.
llvm-svn: 164186
This makes Clang warn about self references in in-class initializers,
for example:
struct S {
int a = a + 42;
};
This basically just moves UninitializedFieldVisitor up a bit in
SemaDeclCXX.cpp, and adds a call to it from ActOnCXXInClassMemberInitializer.
llvm-svn: 164131
is no compelling argument that this is a generally useful warning,
and imposes a strong stylistic argument on code beyond what it was
intended to find warnings in.
llvm-svn: 164083
Retain cycles happen in the case where a block is persisted past its
life on the stack, and the way that occurs is by copying the block.
We should thus look through any explicit copies we see.
Note that Block_copy is actually a type-safe wrapper for _Block_copy,
which does all the real work.
<rdar://problem/12219663>
llvm-svn: 164039
Specifically, this should warn:
__block block_t a = ^{ a(); };
Furthermore, this case which previously warned now does not, since the value
of 'b' is captured before the assignment occurs:
block_t b; // not __block
b = ^{ b(); };
(This will of course warn under -Wuninitialized, as before.)
<rdar://problem/11015883>
llvm-svn: 163962
type checking for non-static data member initializers in a dependent
class, because our ASTs lose too much information to when
type-checking an initializer. Fixes <rdar://problem/11974632>,
although the result is still rather unsatisfactory.
llvm-svn: 163871
TypeSourceInfo, we may have lost some adjustments made to the type of
that function due to declaration merging. Adjust the resulting type
correspondingly. Fixes PR12948 / <rdar://problem/11552434>.
llvm-svn: 163845
integral promotions to both its underlying type and to its underlying type's
promoted type. This matters now that boolean conversions aren't permitted in
converted constant expressions (a la DR1407): an enumerator with a fixed
underlying type of bool still can be.
llvm-svn: 163841
warning to an error. C++ bans it, and both GCC and EDG diagnose it as
an error. Microsoft allows it, so we still warn in Microsoft
mode. Fixes <rdar://problem/11135644>.
llvm-svn: 163831
passing -fretain-comments-from-system-headers. By default, the
compiler no longer parses such documentation comments, as they
can result in a noticeable compile time/PCH slowdown.
Fixes <rdar://problem/11860820>.
llvm-svn: 163778
more robust way to address a few FIXMEs.
The initial implementation, r163342, built the IR asm string and then tried to
patch things on the fly without enough context. Specifically, it didn't skip
mnemonics nor did it track with assembly instruction an expression was related
to. The new implementation patches the operands and then builds the final
IR string.
llvm-svn: 163756
MCOperands then iterate over all of then when computing clobbers, inputs and
outputs.
On x86 the 1-to-many mapping is a memory operand that includes a BaseReg(reg),
MemScale(imm), MemIndexReg(reg), an Expr(MCExpr or imm) and a MemSegReg(reg).
Invalid register (Op.getReg() == 0) are not considered when computing clobber.
llvm-svn: 163728
A couple of missing "RequireNonAbstractType" calls in conditional operator
handling. I looked for opportunities to tie this check in to all relevant
callers of PerformCopyInitialization (couldn't be all callers since this is
called for base subobject copying too, where it's acceptable to copy abstract
types) but the callers varied too much & in many cases had substantial code
or conditionals on the RequireNonAbstractType call, the
PerformCopyInitialization call, or the code between the two calls.
llvm-svn: 163555
analysis that may give false positives because it is confused by aliasing, and
a less precise analysis that has fewer false positives, but may have false
negatives. The more precise warnings are enabled by -Wthread-safety-precise.
An additional note clarify the warnings in the precise case.
llvm-svn: 163537
in classes. Use it to flag those method implementations which don't
contain call to 'super' if they have 'super' class and it has the method
with this attribute set. This is wip. // rdar://6386358
llvm-svn: 163434
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
llvm-svn: 163369
These types are defined differently on 32-bit and 64-bit platforms, and
trying to offer a fixit for one platform would only mess up the format
string for the other. The Apple-recommended solution is to cast to a type
that is known to be large enough and always use that to print the value.
This should only have an impact on compile time if the format string is
incorrect; in cases where the format string matches the definition on the
current platform, no warning will be emitted.
<rdar://problem/9135072&12164284>
llvm-svn: 163266
of a c-function for what it is. Otherwise, this func
is treated as an overloadable c-function resulting in
a crash much later. // rdar://11743706
llvm-svn: 163224
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
initiated enum constant has the same value as another enum constant.
For instance:
enum test { A, B, C = -1, D, E = 1 };
Clang will warn that:
A and D both have value 0
B and E both have value 1
A few exceptions are made to keep the noise down. Enum constants which are
initialized to another enum constant, or an enum constant plus or minus 1 will
not trigger this warning. Also, anonymous enums are not checked.
llvm-svn: 162938
__objc_yes/__objc_no to (BOOL)1/(BOOL)0 when
BOOL is declared; otherwise it resorts to
default of 'signed char'. This is important to
selecting the correct Numeric API numberWithBool:
Can't have a clang test for this. Will checkin and
executable llvm test. // rdar://12156616
llvm-svn: 162922
Summary:
Summary: Keep history of macro definitions and #undefs with corresponding source locations, so that we can later find out all macros active in a specified source location. We don't save the history in PCH (no need currently). Memory overhead is about sizeof(void*)*3*<number of macro definitions and #undefs>+<in-memory size of all #undef'd macros>
I've run a test on a file composed of 109 .h files from boost 1.49 on x86-64 linux.
Stats before this patch:
*** Preprocessor Stats:
73222 directives found:
19171 #define.
4345 #undef.
#include/#include_next/#import:
5233 source files entered.
27 max include stack depth
19210 #if/#ifndef/#ifdef.
2384 #else/#elif.
6891 #endif.
408 #pragma.
14466 #if/#ifndef#ifdef regions skipped
80023/451669/1270 obj/fn/builtin macros expanded, 85724 on the fast path.
127145 token paste (##) operations performed, 11008 on the fast path.
Preprocessor Memory: 5874615B total
BumpPtr: 4399104
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
Stats with this patch:
...
Preprocessor Memory: 7541687B total
BumpPtr: 6066176
Macro Expanded Tokens: 417768
Predefines Buffer: 8135
Macros: 1048576
#pragma push_macro Info: 0
Poison Reasons: 1024
Comment Handlers: 8
In my test increase in memory usage is about 1.7Mb, which is ~28% of initial preprocessor's memory usage and about 0.8% of clang's total VMM allocation.
As for CPU overhead, it should only be noticeable when iterating over all macros, and should mostly consist of couple extra dereferences and one comparison per macro + skipping of #undef'd macros. It's less trivial to measure, though, as the preprocessor consumes a very small fraction of compilation time.
Reviewers: doug.gregor, klimek, rsmith, djasper
Reviewed By: doug.gregor
CC: cfe-commits, chandlerc
Differential Revision: http://llvm-reviews.chandlerc.com/D28
llvm-svn: 162810
and when used in property type declaration, is handled as type
attribute. Do not issue the warning when declaraing the property.
// rdar://12173491
llvm-svn: 162801
variables without a storage class within a function, to implement
CUDA B.2.5: "__shared__ and __constant__ variables have implied static
storage [duration]."
llvm-svn: 162788
This warns in two specific situations:
1) For potentially swapped function arguments, e.g.
void foo(bool, float);
foo(1.7, false);
2) Misplaced brackets around function call arguments, e.g.
bool InRange = fabs(a - b < delta);
Where the last argument in a function call is implicitly converted
from bool to float, and the function returns a float which gets
implicitly converted to bool.
Patch by Andreas Eckleder!
llvm-svn: 162763
make sure we walk up the DC chain for the current context,
rather than allowing ourselves to get switched over to the
canonical DC chain. Fixes PR13642.
llvm-svn: 162616
CodeGen option to a LangOpt option. In turn, hoist the guard into the parser
so that we avoid the new (and fairly unstable) Sema/AST/CodeGen logic. This
should restore the behavior of clang to that prior to r158325.
<rdar://problem/12163681>
llvm-svn: 162602
Add a new static function, buildMSAsmPieces, that will break these strings down
into mnemonic and operands. Upon a match failure, the idea is to use the
ErrorInfo from MatchInstructionImpl to inspect the mnemonic/operand and
decide a course of action. Unfortunately, there's no easy way to test this at
the moment.
llvm-svn: 162321
class extensions a little. clang now allows readonly property
with no ownership rule (assign, unsafe_unretained, weak, retain,
strong, or copy) with a readwrite property with an ownership rule.
// rdar://12103400
llvm-svn: 162319
diagnostics for bad deployment targets and adding a few
more predicates. Includes a patch by Jonathan Schleifer
to enable ARC for ObjFW.
llvm-svn: 162252
The old error message stating that 'begin' was an undeclared identifier
is replaced with a new message explaining that the error is in the range
expression, along with which of the begin() and end() functions was
problematic if relevant.
Additionally, if the range was a pointer type or defines operator*,
attempt to dereference the range, and offer a FixIt if the modified range
works.
llvm-svn: 162248
First, when synthesizing an explicitly strong/retain/copy property
of Class type, don't pretend during compatibility checking that the
property is actually assign. Instead, resolve incompatibilities
by secretly changing the type of *implicitly* __unsafe_unretained
Class ivars to be strong. This is moderately evil but better than
what we were doing.
Second, when synthesizing the setter for a strong property of
non-retainable type, be sure to use objc_setProperty. This is
possible when the property is decorated with the NSObject
attribute. This is an ugly, ugly corner of the language, and
we probably ought to deprecate it.
The first is rdar://problem/12039404; the second was noticed by
inspection while fixing the first.
llvm-svn: 162244
Also, suggest 'readonly' even if the property has been given an ownership
attribute ('strong', 'weak', etc). This is used when properties are declared
readonly in the public interface but readwrite in a class extension.
<rdar://problem/11500004&11932285>
llvm-svn: 162220
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).
This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.
llvm-svn: 162159
specifier is unsed in a declaration; as it may not make the symbol
local to linkage unit as intended. Suggest using "hidden" visibility
attribute instead. // rdar://7703982
llvm-svn: 162138
both a waste of time, and prone to crash due to the use of the
error-recovery path in parser. Fixes <rdar://problem/12103608>, which
has been driving me nuts.
llvm-svn: 162081
elaborated type specifier in template instantiation: such a specifier is always
valid because it must be specified within the definition of the type.
llvm-svn: 162068
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
These require special handling, which we don't currently handle. This is being
put in place to ensure we don't do invalid symbol table lookups or try to parse
invalid assembly. The test cases just makes sure the latter isn't happening.
llvm-svn: 162050
variables, function or label references. The former is a potential clobber.
The latter is either an input or an output. Unfortunately, it's difficult to
test this patch at the moment, but the added test case will eventually do so.
llvm-svn: 162026
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
statement. For example,
if (x)
__asm out dx, ax __asm out dx, ax
results in a single inline asm statement (i.e., both "out dx, ax" statements are
predicated on if(x)).
llvm-svn: 161986
as it does something unexpected (but gcc compatible).
Suggest use of __attribute__((visibility("hidden")))
on declaration instead. // rdar://7703982
llvm-svn: 161972
The reason for the recent fallout for "attaching comments to any redeclaration"
change are two false assumptions:
(1) a RawComment is attached to a single decl (not true for 'typedef struct X *Y'
where we want the comment to be attached to both X and Y);
(2) the whole redeclaration chain has only a single comment (obviously false, the
user can put a separate comment for each redeclaration).
To fix (1) I revert the part of the recent change where a 'Decl*' member was
introduced to RawComment. Now ASTContext has a separate DenseMap for mapping
'Decl*' to 'FullComment*'.
To fix (2) I just removed the test with this assumption. We might not parse
every comment in redecl chain if we already parsed at least one.
llvm-svn: 161878
tablegen code, found by -fcatch-undefined-behavior. I would appreciate if
someone more familiar with the NEON code could point me in the direction of how
to write a test for this. We appear to have essentially no test coverage
whatsoever for these builtins.
llvm-svn: 161827
The AsmParser expects a single asm instruction, but valid ms-style inline asm
statements may contain multiple instructions.
This happens with asm blocks
__asm {
mov ebx, eax
mov ecx, ebx
}
or when multiple asm statements are adjacent to one another
__asm mov ebx, eax
__asm mov ecx, ebx
and
__asm mov ebx, eax __asm mov ecx, ebx
Currently, asm blocks are not properly handled.
llvm-svn: 161780
Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.
llvm-svn: 161722
things going on here that were problematic:
- We were missing the actual access check, or rather, it was suppressed
on account of being a redeclaration lookup.
- The access check would naturally happen during delay, which isn't
appropriate in this case.
- We weren't actually emitting dependent diagnostics associated with
class templates, which was unfortunate.
- Access was being propagated incorrectly for friend method declarations
that couldn't be matched at parse-time.
llvm-svn: 161652
This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce
the implementation with other callers (& update those other callers).
Patch contributed by Sam Panzer (panzer@google.com).
llvm-svn: 161647
We handled the builtin version of this function in r157968, but the builtin
isn't used when compiling as -fno-constant-cfstrings.
This should complete <rdar://problem/6157200>.
llvm-svn: 161525
are not definitions. This follows the behavior of both gcc and earlier
versions of clang. Regression from r156531. <rdar://problem/12048621>.
llvm-svn: 161523
asm statements are those that don't reference variable names, function names,
and labels.
Add logic to generate a patched AsmString that will eventually be consumed by
the AsmParser. No functional change at this point, so unfortunately no test
case.
llvm-svn: 161508
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
A conditional operator between glvalues of types cv1 T and cv2 T produces a
glvalue if the expressions are of the same value kind and one of cv1 and cv2
is a subset of the other.
A conditional operator between two null pointer constants is permitted if one
of them is of type std::nullptr_t.
llvm-svn: 161476
and the other is a glvalue of class type, don't forget to copy-initialize a
temporary when performing the lvalue-to-rvalue conversion on the glvalue.
Strangely, DefaultLvalueConversions misses this part of the lvalue-to-rvalue
conversions.
llvm-svn: 161450
for side-effects. Instead, check for side-effects after performing
initialization. Doing so also removes some strange corner cases and differences
between in-class initialization and constructor initialization.
llvm-svn: 161449
This is useful for example for %n in printf, which expects
a pointer to int with the same logic for checking as %d
would have in scanf.
llvm-svn: 161407
The one caller that's surrounded by nearby code manipulating the underlying
evaluation context list is left unmodified for readability.
Review by Sean Silva and Richard Smith.
llvm-svn: 161355
in duplicate -Wuninitialized warnings. Change so that only the check in
TryConstructorInitialization() will be used and a single warning be emitted.
llvm-svn: 161345
we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.
llvm-svn: 161316
The only caveat is renumbering CXCommentKind enum for aesthetic reasons -- this
breaks libclang binary compatibility, but should not be a problem since API is
so new.
This also fixes PR13372 as a side-effect.
llvm-svn: 161087
on object pointers and whether pointer arithmetic on object pointers
is supported. Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.
llvm-svn: 161028
type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.
Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.
llvm-svn: 161020
sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.
llvm-svn: 161008
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
llvm-svn: 160998
type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838
llvm-svn: 160993
While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.
llvm-svn: 160984
expressions to have complete return types (or accessible destructors). If the
return type is required to be complete for some other reason (for instance, if
it is needed by overload resolution), then it will still be required to be
complete. This is apparently required in order to parse a MSVC11 header.
llvm-svn: 160924
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.
llvm-svn: 160705
A warning was added in r150128 for returning non-C compatible
user-defined types from functions with C linkage.
This makes the text more clear for the case when the type isn't
decidedly non-C compatible, but incomplete.
llvm-svn: 160681
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
llvm-svn: 160659
Make handler functions for thread safety attributes consistent with other attributes handler functions
by removing the bool parameter from some of the thread safety attributes handler functions and extracting
common checks out of different handler functions.
llvm-svn: 160635
structor class under ARC, that struct/class does not have a trivial
move constructor or move assignment operator. Fixes the rest of
<rdar://problem/11738725>.
llvm-svn: 160615
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
llvm-svn: 160614
While we still want to consider this a hard error (non-POD variadic args are
normally a DefaultError warning), delaying the diagnostic allows us to give
better error messages, which also match the usual non-POD errors more closely.
In addition, this change improves the diagnostic messages for format string
argument type mismatches by passing down the type of the callee, so we can
say "variadic method" or "variadic function" appropriately.
<rdar://problem/11825593>
llvm-svn: 160517
Previously, we would ask for the SourceLocation of an argument even if
it were NULL (i.e. if Sema resulted in an ExprError trying to build it).
<rdar://problem/11890818>
llvm-svn: 160515
Panzer. I've not been able to trigger a failure caused by this, so no test yet.
Also included is a small change from Paul Robinson to only consider the
FailureKind if the overload candidate did actually fail.
llvm-svn: 160470
be defined as deleted, take cv-qualifiers on class members into account when
looking up the copy or move constructor or assignment operator which will be
used for them.
llvm-svn: 160418
and a function template instantiation, if there's a parameter pack in the
declaration and one at the same place in the instantiation, don't assume that
the pack wasn't expanded -- it may have expanded to nothing. Instead, go ahead
and check whether the parameter pack was expandable. We can do this as a
side-effect of the work we'd need to do anyway, to find how many parameters
were produced.
llvm-svn: 160416
[temp.deduct.call]p4 under Objective-C++ ARC, make sure to adjust the
qualifiers to introduce the implicit strong lifetime when
needed. Fixes <rdar://problem/11825671>.
llvm-svn: 160412
Checks against nil often appear as guards in macros, and comparing
Objective-C literals to nil has well-defined behavior (if tautological).
On OS X, 'nil' has not been typed as 'id' since 10.6 (possibly earlier),
so the warning was already not firing, but other runtimes continue to use
((id)0) or some variant. This change accepts comparisons to any null pointer;
to keep it simple, it looks through all casts (not just casts to 'id').
PR13276
llvm-svn: 160379
Suggested by Ted, since string literal comparison is at least slightly more
sensible than comparison of runtime literals. (Ambiguous language on
developer.apple.com implies that strings are guaranteed to be uniqued within
a translation unit and possibly across a linked binary.)
llvm-svn: 160378
Recovering as if the user had actually called -isEqual: is a bit too far from
the semantics of the program as written, /even though/ it's probably what they
intended.
llvm-svn: 160377
* Treat compound assignment as a use, at Jordy's request.
* Always add compound assignments into the CFG, so we can correctly diagnose the use in 'return x += 1;'
llvm-svn: 160334
as an array of its base class TemplateArgument. Switch the const
TemplateArgument* parameters of InstantiatingTemplate's constructors to
ArrayRef<TemplateArgument> to prevent this from happening again in the future.
llvm-svn: 160245
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("hidden"))) zed;
Which is a bit silly and got a lot noisier now that we correctly handle
visibility pragmas. This patch fixes that and also has some extra quality
improvements:
* We now produce an error instead of a warning for
struct __attribute__((visibility("hidden"))) zed {
};
struct __attribute__((visibility("default"))) zed;
* The "after definition" warning now points to the new attribute that is
ignored instead of pointing to the declaration.
llvm-svn: 160227
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.
llvm-svn: 160161
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
llvm-svn: 160078
Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.
Revert the release notes change (r159766) now that this is just a new warning.
llvm-svn: 159939
* When substituting a reference to a non-type template parameter pack where the
corresponding argument is a pack expansion, transform into an expression
which contains an unexpanded parameter pack rather than into an expression
which contains a pack expansion. This causes the SubstNonTypeTemplateParmExpr
to be inside the PackExpansionExpr, rather than outside, so the expression
still looks like a pack expansion and can be deduced.
* Teach MarkUsedTemplateParameters that we can deduce a reference to a template
parameter if it's wrapped in a SubstNonTypeTemplateParmExpr (such nodes are
added during alias template substitution).
llvm-svn: 159922
expression, skip over any SubstNonTypeTemplateParmExprs which alias templates
may have inserted before checking for a DeclRefExpr referring to a non-type
template parameter declaration.
llvm-svn: 159909
-ftemplate-depth limit. There are various ways to get an infinite (or merely
huge) stack of substitutions with no intervening instantiations. This is also
consistent with gcc's behavior.
llvm-svn: 159907
which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.
llvm-svn: 159895
very simple semantic analysis that just builds the AST; minor changes for lexer
to pick up source locations I didn't think about before.
Comments AST is modelled along the ideas of HTML AST: block and inline content.
* Block content is a paragraph or a command that has a paragraph as an argument
or verbatim command.
* Inline content is placed within some block. Inline content includes plain
text, inline commands and HTML as tag soup.
llvm-svn: 159790
actually perform value initialization rather than trying to fake it with a call
to the default constructor. Fixes various bugs related to the previously-missing
zero-initialization in this case.
I've also moved this and the other list initialization 'special case' from
TryConstructorInitialization into TryListInitialization where they belong.
llvm-svn: 159733
This required moving the ctors for IntegerLiteral and FloatingLiteral out of
line which shouldn't change anything as they are usually called through Create
methods that are already out of line.
ASTContext::Deallocate has been a nop for a long time, drop it from ASTVector
and make it independent from ASTContext.h
Pass the StorageAllocator directly to AccessedEntity so it doesn't need to
have a definition of ASTContext around.
llvm-svn: 159718
initializer.
I really feel like Clang should warn about this, but I can't describe
a good reason. GCC will warn on this in some cases under
-Wsequence-point, but it actually seems like a false positive for that
warning....
llvm-svn: 159631
c-functions declared in implementation should have their
parsing delayed until the end so, they can access forward
declared private methods. // rdar://10387088
llvm-svn: 159626
In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.
In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.
Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.
<rdar://problem/11662489> (again)
llvm-svn: 159591
template instantiation. I wasn't able to reproduce this down to
anything small enough to put in our test suite, but it's "obviously"
okay to set the invalid bit earlier and precludes a
known-broken-but-not-marked-broken class from being used elsewhere.
llvm-svn: 159584
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
llvm-svn: 159539
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
type traits that assignment to/construction of a lifetime-qualified
object under ARC is *not* trivial. Fixes <rdar://problem/11738725>.
llvm-svn: 159401
to see if we had an underlying final class or method, but we would then
use the cast type to do the call, resulting in a direct call to the wrong
method.
llvm-svn: 159212
This works around a quirk in the way that explicit template specializations are
handled in Clang. We generate an implicit declaration from the original
template which the explicit specialization is considered to redeclare. This
trips up the explicit delete logic.
This change only works around that strange representation. At some point it'd
be nice to remove those extra declarations to make the AST more accurately
reflect the C++ semantics.
Review by Doug Gregor.
llvm-svn: 159167
resulted in it being reverted. A test for that bug was added in r158950.
Original comment:
If an object (such as a std::string) with an appropriate c_str() member function
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 159159
This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:
__thread int x __attribute__((tls_model("initial-exec")));
if it will not be used in a shared library that is dlopen'ed.
This depends on LLVM r159077.
llvm-svn: 159078
Heavily based on a patch from
Aaron Wishnick <aaron.s.wishnick@gmail.com>.
I'll clean up the duplicated function in CodeGen as
a follow-up, later today or tomorrow.
llvm-svn: 159060
* Primarily fixed \param commands with names not matching any actual
parameters of the documented functions. In many cases this consists
just of fixing up the parameter name in the \param to match the code,
in some it means deleting obsolete documentation and occasionally it
means documenting the parameter that has replaced the older one that
was documented, which sometimes means some simple reverse-engineering
of the docs from the implementation;
* Fixed \param ParamName [out] to the correct format with [out] before
the parameter name;
* Fixed some \brief summaries.
llvm-svn: 158980
Revert "If an object (such as a std::string) with an appropriate c_str() member function"
This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.
llvm-svn: 158949
This now correctly covers, I believe, all the pointer types:
* 'any' pointers (both function and data normal pointers and ObjC object pointers)
* member pointers (both function and data)
* block pointers
llvm-svn: 158931
In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) This leads to
odd warnings when returning enum constants directly in blocks with inferred
return types. The easiest way out of this is to pretend that, like C++, enum
constants have enum type when being returned from a block.
<rdar://problem/11662489>
llvm-svn: 158899
Also, don't warn if the used function is __attribute__((const)), in which case
it's not supposed to use global variables anyway.
The inline-in-inline thing is a heuristic, and one that's possibly incorrect
fairly often because the function being inlined could definitely use global
variables. However, even some C standard library functions are written using
other (trivial) static-inline functions in the headers, and we definitely don't
want to be warning on that (or on anything that /uses/ these trivial inline
functions). So we're using "inlined" as a marker for "fairly trivial".
(Note that __attribute__((pure)) does /not/ guarantee safety like ((const),
because ((const)) does not guarantee that global variables are not being used,
and the warning is about globals not being shared across TUs.)
llvm-svn: 158898
express library-level dependencies within Clang.
This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.
llvm-svn: 158888
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 158887
"write" attribute (copy/retain/etc.). But, property declaration in
primary class and protcols are tentative as they may be overridden
into a 'readwrite' property in class extensions. Postpone diagnosing
such warnings until the class implementation is seen.
// rdar://11656982
llvm-svn: 158869
in microsoft mode. Fixes PR12701.
The code for this was already in 2 of the 3 branches of a
conditional and missing in the 3rd branch, so lift it above
the conditional.
llvm-svn: 158842
It's very easy for anonymous external linkage to propagate in C++ through
return types and parameter types. Likewise, it's possible that a template
containing an inline function is only used with parameters that have internal
linkage. Actually diagnosing where the internal linkage comes from is fairly
difficult (both to locate and then to print nicely). Finally, since we only
have one translation unit available, we can't even prove that any of this
violates the ODR.
This warning needs better-defined behavior in C++ before it can really go in.
Rewording of the C warning (which /is/ specified by C99) coming shortly.
llvm-svn: 158836
error was asserting on anything that included Windows.h. MS-style inline asm is
still dropped, but at least now we're not completely silent about it.
llvm-svn: 158833
That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.
However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.
It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?
Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.
llvm-svn: 158807
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
llvm-svn: 158771
Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.
llvm-svn: 158759
name as an existing ivar since this is common source of error
when people remove @synthesize to take advantage of autosynthesis.
// rdar://11671080
llvm-svn: 158756
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
Note that this is mostly a structural patch that handles the change from the old
spelling style to the new one. One consequence of this is that all AT_foo_bar
enum values have changed to not be based off of the first spelling, but rather
off of the class name, so they are now AT_FooBar and the like (a straw poll on
IRC showed support for this). Apologies for code churn.
Most attributes have GNU spellings as a temporary solution until everything else
is sorted out (such as a Keyword spelling, which I intend to add if someone else
doesn't beat me to it). This is definitely a WIP.
I've also killed BaseCheckAttr since it was unused, and I had to go through
every attribute anyway.
llvm-svn: 158700
because it expects a reference and receives a non-l-value.
For example, given:
int foo(int &);
template<int x> void b() { foo(x); }
clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment #5 in PR3104, and should be the last bit of work needed for the
bug.
llvm-svn: 158691
Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).
This removes the warning entirely from uses in the main source file in C++.
llvm-svn: 158689
This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.
llvm-svn: 158683
This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)
I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.
llvm-svn: 158666
Now, as long as the 'Namespaces' variable is correct inside Attr.td, the
generated code will correctly admit a C++11 attribute only when it has the
appropriate namespace(s).
llvm-svn: 158661
David Blaikie