These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162475 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162159 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162138 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162081 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162067 91177308-0d34-0410-b5e6-96231b3b80d8
as it does something unexpected (but gcc compatible).
Suggest use of __attribute__((visibility("hidden")))
on declaration instead. // rdar://7703982
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161972 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161878 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161647 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161525 91177308-0d34-0410-b5e6-96231b3b80d8
are not definitions. This follows the behavior of both gcc and earlier
versions of clang. Regression from r156531. <rdar://problem/12048621>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161523 91177308-0d34-0410-b5e6-96231b3b80d8
in duplicate -Wuninitialized warnings. Change so that only the check in
TryConstructorInitialization() will be used and a single warning be emitted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161345 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161087 91177308-0d34-0410-b5e6-96231b3b80d8
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'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160998 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160847 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160681 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160615 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160227 91177308-0d34-0410-b5e6-96231b3b80d8
to the same signature. Fix a bug in the type printer which would cause this
diagnostic to print wonderful types like 'const const int *'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160161 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160078 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation depends on the template, its arguments and parameters, but not
where it is instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160034 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159591 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158980 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158759 91177308-0d34-0410-b5e6-96231b3b80d8
The target specific __builtin_va_list types are now explicitly built instead
of injecting strings into the preprocessor input.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158592 91177308-0d34-0410-b5e6-96231b3b80d8
method definition that has its '{' attached to the method name without
a space.
With a method like:
-(id)meth{
.....
}
the logic in ObjCMethodDecl that determined the selector locations got
confused because it was initialized based on an end location for '{' but
that end location changed to '}' after the method was finished.
Fix this by having an immutable end location for the declarator and
for getLocEnd() get the end location from the body itself.
Fixes rdar://11659739.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158583 91177308-0d34-0410-b5e6-96231b3b80d8
initialization, and use that information to produce the right kind of
initialization during template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158288 91177308-0d34-0410-b5e6-96231b3b80d8
This could happen for cases like this:
- (NSArray *)getAllNames:(NSArray *)images {
NSMutableArray *results = [NSMutableArray array];
for (auto img in images) {
[results addObject:img.name];
}
return results;
}
Here the property access will fail because 'img' has type 'id', rather than,
say, NSImage.
This warning will not fire in templated code, since the 'id' could have
come from a template parameter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158239 91177308-0d34-0410-b5e6-96231b3b80d8
nested name specifiers in addition to the function's identifier when the
correction has a different nested name specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158178 91177308-0d34-0410-b5e6-96231b3b80d8
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158104 91177308-0d34-0410-b5e6-96231b3b80d8
This is a large class of false positives where anonymous enums are used to
declare constants (see Clang's Diagnostics.h for example). A small number of
true positives could probably be found in this bucket by still warning if the
anonymous enum is used in a declarator (enum { ... } x;) but so far we don't
believe this to be a source of significant benefit so I haven't bothered to
preserve those cases.
General offline review/acknowledgment by rtrieu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157713 91177308-0d34-0410-b5e6-96231b3b80d8
same value and were initialized with literals. Clang will warn on code like
this:
enum A {
FIRST = 1,
SECOND = 1
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157666 91177308-0d34-0410-b5e6-96231b3b80d8
that the methods have the same number of parameters, although we
certainly assumed this in many places. Objective-C can be insane
sometimes. Fixes <rdar://problem/11460990>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157025 91177308-0d34-0410-b5e6-96231b3b80d8
in @interface by issuing warning (off by default) under
opt'ed in flag -Winterface-block-ivar. // rdar://10763173
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156825 91177308-0d34-0410-b5e6-96231b3b80d8
// FIXME: This needs to happen before we merge declarations. Then,
// let attribute merging cope with attribute conflicts.
This was already being done for variables, but for functions we were merging
then first and then applying the attributes. To avoid duplicating merging
logic, some of the helpers in SemaDeclAttr.cpp become methods that can
handle merging two attributes in one decl or inheriting attributes from one
decl to another.
With this change we are now able to produce errors for variables with
incompatible visibility attributes or warn about unused dllimports in
variables.
This changes the attribute list iteration back to being in reverse source
code order, as that matches what decl merging does and avoids differentiating
the two cases is the merge*Attr methods.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156531 91177308-0d34-0410-b5e6-96231b3b80d8
Added support for conditional operators and tightened the exclusion of the
unary operator from all operators to only the address of operator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156450 91177308-0d34-0410-b5e6-96231b3b80d8
for having a uniform logic for adding attributes to a decl. This in turn
is needed to fix the FIXME:
// FIXME: This needs to happen before we merge declarations. Then,
// let attribute merging cope with attribute conflicts.
ProcessDeclAttributes(S, NewFD, D,
/*NonInheritable=*/false, /*Inheritable=*/true);
The idea is that mergeAvailabilityAttr will become a method. Once attributes
are processed before merging, it will be called from handleAvailabilityAttr to
handle multiple attributes in one decl:
void f(int) __attribute__((availability(ios,deprecated=3.0),
availability(ios,introduced=2.0)));
and from SemaDecl.cpp to handle multiple decls:
void f(int) __attribute__((availability(ios,deprecated=3.0)));
void f(int) __attribute__((availability(ios,introduced=2.0)));
As a bonus, use the new structure to diagnose incompatible availability
attributes added to different decls (see included testcases).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156269 91177308-0d34-0410-b5e6-96231b3b80d8
refactorings in that revision, and some of the subsequent bugfixes, which
seem to be relevant even without delayed exception specification parsing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156031 91177308-0d34-0410-b5e6-96231b3b80d8
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155808 91177308-0d34-0410-b5e6-96231b3b80d8
exception specifications in C++11 until after we've parsed the exception
specifications for nested classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155293 91177308-0d34-0410-b5e6-96231b3b80d8
exception specifications on member functions until after the closing
'}' for the containing class. This allows, for example, a member
function to throw an instance of its own class. Fixes PR12564 and a
fairly embarassing oversight in our C++98/03 support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154844 91177308-0d34-0410-b5e6-96231b3b80d8
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154799 91177308-0d34-0410-b5e6-96231b3b80d8
Infinite recursion was happening when DiagnoseInvalidRedeclaration
called ActOnFunctionDeclarator to check if a typo correction works when
the correction was just to the nested-name-specifier because the wrong
DeclContext was being passed in. Unlike a number of functions
surrounding typo correction, the DeclContext passed in for a function is
the context of the function name after applying any nested name
specifiers, not the lexical DeclContext where the
function+nested-name-specifier appears.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153962 91177308-0d34-0410-b5e6-96231b3b80d8
move constructor/move assignment operator are not declared, rather than being
defined as deleted, so move operations on the derived class fall back to
copying rather than moving.
If a move operation on the derived class is explicitly defaulted, the
unmovable subobject will be copied instead of being moved.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153883 91177308-0d34-0410-b5e6-96231b3b80d8
concerning qualified declarator-ids. We now diagnose extraneous
qualification at namespace scope (which we had previously missed) and
diagnose these qualification errors for all kinds of declarations; it
was rather uneven before. Fixes <rdar://problem/11135644>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153577 91177308-0d34-0410-b5e6-96231b3b80d8
typo correction to introduce a nested-name-specifier; we aren't
prepared to handle it here. Fixes PR12297 / <rdar://problem/11075219>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153445 91177308-0d34-0410-b5e6-96231b3b80d8
a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153349 91177308-0d34-0410-b5e6-96231b3b80d8
Benjamin Kramer