constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.
llvm-svn: 113545
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
the function processing the format string can decided whether or not to accept a null format string (e.g., asl_log). Fixes <rdar://problem/8269537>.
llvm-svn: 113469
covered by individual case statements. Flow-based analyses may wish to consult this information,
and recording this in the AST allows us to obviate reconstructing this information later when
we build the CFG.
llvm-svn: 113447
TreeTransform, since we were getting an empty source range where we
shouldn't. Sadly, the test case is Boost.Proto, and isn't worth
reducing.
llvm-svn: 113446
typeid expressions:
- make sure we have a proper source location for the closing ')'
- cache the declaration of std::type_info once we've found it
llvm-svn: 113441
function-style cast. Previously, we had a (redundant, incorrect)
semantic-checking path for non-class types, which allowed
value-initialization of a reference type and then crashed.
llvm-svn: 113415
Fixes PR8110, and thus PR8109, PR8097, and parts of PR8101, PR8105 and PR8107. Only a few traits have tests for incomplete arrays, since I'm not yet clear what the result for them should be; Howards wants to file a DR to change the standard.
llvm-svn: 113326
restrictions. The note's not really on the right place given its wording,
but putting a second note on the call site (or muddying the wording) doesn't
appeal.
There are corner cases where this can be wrong, but I'm not concerned.
llvm-svn: 112950
should probably be removed if it has no purpose, but I just #if'd it out
in case it's usefulIdempotentOperationChecker::isTruncationExtensionAssignment
should probably be removed if it has no purpose, but I just #if'd it out
in case it's useful
llvm-svn: 112949
The rationale behind this is that it is normal for callback functions to have a non-void return type
and it should still be possible to mark them noreturn. (JavaScriptCore is a good example of this).
llvm-svn: 112918
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
libclang. This includes:
- Cursor kind for function templates, with visitation logic
- Cursor kinds for template parameters, with visitation logic
- Visitation logic for template specialization types, qualified type
locations
- USR generation for function templates, template specialization
types, template parameter types.
Also happens to fix PR7804, which I tripped across while testing.
llvm-svn: 112604
declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.
llvm-svn: 112579
instantiating the parameters. In a perfect world, this wouldn't
matter, and compilers are free to instantiate in any order they
want. However, every other compiler seems to instantiate the return
type first, and some code (in this case, Boost.Polygon) depends on
this and SFINAE to avoid instantiating something that shouldn't be
instantiated.
We could fight this battle, and insist that Clang is allowed to do
what it does, but it's not beneficial: it's more predictable to
instantiate this way, in source order. When we implement
late-specified return types, we'll need to instantiate the return type
last when it was late-specified, hence the FIXME.
We now compile Boost.Polygon properly.
llvm-svn: 112561
of that parameter, reduce the level by the number of active template
argument lists rather than by 1. The number of active template
argument lists is only > 1 when we have a class template partial
specialization of a member template of a class template that itself is
a member template of another class template.
... and Boost.MSM does this. Fixes PR7669.
llvm-svn: 112551
namely when the friend function prototype is already used
at the point of the template definition that is supposed
to inject the friend function. Testcase verifies four
scenarios.
I would like receive some code review for this.
llvm-svn: 112524
deduction where the parameter is a function reference, function
pointer, or member function pointer and the argument is an overloaded
function. Fixes <rdar://problem/8360106>, a template argument
deduction issue found by Boost.Filesystem.
llvm-svn: 112523
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
the parameter names from the completions, e.g., provide
withString:(NSString *)
instead of
withString:(NSString *)string
since the parameter name is, by convention, redundant with the
selector piece that precedes it and the completions can get
unnecessarily long.
llvm-svn: 112456
of prioritizing just by initialization order, we bump the priority of
just the *next* initializer in the list, and leave everything else at
the normal priority. That way, if one intentionally skips the
initialization of a base or member (to get default initialization),
we'll still get ordered completion for the rest.
llvm-svn: 112454
For large floats/integers, APFloat/APInt will allocate memory from the heap to represent these numbers.
Unfortunately, when we use a BumpPtrAllocator to allocate IntegerLiteral/FloatingLiteral nodes the memory associated with
the APFloat/APInt values will never get freed.
I introduce the class 'APNumericStorage' which uses ASTContext's allocator for memory allocation and is used internally by FloatingLiteral/IntegerLiteral.
Fixes rdar://7637185
llvm-svn: 112361
an object of type I, if the current access target is protected
when named in a class N, consider the friends of the classes P
where I <= P <= N and where a notional member of N would be
non-forbidden in P.
llvm-svn: 112358
member function you're typing in overrides another virtual function,
this fills in a (qualified!) call to that virtual function to make
such delegation easy.
llvm-svn: 112294
a message send to "super" from a method that appears to be meant to
override a superclass method (same kind, same selector, same argument
types), provide a "super" completion that fills in the selector along
with forwarding the method's arguments (as placeholders).
llvm-svn: 112263
an '&' expression from the second caller of ActOnIdExpression.
Teach template argument deduction that an overloaded id-expression
doesn't give a valid type for deduction purposes to a non-static
member function unless the expression has the correct syntactic
form.
Teach ActOnIdExpression that it shouldn't try to create implicit
member expressions for '&function', because this isn't a
permitted form of use for member functions.
Teach CheckAddressOfOperand to diagnose these more carefully.
Some of these cases aren't reachable right now because earlier
diagnostics interrupt them.
llvm-svn: 112258
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
function, take into account the qualifiers on the object argument
(e.g., what will become "this"), filtering around uncallable member
functions and giving a slight priority boost to those with
exactly-matching qualifiers.
llvm-svn: 112193
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
3rd try. How embarrassing.
llvm-svn: 112180
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
llvm-svn: 112149
vectors that are the same size. Fix up testcases accordingly and add a new one
to make sure we still error if lax vector conversions are disabled.
Fixes rdar://8328190
llvm-svn: 112122
This works courtesy of the new SmallVector<..., 0> specialization that
doesn't require a complete type. Note that you'll need to pull at least
SmallVector.h from LLVM to compile successfully.
llvm-svn: 112114
code-completion results cached by ASTUnit, sort the resulting result
set. This makes testing far, far easier, so this commit also includes
tests for the previous few fixes.
llvm-svn: 112070
token. The first token might be something that ends up triggering code
completion, which in turn requires a valid Scope. Test case forthcoming.
llvm-svn: 112066
templates when only the declaration is in scope. This requires deferring the
instantiation to be lazy, and ensuring the definition is required for that
translation unit. We re-use the existing pending instantiation queue,
previously only used to track implicit instantiations which were required to be
lazy. Fixes PR7979.
A subsequent change will rename *PendingImplicitInstantiations to
*PendingInstatiations for clarity given its broader role.
llvm-svn: 112037
only form pointers-to-member if the expression has the appropriate
form. This avoids assertions later on on invalid code, but also
allows us to properly resolve mixed-staticity overloads.
llvm-svn: 111987
previous use of a synthesized 'ivar' with property of same name
declared as @dynamic. In this case, 'ivar' is in the
inherited class and no diagnostics should be issued.
llvm-svn: 111940
class extensions (nonfragile-abi2).For every class @interface and class
extension @interface, if the last ivar is a bitfield of any type,
then add an implicit `char :0` ivar to the end of that interface.
llvm-svn: 111857
argument in a for-each statement (e.g., "for (id x in <blah>)"), which
restricts the expression completions provided to Objective-C types (or
class types in C++).
llvm-svn: 111843
declarator. Here, we can only see a few things (e.g., cvr-qualifiers,
nested name specifiers) and we do not want to provide other non-macro
completions. Previously, we would end up in recovery mode and would
provide a large number of non-relevant completions.
llvm-svn: 111818
constructors. We perform semantic checking when creating the definition, and
this isn't needed in certain contexts (value initialization) but is in others
(default initialization). This fixes PR7948.
We add explicit code to the default initialization path to ensure the
definition is both present and valid.
Doug, please review. I think this follows your latest suggestion, and it ended
up remarkably cleaner than I anticipated. Also let me know if similar logic
should be followed for destructors and copy-constructors.
llvm-svn: 111802
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
conversion a second time for a conversion candidate (with the real
acting context), because the only problems we would find are access or
ambiguity issues that won't be diagnosed until we pick this
candidate. Add a test case to prove it to myself.
llvm-svn: 111526
conversion functions as if their acting context were the class that
we're converting from (the implicit object argument's
type). Retroactively tweaking the implicit conversion sequence, as we
were trying to do before, breaks the invariants of that implicit
conversion sequence (e.g., the types and conversions don't match
up). Fixes <rdar://problem/8018274>.
llvm-svn: 111520
active C++ ABI as a raw string, we store it as an enum. This should improve
performance somewhat.
And yes, this time, I started from a clean build directory, and
all the tests passed. :)
llvm-svn: 111507
Now all classes derived from Attr are generated from TableGen.
Additionally, Attr* is no longer its own linked list; SmallVectors or
Attr* are used. The accompanying LLVM commit contains the updates to
TableGen necessary for this.
Some other notes about newly-generated attribute classes:
- The constructor arguments are a SourceLocation and a Context&,
followed by the attributes arguments in the order that they were
defined in Attr.td
- Every argument in Attr.td has an appropriate accessor named getFoo,
and there are sometimes a few extra ones (such as to get the length
of a variadic argument).
Additionally, specific_attr_iterator has been introduced, which will
iterate over an AttrVec, but only over attributes of a certain type. It
can be accessed through either Decl::specific_attr_begin/end or
the global functions of the same name.
llvm-svn: 111455
which in a fit of zeal wanted to walk the entire translation unit,
and replace it with a new checker that walks the types of declarations
nested within the class. Also, look into templates when doing this.
llvm-svn: 111357
than GCC 4.2 here when building 32-bit (where GCC will allow
allocation of an array for which we can't get a valid past-the-end
pointer), and emulate its odd behavior in 64-bit where it only allows
63 bits worth of storage in the array. The former is a correctness
issue; the latter is harmless in practice (you wouldn't be able to use
such an array anyway) and helps us pass a GCC DejaGNU test.
Fixes <rdar://problem/8212293>.
llvm-svn: 111338
This option is not part of the Unused diagnostic group until the warnings on llvm codebase are fixed
and we are ready to turn it on. Suggestion by Daniel.
llvm-svn: 111298
nested-name-specifiers. Also includes fixes to the generation of
nested-name-specifier result in the non-cached case; we were producing
lame results for namespaces and namespace aliases, which (1) didn't
always have nested-name-specifiers when we want them, and (2) did not
have the necessary "::" as part of the completion.
llvm-svn: 111203
type class, so that we can adjust priorities appropriately when the
preferred type for the context and the actual type of the completion
are similar.
This gets us one step closer to parity of the cached completion
results with the non-cached completion results.
llvm-svn: 111139
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit completion logic
introduces the completion strings for those declarations if the actual
code-completion occurs in one of the contexts where it matters.
There are a few new code-completion-context kinds. Without these,
certain completions (e.g., after "using namespace") would need to
suppress all global completions, which would be unfortunate.
Note that we don't get the priorities right for global completions,
because we don't have enough type information. We'll need a way to
compare types in an ASTContext-agnostic way before this can be
implemented.
llvm-svn: 111093
Unused warnings for functions:
-static functions
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
Unused warnings for variables:
-static variables
-variables in anonymous namespace
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
Reveals lots of opportunities for dead code removal in llvm codebase that will
interest my esteemed colleagues.
llvm-svn: 111086
when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-completion
results for macro definitions after we have parsed the file, then
store an ASTContext-agnostic version of those results (completion
string, cursor kind, priority, and active contexts) in the
ASTUnit. When performing code completion in that ASTUnit, we splice
the macro definition results into the results provided by the actual
code-completion (which has had macros turned off) before libclang gets
those results. We use completion context information to only splice in
those results that make sense for that context.
With a completion involving all of the macros from Cocoa.h and a few other
system libraries (totally ~8500 macro definitions) living in a
precompiled header, we get about a 9% performance improvement from
code completion, since we no longer have to deserialize all of the
macro definitions from the precompiled header.
Note that macro definitions are merely the canary; the cache is
designed to also support other top-level declarations, which should be
a bigger performance win. That optimization will be next.
Note also that there is no mechanism for determining when to throw
away the cache and recompute its contents.
llvm-svn: 111051
-static variables
-variables in anonymous namespace (fixes rdar://7794535)
-static data members in anonymous namespace
-static data members specializations in anonymous namespace
llvm-svn: 111027
-static function declarations
-functions in anonymous namespace
-class methods in anonymous namespace
-class method specializations in anonymous namespace
-function specializations in anonymous namespace
llvm-svn: 111026
qua templates. The current fix suppresses the access check entirely
in this case; to do better, we'd need to be able to say that a
particular lookup result came from a particular injected class name,
which is not easy to do with the current representation of LookupResult.
This is on my known-problems list.
llvm-svn: 111009
used when parsing (or re-parsing) a file. Also, when loading a
precompiled header into ASTUnit, create a Sema object that holds onto
semantic-analysis information.
llvm-svn: 111003
can create (and hold on to) the Sema object. Also, move Sema-related
initialization/finalization with its various consumers and external
sources into the Sema constructor and destructor, rather than placing
it in ParseAST.
llvm-svn: 110973
from GCC's in that we warn on *any* increase in alignment requirements, not
just those that are enforced by hardware. Please let us know if this causes
major problems for you (which it shouldn't, since it's an optional warning).
llvm-svn: 110959
can create (and hold on to) the Sema object. Also, move Sema-related
initialization/finalization with its various consumers and external
sources into the Sema constructor and destructor, rather than placing
it in ParseAST.
llvm-svn: 110952
that actually refer to the same underlying type, it is not an
ambiguity; add uniquing support based on the canonical type of type
declarations. Fixes <rdar://problem/8296180>.
llvm-svn: 110806
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
llvm-svn: 110803
implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.
As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.
The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.
Fixes PR7055. Bootstrapped okay.
llvm-svn: 110773
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead to a 0.5% increase in memory use and no speed regression when parsing Cocoa.h. On the other hand, now chained PCH works when there's a forward declaration in one PCH and the interface definition in another.
- Add HandleInterestingDecl to ASTConsumer. PCHReader passes the "interesting" decls it finds to this function instead of HandleTopLevelDecl. The default implementation forwards to HandleTopLevelDecl, but ASTUnit's handler for example ignores them. This fixes a potential crash when lazy loading of PCH data would cause ASTUnit's "top level" declaration collection to change while being iterated.
llvm-svn: 110610
an lvalue of another, compatible Objective-C object type (e.g., a
subclass). Introduce a new initialization sequence step kind to
describe this binding, along with a new cast kind. Fixes PR7741.
llvm-svn: 110513
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
llvm-svn: 110507
a template-argument-list. When template template parameters are
involved, we won't already have checked the template-argument-list (it
may not be known yet!). Fixes PR7807.
llvm-svn: 110444
the else clause. The problem is that it's overly zealous and will respond to
uses in assignments, or after assignments. We should bring this back once we
can do it right. Fixes PR7100.
llvm-svn: 110314
just means "not a function type", not "not a function type or void". This
changes behavior slightly, but generally in a way which accepts more code.
llvm-svn: 110303
completion within the translation unit using the same command-line
arguments for parsing the translation unit. Eventually, we'll reuse
the precompiled preamble to improve code-completion performance, and
this also gives us a place to cache results.
Expose this function via the new libclang function
clang_codeCompleteAt(), which performs the code completion within a
CXTranslationUnit. The completion occurs in-process
(clang_codeCompletion() runs code completion out-of-process).
llvm-svn: 110210
a switch or goto somewhere in the function. Indirect gotos trigger the
jump-checker regardless, because the conditions there are slightly more
elaborate and it's too marginal a case to be worth optimizing.
Turns off the jump-checker in a lot of cases in C++. rdar://problem/7702918
llvm-svn: 109962
dependent bases, construct a dependent nested-name-specifier rather
than complaining that the name could not be found within the current
instantiation itself. Fixes PR7725.
llvm-svn: 109582
when the RHS of the ||/&& is ever 0 or 1. This handles a variety of
creative idioms for "true" used in C programs and fixes many false
positives at the expense of a few false negatives. This fixes
rdar://8230351.
llvm-svn: 109314
them as such. Type::is(Signed|Unsigned|)IntegerType() now return false
for vector types, and new functions
has(Signed|Unsigned|)IntegerRepresentation() cover integer types and
vector-of-integer types. This fixes a bunch of latent bugs.
Patch from Anton Yartsev!
llvm-svn: 109229
GCC emits a warning instead of an error when using an unavailable Objective-C protocol, so now
Clang's behavior is more strict in this case, but more consistent. We will need to see how much
this fires on real code and determine whether this case should be downgraded to a warning.
Fixes <rdar://problem/8213093>.
llvm-svn: 109033
FunctionTemplateDecl::findSpecialization.
Redeclarations of specializations will not cause the previous decl to be removed from the set,
the set will keep the canonical decl. findSpecialization will return the most recent redeclaration.
llvm-svn: 108834
leaks though) and add methods to its interface for adding/finding specializations.
Simplifies its users a bit and we no longer need to replace specializations in the folding set with
their redeclarations. We just return the most recent redeclarations.
As a bonus, it fixes http://llvm.org/PR7670.
llvm-svn: 108832
A ParmVarDecl instantiated from a FunctionProtoType may have Record as DeclContext,
in which case isStaticDataMember() will erroneously return true.
llvm-svn: 108692
The rationale is that we are copying the entire definition including
parameter names which may differ between the declaration and the
definition.
This is particularly important if any parameters are unnamed in the
declaration, as a DeclRef to an unnamed ParmVarDecl would cause the
pretty printer to produce invalid output.
llvm-svn: 108643
their call expressions synthetically have the "deduced" types based on their
first argument. We only insert conversions in the AST for arguments whose
values require conversion to match the value type expected. This keeps PR7600
closed by maintaining the return type, but avoids assertions due to unexpected
implicit casts making the type unsigned (test case added from Daniel).
The magic is moved into the codegen for the atomic builtin which inserts the
casts as needed at the IR level to raise the type to an integer suitable for
the LLVM intrinsic. This shouldn't cause any real change in functionality, but
now we can make the builtin be more truly polymorphic.
llvm-svn: 108638
expression such as the "foo" in "this->blah.foo<1, 2>", and we can't
look into the type of "this->blah" (e.g., because it is dependent),
look into the local scope of a template of the same name. Fixes
<rdar://problem/8198511>.
llvm-svn: 108531
handling the parsing of scanf format strings and hooking the checking into Sema.
Most of this checking logic piggybacks on what was already there for checking printf format
strings, but the checking logic has been refactored to support both.
What is left to be done is to support argument type checking in format strings and of course
fix the usual tail of bugs that will follow.
llvm-svn: 108500
represent builtins that have the "scanf" attribution (via the format attribute) just
like we do with printf functions. Follow-up work is needed to add similar support
for fscanf et al.
This is to support format-string checking for scanf functions.
llvm-svn: 108499
definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.
llvm-svn: 108372
reinterpret_casts (possibly indirectly via C-style/functional casts)
on values, e.g.,
int i;
reinterpret_cast<short&>(i);
The IR generated for this is essentially the same as for
*reinterpret_cast<short*>(&i).
Fixes PR6437, PR7593, and PR7344.
llvm-svn: 108294
t2.c:2:12: warning: use of logical && with constant operand; switch to bitwise &
or remove constant [-Wlogical-bitwise-confusion]
return x && 4;
^ ~
wording improvement suggestions are welcome.
llvm-svn: 108260
(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary.
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253
size" error for code like
new (int [size])
to a warning, add a Fix-It to remove the parentheses, and make this
diagnostic work properly when it occurs in a template
instantiation. <rdar://problem/8018245>.
llvm-svn: 108242
effect warning" by printing the qualifiers we saw and correctly
pluralizing the message, e.g.,
test/SemaCXX/conditional-expr.cpp:295:3: warning: 'const volatile' type
qualifiers on return type have no effect
const volatile Enum g2() {
^~~~~ ~~~~~~~~
llvm-svn: 108236
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.
llvm-svn: 108217
around by exempting enums from the check, but this doesn't handle a lot of
cases. A better approach is to directly check if the operator comes from
a macro expansion.
I've removed a reference to the rdar that originally led to the enum
suppression when removing it's overly contrived test case. Let me know if that
number or a more reasilistic test case involving enums is still needed.
llvm-svn: 108128
default arguments to template parameters don't have a DeclContext when
instantiated, and so we can't detect that we're in an instantiation context as
opposed to the definition context. However, it fixes the more commonly-occuring
cases in TMP code that use devolve to this type of tautology after
substitution.
llvm-svn: 108044
expected value type. This is necessary as the builtin is internally represented
as only operating on integral types.
Also, add a FIXME to add support for floating point value types.
llvm-svn: 108002
selector of an Objective-C method declaration, e.g., given
- (int)first:(int)x second:(int)y;
this code completion point triggers at the location of "second". It
will provide completions that fill out the method declaration for any
known method, anywhere in the translation unit.
llvm-svn: 107929
unknown attributes that we discard. Add a diagnostic group for unknown
attribute warnings to allow turning these off when we don't care. Also
consolidates the tests for this case.
llvm-svn: 107864
typedefs won't have the same canonical declaration (since they are
distinct), so we need to check for this case specifically. Fixes
<rdar://problem/8018262>.
llvm-svn: 107833
CXXConstructExpr/CXXTemporaryObjectExpr/CXXNewExpr as
appropriate. Fixes PR7556, and provides a slide codegen improvement
when copy-initializing a POD class type from a value-initialized
temporary. Previously, we weren't eliding the copy.
llvm-svn: 107827
declarations when implicitly declaring the default constructor, copy
constructor, destructor, and copy-assignment operators of a
class. Argiris fixed the underlying problem in r107596.
llvm-svn: 107681
Currently, adding it to visible decls of a PCH'ed translation unit has no effect because
adding visible decls before deserialization has no effect (the decls won't be visible).
This will be fixed in a future commit; then it will force deserialization of visible decls, so avoid pointlessly installing it.
llvm-svn: 107595
declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
llvm-svn: 107551
allows Sema some limited access to the current scope, which we only
use in one way: when Sema is performing some kind of declaration that
is not directly driven by the parser (e.g., due to template
instantiatio or lazy declaration of a member), we can find the Scope
associated with a DeclContext, if that DeclContext is still in the
process of being parsed.
Use this to make the implicit declaration of special member functions
in a C++ class more "scope-less", rather than using the NULL Scope hack.
llvm-svn: 107491
aren't dropping all exception specifications on destructors, the
exception specifications on implicitly-declared destructors were
detected as being wrong (which they were).
Introduce logic to provide a proper exception-specification for
implicitly-declared destructors. This also fixes PR6972.
Note that the other implicitly-declared special member functions also
need to get exception-specifications. I'll deal with that in a
subsequent commit.
llvm-svn: 107385
parameters starts at the end of the template-parameter rather than at
the point where the template parameter name is encounted. For example,
given:
typedef unsigned char T;
template<typename T = T> struct X0 { };
The "T" in the default argument refers to the typedef of "unsigned
char", rather than referring to the newly-introduced template type
parameter 'T'.
Addresses <rdar://problem/8122812>.
llvm-svn: 107354
union whose first field has integral vector type. Also, clean up this
diagnostic a bit. Thanks to Eli for spotting this change in semantics
last week.
llvm-svn: 107296
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
Previously we relied on the presence of a member which needs no initialization
to prevent us from creating an additional initialization of the outer anonymous
union field. We have already correctly marked that field as initialized by the
member of the union (repeatedly due to the original bug this patch fixes) so we
simply need to bail out.
llvm-svn: 107242
anonymous union under the presumption that they didn't do anything. While this
is true, our checks for redundant initialization of an anonymous union still
fire when these overlap with explicit user initialization. A cleaner approach
is to avoid initializing multiple members of a union altogether, but this still
is in a rather fuzzy are especially when C++0x allows non-POD types into
unions.
llvm-svn: 107235
type to an integral or enumeration type in the size of an array new
expression, e.g.,
new int[ConvertibleToInt(10)];
This is a GNU and C++0x extension.
llvm-svn: 107229
initialization. I tried several ideas but couldn't come up with a test case for
this that didn't rely on a Clang bug to report a diagnostic after template
instantiation of the constructor due to the implicit initializers. Suggestions
welcome. This fixes the source location aspect of PR7402.
llvm-svn: 107226
have integral or enumeration type, so that we still check the contents
of the switch body. My previous patch made this worse; now we're back
to where we were previously.
llvm-svn: 107223
enumeration type out into a separate, reusable routine. The only
functionality change here is that we recover a little more
aggressively from ill-formed switch conditions.
llvm-svn: 107222
unimplemented property warning for properties
coming from class's conformin protocol. It also
simplifies the algorithm in the process.
Fixes radar 8035776.
llvm-svn: 107174
This is more targeted, as it simply provides toggle actions for the parser to
turn access checking on and off. We then use these to suppress access checking
only while we parse the template-id (included scope specifier) of an explicit
instantiation and explicit specialization of a class template. The
specialization behavior is an extension, as it seems likely a defect that the
standard did not exempt them as it does explicit instantiations.
This allows the very common practice of specializing trait classes to work for
private, internal types. This doesn't address instantiating or specializing
function templates, although those apparently already partially work.
The naming and style for the Action layer isn't my favorite, comments and
suggestions would be appreciated there.
llvm-svn: 106993
much as we already do for allocation function lookup. Explicitly check access
for the function we actually select in one case that was previously missing,
but being caught behind the blanket diagnostics for all overload candidates.
This fixs PR7436.
llvm-svn: 106986
current attribute system, but it is enough to handle class templates which
specify parts of their alignment in terms of their template parameters.
This also replaces the attributes test in SemaTemplate with one that actually
tests working attributes instead of broken ones. I plan to add more tests here
for non-dependent attributes in a subsequent patch.
Thanks to John for walking me through some of this. =D
llvm-svn: 106818
__real myvec and __imag myvec, since they aren't all that useful (it's
just an identity function) but we might want to use them in more
restricted cases in the future (e.g., "__real mycomplexvec" could
extract the real parts of a vector of complex numbers).
llvm-svn: 106601
types, updating callers of both isFloatingType() and
isRealFloatingType() accordingly. Caught at least one issue where we
allowed one to declare a vector of vectors (!), along with cleaning up
the standard-conversion logic for C++.
llvm-svn: 106595
"floating type" in C, which does not include vector types. Introduce
Type::hasFloatingRepresentation() for the places where we want to know
whether the underlying representation is one or more floating-point
values. Remove some hacks we had where the former behavior of
Type::isFloatingType() was at odds with the language definition of the
term.
llvm-svn: 106584
floating-point conversions or floating-integral conversions. We
really, really, really need to make isFloatingType() and friends not
apply to vector types.
llvm-svn: 106551
if/while/switch/for statements to ensure that walking the children of
these statements actually works. Previously, we stored the condition
variable as a VarDecl. However, StmtIterator isn't able to walk from a
VarDecl to a set of statements, and would (in some circumstances) walk
beyond the end of the list of statements, cause Bad Behavior.
In this change, we've gone back to representing the condition
variables as DeclStmts. While not as memory-efficient as VarDecls, it
greatly simplifies iteration over the children.
Fixes the remainder of <rdar://problem/8104754>.
llvm-svn: 106504
http://llvm.org/bugs/show_bug.cgi?id=7377
Updated format string highlighting and fixits to take advantage of the new CharSourceRange class.
- Change HighlightRange to allow highlighting whitespace only in a CharSourceRange (for warnings about the ' ' (space) flag)
- Change format specifier range helper function to allow for half-open ranges (+1 to end)
- Enabled previously failing tests (FIXMEs/XFAILs removed)
- Small fixes and additions to format string test cases
M test/Sema/format-strings.c
M test/Sema/format-strings-fixit.c
M lib/Frontend/TextDiagnosticPrinter.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 106480
attribute as part of the calculation. Sema::MarkDeclReferenced(), and
a few other places, want only to consider the "used" bit to determine,
e.g, whether to perform template instantiation. Fixes a linkage issue
with Boost.Serialization.
llvm-svn: 106252
- Added warning for undefined behavior when using field specifier
- Added warning for undefined behavior when using length modifier
- Fixed warnings for invalid flags
- Added warning for ignored flags
- Added fixits for the above warnings
- Fixed accuracy of detecting several undefined behavior conditions
- Receive normal warnings in addition to security warnings when using %n
- Fix bug where '+' flag would remain on unsigned conversion suggestions
Summary of changes:
- Added expanded tests
- Added/expanded warnings
- Added position info to OptionalAmounts for fixits
- Extracted optional flags to a wrapper class with position info for fixits
- Added several methods to validate a FormatSpecifier by component, each checking for undefined behavior
- Fixed conversion specifier checking to conform to C99 standard
- Added hooks to detect the invalid states in CheckPrintfHandler::HandleFormatSpecifier
Note: warnings involving the ' ' (space) flag are temporarily disabled until whitespace highlighting no longer triggers assertions. I will make a post about this on cfe-dev shortly.
M test/Sema/format-strings.c
M include/clang/Basic/DiagnosticSemaKinds.td
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 106233
1. builtins definitions for BuiltinsARM.def
2. intrinsic validation code for SemaChecking
Unsure as to whether this is the best way to handle the make dependencies or not.
llvm-svn: 106208
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.
llvm-svn: 106167
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.
llvm-svn: 106161
virtual base class, but the class still has dependent base classes,
then don't diagnose the failed match as an error: the right base class
might magically appear. Fixes PR7259.
llvm-svn: 106103
introduced by using decls are hidden even if their template parameter lists
or return types differ from the "overriding" declaration.
Propagate using shadow declarations around more effectively when looking up
template-ids. Reperform lookup for template-ids in member expressions so that
access control is properly set up.
Fix some number of latent bugs involving template-ids with totally invalid
base types. You can only actually get these with a scope specifier, since
otherwise the template-id won't parse as a template-id.
Fixes PR7384.
llvm-svn: 106093
provides C "integer type" semantics in C and C++ "integral type"
semantics in C++.
Note that I still need to update isIntegerType (and possibly other
predicates) using the same approach I've taken for
isIntegralType(). The two should have the same meaning, but currently
don't (!).
llvm-svn: 106074
in C++ that involve both integral and enumeration types. Convert all
of the callers to Type::isIntegralType() that are meant to work with
both integral and enumeration types over to
Type::isIntegralOrEnumerationType(), to prepare to eliminate
enumeration types as integral types.
llvm-svn: 106071
objective-c++ class objects which have GC'able objc object
pointers and need to use ObjC's objc_memmove_collectable
API (radar 8070772).
llvm-svn: 106061
C++ semantics, eliminating an extension diagnostic that doesn't match
C++ semantics (ordered comparison with NULL) and tightening some
extwarns to errors in C++ to match GCC and maintain conformance in
SFINAE contexts. Fixes <rdar://problem/7941392>.
llvm-svn: 106050
Stmt* such as those which occur in ?: . Fixes PR7378.
Also, generally whip the code into shape fixing several coding style violations.
llvm-svn: 105992
case of an elaborated-type-specifier like 'typename A<T>::foo', and
DependentTemplateSpecializationType represents the case of an
elaborated-type-specifier like 'typename A<T>::template B<T>'. The TypeLoc
representation of a DependentTST conveniently exactly matches that of an
ElaboratedType wrapping a TST.
Kill off the explicit rebuild methods for RebuildInCurrentInstantiation;
the standard implementations work fine because the nested name specifier
is computable in the newly-entered context.
llvm-svn: 105801
new design discussed on cfe-dev, with further steps in that direction to come.
It is already much more complete than the previous visitor.
Patch by Zhanyong and Craig with 80 column wraps and one missing declaration
added by me.
llvm-svn: 105709
- Refactored LengthModifier to be a class.
- Added toString methods in all member classes of FormatSpecifier.
- FixIt suggestions keep user specified flags unless incorrect.
Limitations:
- The suggestions are not conversion specifier sensitive. For example, if we have a 'pad with zeroes' flag, and the correction is a string conversion specifier, we do not remove the flag. Clang will warn us on the next compilation.
A test/Sema/format-strings-fixit.c
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 105680
being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678
or block-pointer type by removing the qualifiers parameter. Introduce a
method to perform semantic checking when adding qualifiers to a type.
llvm-svn: 105526
a member template, and you try to call the member template with an explicit
template argument. See PR7247
For example, this downgrades the error to a warning in:
template<typename T> struct set{};
struct Value {
template<typename T>
void set(T value) {
}
};
void foo() {
Value v;
v.set<double>(3.2); // Warning here.
}
llvm-svn: 105518
bring in the entire lookup table at once.
Also, give ExternalSemaSource's vtable a home. This is important because otherwise
any reference to it will cause RTTI to be emitted, and since clang is compiled
with -fno-rtti, that RTTI will contain unresolved references (to ExternalASTSource's
RTTI). So this change makes it possible to subclass ExternalSemaSource from projects
compiled with RTTI, as long as the subclass's home is compiled with -fno-rtti.
llvm-svn: 105268
The macros required for DeclNodes use have changed to match the use of
StmtNodes. The FooFirst enumerator constants have been named firstFoo
to match usage elsewhere.
llvm-svn: 105165
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
llvm-svn: 105128
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
llvm-svn: 104941
Douglas Gregor