| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 172684
|
|
|
|
| |
llvm-svn: 172678
|
|
|
|
|
|
|
|
| |
This fixes pr14946. The problem was that the linkage computation was done too
early, so things like "extern int a;" would be given external linkage, even if
a previous declaration was static.
llvm-svn: 172667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
llvm-svn: 172665
|
|
|
|
|
|
|
|
| |
overriding and overridden method, allow the overridden method to have
a narrower contract (introduced earlier, deprecated/obsoleted later)
than the overriding method. Fixes <rdar://problem/12992023>.
llvm-svn: 172567
|
|
|
|
|
|
|
|
| |
ActOnFinishFullExpr that some of its checks only apply to discarded-value
expressions. This adds missing checks for unexpanded variadic template
parameter packs to a handful of constructs.
llvm-svn: 172485
|
|
|
|
|
|
| |
we know whether it is static.
llvm-svn: 172376
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The testcase in pr14929 shows that this is extremely hard to do. If we choose
to apply the attribute, that causes the visibility of some decls to change and
that can happen really late (during codegen).
Current gcc warns and ignores the attribute in this testcase with a warning.
This suggest that the correct solution is to find a point in the compilation
where we can compute the visibility and
* assert it was never computed before
* reject any attempts to compute it again in the future (with warnings).
llvm-svn: 172305
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which a particular declaration resides. Use this information to
customize the "definition of 'blah' must be imported from another
module" diagnostic with the module the user actually has to
import. Additionally, recover by importing that module, so we don't
complain about other names in that module.
Still TODO: coming up with decent Fix-Its for these cases, and expand
this recovery approach for other name lookup failures.
llvm-svn: 172290
|
|
|
|
|
|
|
| |
Before we were only checking if the new declaration itself was marked extern
C. Fixes prpr14766.
llvm-svn: 172243
|
|
|
|
|
|
| |
external declarations with C language linkage.
llvm-svn: 172150
|
|
|
|
|
|
|
|
|
|
| |
(because they are part of some module) but have not been made visible
(because they are in a submodule that wasn't imported), filter out
those declarations unless both the old declaration and the new
declaration have external linkage. When one or both has internal
linkage, there should be no conflict unless both are imported.
llvm-svn: 171925
|
|
|
|
| |
llvm-svn: 171902
|
|
|
|
| |
llvm-svn: 171894
|
|
|
|
|
|
|
| |
The availability implies default visibility, so it can change the computed
visibility.
llvm-svn: 171840
|
|
|
|
|
|
|
|
| |
<objc/Protocol.h>. Caused by my recent changes for
various builtin declarations of objc_msgSendSuper
variety. // rdar://12489098
llvm-svn: 171638
|
|
|
|
|
|
|
| |
to match those foung in objc.h an avoid spurious warnings.
// rdar://12489098
llvm-svn: 171492
|
|
|
|
|
|
|
|
| |
To do so we have to wait until we know that the type of a variable has been
deduced. Sema::FinalizeDeclaration is the first callback that is used for
decl with or without initializers.
llvm-svn: 171458
|
|
|
|
| |
llvm-svn: 171457
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
| |
llvm-svn: 171263
|
|
|
|
|
|
|
|
| |
This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the logic
in Sema::IsOverload.
llvm-svn: 171193
|
|
|
|
|
|
|
| |
The language linkage of redeclarations must match. GCC was already reporting
an error for this.
llvm-svn: 171139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the body of a functions. The problem was that hasBody looks at the entire chain
and causes problems to -fvisibility-inlines-hidden if the cache was not
invalidated.
Original message:
Cache visibility of decls.
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171053
|
|
|
|
|
|
| |
It broke stage2.
llvm-svn: 171050
|
|
|
|
|
|
|
|
|
|
|
| |
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171048
|
|
|
|
| |
llvm-svn: 170992
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was removed with -Wunique-enum, which is still removed. The
corresponding thread on cfe-comments for that warning is here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024224.html
If we get specific user feedback for -Wduplicate-enum we can evaluate
whether or not to keep it.
llvm-svn: 170974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and make sure additional uses don't get introduced. <rdar://problem/12858424>.
llvm-svn: 170081
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This fixes PR14339.
llvm-svn: 169705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
that was skipped by the parser.
llvm-svn: 169531
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
expose only the iterators instead.
llvm-svn: 168770
|