| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
weak reference.
Thanks to Jordan Rose and John McCall for their sage code review.
Fixes <rdar://problem/12569201>.
llvm-svn: 170864
|
|
|
|
|
|
|
|
| |
This is just a minor bit of refactoring, but it is nice cleanup for
the subsequent patch that adds warning support for assigning literals
to weak variables.
llvm-svn: 170863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
|
|
|
|
|
|
|
|
| |
literal."
Per code feedback, I want to see if there is a more general way to do this.
llvm-svn: 170777
|
|
|
|
|
|
|
|
|
| |
Such variables may immediately become nil or may have unpredictable
behavior.
Fixes <rdar://problem/12569201>.
llvm-svn: 170763
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
|
| |
category, when those properties will be implemented in category's
primary class or one of its super classes. // rdar://12568064
llvm-svn: 170573
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
| |
too). When instantiating a direct-initializer, if we find it has zero
arguments, produce an empty ParenListExpr rather than returning a null
expression.
llvm-svn: 170490
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy-list-initialization (and doesn't add an additional copy step):
Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it
when instantiating initializers in order to correctly handle instantiation of
copy-list-initialization. Teach TreeTransform that function arguments are
initializations, and so need this special treatment too. Finally, remove some
hacks which were working around SubstInitializer's shortcomings.
llvm-svn: 170489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
|
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
|
|
|
| |
llvm-svn: 170428
|
|
|
|
|
|
|
|
| |
This fixes the storage class of extern decls that are merged with file level
statics. The patch also fixes the linkage computation so that they are
considered internal.
llvm-svn: 170406
|
|
|
|
|
|
|
|
| |
(This change only affects ObjC.)
<rdar://problem/12857117>.
llvm-svn: 170402
|
|
|
|
|
|
| |
missing 'void', insert a fixit to add the void.
llvm-svn: 170399
|
|
|
|
| |
llvm-svn: 170297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the missing warning here:
struct S {
template <typename T>
void meth() {
char arr[3];
arr[4] = 0; // warning: array index 4 is past the end of the array
}
};
template <typename T>
void func() {
char arr[3];
arr[4] = 0; // no warning
}
llvm-svn: 170180
|
|
|
|
|
|
| |
Sema::ActOnStartOfFunctionDef is already doing.
llvm-svn: 170179
|
|
|
|
|
|
| |
and make sure additional uses don't get introduced. <rdar://problem/12858424>.
llvm-svn: 170081
|
|
|
|
|
|
| |
to (SEL). Fixes // rdar://12859590
llvm-svn: 170058
|
|
|
|
|
|
| |
<rdar://problem/12857416>.
llvm-svn: 170056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation
has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
|
|
|
|
|
|
|
|
|
|
| |
is switched of by about 0.8% (tested with int i<N>).
Additionally, this puts computing the diagnostic class into the hot
path more when parsing, in preparation for upcoming optimizations
in this area.
llvm-svn: 169976
|
|
|
|
|
|
| |
unavailable due to availability attributes. <rdar://problem/12798237>
llvm-svn: 169903
|
|
|
|
|
|
|
|
|
| |
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
|
|
|
|
|
|
| |
This fixes PR14339.
llvm-svn: 169705
|
|
|
|
|
|
|
|
|
|
| |
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
llvm-svn: 169690
|
|
|
|
|
|
| |
don't mark the function as invalid, since we suppress the error.
llvm-svn: 169689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
|
|
|
|
|
|
| |
flavour of special member.
llvm-svn: 169670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
|
|
|
|
| |
llvm-svn: 169664
|
|
|
|
|
|
|
|
| |
properly, rather than faking it up by pretending that a reference member makes
the default constructor non-trivial. That leads to rejects-valids when putting
such types inside unions.
llvm-svn: 169662
|
|
|
|
|
|
|
|
|
| |
with -Werror. Previously, compiling with -Werror would emit only the first
warning in a compilation unit, because clang assumes that once an error occurs,
further analysis is unlikely to return valid results. However, warnings that
have been upgraded to errors should not be treated as "errors" in this sense.
llvm-svn: 169649
|
|
|
|
|
|
| |
defaulted.
llvm-svn: 169574
|
|
|
|
|
|
| |
that was skipped by the parser.
llvm-svn: 169531
|
|
|
|
|
|
|
|
| |
function.
Fixes PR14518.
llvm-svn: 169510
|
|
|
|
|
|
|
|
|
|
|
| |
Don't require that, during template deduction, a template specialization type
as a function parameter has at least as many template arguments as one used in
a function argument (not even if the argument has been resolved to an exact
type); the additional parameters might be provided by default template
arguments in the template. We don't need this check, since we now implement
[temp.deduct.call]p4 with an additional check after deduction.
llvm-svn: 169475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.
(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)
This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.
<rdar://problem/11982013>
llvm-svn: 169400
|
|
|
|
|
|
|
| |
No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).
llvm-svn: 169399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.
There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.
In C++, the type of a character literal is 'char', and so this problem
doesn't exist.
<rdar://problem/12282316>
llvm-svn: 169398
|
|
|
|
|
|
|
| |
Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.
llvm-svn: 169374
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the analysis improves, it will continue to add new warnings that are
potentially disruptive to existing users. From now on, such warnings will
first be introduced under the "beta" flag. Such warnings are not turned on by
default; their purpose is to allow users to test their code against future
planned changes, before those changes are actually made. After a suitable
migration period, beta warnings will be folded into the standard
-Wthread-safety.
llvm-svn: 169338
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
| |
an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.
llvm-svn: 169075
|
|
|
|
|
|
| |
scope when dealing with nested blocks. Fixes <rdar://problem/12778708>.
llvm-svn: 169065
|
|
|
|
|
|
|
|
| |
with a signed fixed type.
<rdar://problem/12780159>.
llvm-svn: 169051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
|