through varargs. This only happens when we're in an unevaluated
context, where we don't want to trigger an error anyway. Fixes PR11131
/ <rdar://problem/10288375>.
llvm-svn: 141986
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
function type' when that expression is actually an overloaded function
reference (and not the address of an overloaded function
reference). Fixes PR11066.
llvm-svn: 141514
C-style and functional casts are built in SemaCXXCast.cpp.
Introduce a helper class to encapsulate most of the random
state being passed around, at least one level down.
llvm-svn: 141170
return to one which does not return (has noreturn attribute)
should warn as it is an unsafe assignment. // rdar://10095762
c++ already handles this. This is the c version.
llvm-svn: 141141
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: -(id)first:(int)x second:(int)y;
-With a space between the arguments: -(id)first: (int)x second: (int)y;
-For nullary selectors, immediately before ';': -(void)release;
In such cases we infer the locations instead of storing them.
llvm-svn: 140989
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: [foo first:1 second:2]
-With a space between the arguments: [foo first: 1 second: 2]
-For nullary selectors, immediately before ']': [foo release]
In such cases we infer the locations instead of storing them.
llvm-svn: 140987
system change in <rdar://problem/10109725> that allows conversion from
'self' in class methods to the root of the class's hierarchy. This
conversion rule is a hack that has non-trivial repurcussions
(particularly with overload resolution).
llvm-svn: 140605
builds a semantic (structured) initializer list, just reports on whether it can match
the given list to the target type.
Use this mode for doing init list checking in the initial step of initialization, which
will eventually allow us to do overload resolution based on the outcome.
llvm-svn: 140457
This fixes a few errors when parsing MFC code with clang.
BTW clang trunk is now about 5 patches away to be able the parse the default wizard-generated MFC project.
llvm-svn: 140452
OpenCL 6.2.1 says: "Implicit conversions between built-in vector data types are
disallowed." OpenCL 6.2.2 says: "Explicit casts between vector types are not
legal." For example:
uint4 u = (uint4)(1);
int4 i = u; // invalid implicit conversion
int4 e = (int4)u; // invalid explicit conversion
Fixes PR10967. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140300
OpenCL is different from AltiVec in the way it supports vector literals. OpenCL
is strict with regards to semantic checks. For example, implicit conversions
and explicit casts between vectors of different types are disallowed.
Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140270
the lifetime of the block by copying it to the heap, or else we'll get
a dangling reference because the code working with the non-block-typed
object will not know it needs to copy.
There is some danger here, e.g. with assigning a block literal to an
unsafe variable, but, well, it's an unsafe variable.
llvm-svn: 139451
what 'nullPos' is supposed to mean, at least at this one site.
Use closed forms for the arithmetic. Rip out some clever but
ultimately pointless code that was trying to use 0 or 0L depending
the size of a pointer vs. the size of int; first, it didn't work
on LLP64 systems, and second, the sentinel checking code requires
a pointer-typed value anyway, so this fixit would not have actually
removed the warning.
llvm-svn: 139361
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
llvm-svn: 139352
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
llvm-svn: 138913
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
llvm-svn: 138821
to varargs functions in unevaluated contexts. AFAICT, there is no
standards justification for this, but it matches what other compilers do
and therefore preserves compatibility with certain template metaprogramming
idioms.
Should fix self-host.
llvm-svn: 138715
Old warning:
warning: use of NULL in arithmetic operation [-Wnull-arithmetic]
return 10 <= NULL;
^ ~~~~
New warning:
warning: comparison between NULL and non-pointer ('int' and NULL) [-Wnull-arithmetic]
return 10 <= NULL;
~~ ^ ~~~~
llvm-svn: 137377
ASTContext with accessors/mutators. The only functional change is that
the AST writer won't bother writing the id/Class/SEL redefinition type
if it hasn't been explicitly set; previously, it ended up being
written as a synonym for the built-in id/Class/SEL.
llvm-svn: 137349
case situations with the unary operators & and *. Also extend the array bounds
checking to work with pointer arithmetic; the pointer arithemtic checking can
be turned on using -Warray-bounds-pointer-arithmetic.
The changes to where CheckArrayAccess gets called is based on some trial &
error and a bunch of digging through source code and gdb backtraces in order
to have the check performed under as many situations as possible (such as for
variable initializers, arguments to function calls, and within conditional in
addition to the simpler cases of the operands to binary and unary operator)
while not being called--and triggering warnings--more than once for a given
ArraySubscriptExpr.
llvm-svn: 136997
when performing typo correction involving any overloaded template functions.
The added test cases, while currently demontrating sub-optimal behavior, will
not trigger any messages without the 1-line change to SemaExpr.cpp.
llvm-svn: 136943
Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.
llvm-svn: 136807
appropriate sentinel at the end of the argument list. Also, put the
sentinel warnings under -Wsentinel. Fixes <rdar://problem/8764236>.
llvm-svn: 136566
special diagnostic for ARC ownership-qualified types. We wouldn't want
to expose Objective-C programmers to the term "POD", would we? Fixes
<rdar://problem/9772982>.
llvm-svn: 136558
and to work with pointer arithmetic in addition to array indexing.
The new pointer arithmetic porition of the array bounds checking can be
turned on by -Warray-bounds-pointer-arithmetic (and is off by default).
llvm-svn: 136046
template<unsigned int A, unsigned int B> struct S {
int foo() {
int x = A && B;
}
}
will not warn on A && B on every instantiation. This will still warn on other cases inside templates, which will be caught on checking the template definition.
llvm-svn: 135222
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
llvm-svn: 135051
require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.
llvm-svn: 134906
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
(NSString**)&x; // Casting as (__strong NSString**).
llvm-svn: 134275
newly introduced Sema::BuildVectorLiteral.
-Make Sema::ActOnCastExpr handle a vector initializer both when the cast'ed expression
is a ParenListExpr and when it is a ParenExpr.
-Ultimately make Sema::ActOnParenOrParenListExpr independent of what the cast type was.
llvm-svn: 134274
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
and into a new file, SemaExprMember.cpp, bringing SemaExpr.cpp just
under 10,000 lines of code (ugh). No functionality change, although I
intend to do some refactoring of this code to address PR8368 at some
point in the "near" future.
llvm-svn: 133674
of: a + b ? x : y. In our testing of this flag we've yet to hit a single
case where the existing precedence was correct, so we should suggest
grouping the ?: first.
llvm-svn: 133526
pointers I found while working on the NULL arithmetic warning. We here
always assuming the LHS was the pointer, instead of using the selected
pointer expression.
llvm-svn: 133428
effectively that this abstraction simply doesn't exist. That is
highlighted by the fact that by using it we were papering over a more
serious error in this warning: the fact that we warned for *invalid*
constructs involving member pointers and block pointers.
I've fixed the obvious issues with the warning here, but this is
confirming an original suspicion that this warning's implementation is
flawed. I'm looking into how we can implement this more reasonably. WIP
on that front.
llvm-svn: 133425
This makes 'isPointerLikeType' a little less confusing, and pulls the
decay check into a separate interface that is much more clear and
concrete. Also, just implement these as logical wrappers around other
predicates. Having a switch based implementation isn't likely to be
necessary. We can try to optimize them later if they show up on
a profile.
llvm-svn: 133405
Trieu, and fix them by checking for array and function types as well as
pointer types.
I've added a predicate method on Type to bundle together the logic we're
using here: isPointerLikeType(). I'd welcome better names for this
predicate, this is the best I came up with. It's implemented as a switch
to be a touch lighter weight than all the chained isa<...> casts that
would result otherwise.
llvm-svn: 133383
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
C++, which means:
- binding the temporary as needed in Sema, so that we generate the
appropriate call to the destructor, and
- emitting the compound literal into the appropriate location for
the aggregate, rather than trying to emit it as a temporary and
memcpy() it.
Fixes PR10138 / <rdar://problem/9615901>.
llvm-svn: 133235
be more consistent in how parenthesized ranges which hit macros are
handled. Also makes the code significantly shorter, and the diagnostics
when macros are present a bit more useful.
Pair programmed w/ Matthew.
llvm-svn: 133122
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
Change the output for -Wshift-overflow and
-Wshift-sign-overflow to an unsigned hexadecimal. It makes
more sense for looking at bits than a signed decimal does.
Also, change the diagnostic's wording from "overrides"
to "sets".
This uses a new optional argument in APInt::toString()
that adds the '0x' prefix to hexademical numbers.
This fixes PR 9651.
Patch by nobled@dreamwidth.org!
llvm-svn: 133033
- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors
llvm-svn: 132979
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
This is a follow-up to r132565, and should address the rest of PR9969:
Warn about cases such as
int foo(A a, bool b) {
return a + b ? 1 : 2; // user probably meant a + (b ? 1 : 2);
}
also when + is an overloaded operator call.
llvm-svn: 132784
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
llvm-svn: 132612
Warn in cases such as "x + someCondition ? 42 : 0;",
where the condition expression looks arithmetic, and has
a right-hand side that looks boolean.
This (partly) addresses http://llvm.org/bugs/show_bug.cgi?id=9969
llvm-svn: 132565
I tried to use an assert to prove that I could remove each of the
arguments I did, but ended up writing my assert with inverted logic.
Doh! Reported by Xi Wang on cfe-dev. I have manually verified the source
locations and ranges for these using -ast-dump. I tried writing a test
case that would catch these, but these expressions aren't exposed in the
c-index-test's token annotation utility.
llvm-svn: 132284
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
provide re-usable forms of the rest of the custom validation done here.
Still no functionality changed here.
With this it should be possible to have an expression-centric code path
and a type-centric code path which don't duplicate logic.
llvm-svn: 132118
traits which uses the information embedded in the expression. Use this
to simplify several interfaces which repeated information embedded in
the expression through explicit arguments. I added an assertion that the
only extra piece of data to come in from the parser matches what is
stored in the expression. No functionality change intended here.
Also cleaned up the doxygen comments for some of these methods and some
formatting oddities.
llvm-svn: 132115
non-POD/non-trivial object throuugh a C-style varargs. The warning
itself was default-mapped to error, but can be downgraded, but we were
treating it in Sema like a hard error, silently dropping the call.
Instead, treat this problem like a warning, and do what the warning
says we do: abort at runtime. To do so, we fake up a __builtin_trap()
expression that gets evaluated as part of the argument.
llvm-svn: 131805
defaulted default constructors.
As it happens, making sure that we handle out-of-line defaulted
functions properly will involved making sure that we actually parse them
correctly, so that's coming after.
llvm-svn: 131224
We can use this to produce nice diagnostics (and try to fixit-and-recover) in
various cases where we might see "MyFunction" instead of "MyFunction()". The
changes in SemaExpr are an example of how to use isExprCallable.
llvm-svn: 130878
make sure to mark the destructor. This normally isn't required,
because the destructor should have been marked as part of the
declaration of the local, but it's necessary when the variable
is a parameter because it's the call sites that are responsible
for those destructors.
llvm-svn: 130372
member function, i.e. something of the form 'x.f' where 'f' is a non-static
member function. Diagnose this in the general case. Some of the new diagnostics
are probably worse than the old ones, but we now get this right much more
universally, and there's certainly room for improvement in the diagnostics.
llvm-svn: 130239
performs name lookup for an identifier and resolves it to a
type/expression/template/etc. in the same step. This scheme is
intended to improve both performance (by reducing the number of
redundant name lookups for a given identifier token) and error
recovery (by giving Sema a chance to correct type names before the
parser has decided that the identifier isn't a type name). For
example, this allows us to properly typo-correct type names at the
beginning of a statement:
t.c:6:3: error: use of undeclared identifier 'integer'; did you mean
'Integer'?
integer *i = 0;
^~~~~~~
Integer
t.c:1:13: note: 'Integer' declared here
typedef int Integer;
^
Previously, we wouldn't give a Fix-It because the typo correction
occurred after the parser had checked whether "integer" was a type
name (via Sema::getTypeName(), which isn't allowed to typo-correct)
and therefore decided to parse "integer * i = 0" as an expression. By
typo-correcting earlier, we typo-correct to the type name Integer and
parse this as a declaration.
Moreover, in this context, we can also typo-correct identifiers to
keywords, e.g.,
t.c:7:3: error: use of undeclared identifier 'vid'; did you mean
'void'?
vid *p = i;
^~~
void
and recover appropriately.
Note that this is very much a work-in-progress. The new
Sema::ClassifyName is only used for expression-or-declaration
disambiguation in C at the statement level. The next steps will be to
make this work for the same disambiguation in C++ (where
functional-style casts make some trouble), then push it
further into the parser to eliminate more redundant name lookups.
Fixes <rdar://problem/7963833> for C and starts us down the path of
<rdar://problem/8172000>.
llvm-svn: 130082
gcc's unused warnings which don't get emitted if the function is referenced even in an unevaluated context
(e.g. in templates, sizeof, etc.). Also, saying that a function is 'unused' because it won't get codegen'ed
is somewhat misleading.
- Don't emit 'unused' warnings for functions that are referenced in any part of the user's code.
- A warning that an internal function/variable won't get emitted is useful though, so introduce
-Wunneeded-internal-declaration which will warn if a function/variable with internal linkage is not
"needed" ('used' from the codegen perspective), e.g:
static void foo() { }
template <int>
void bar() {
foo();
}
test.cpp:1:13: warning: function 'foo' is not needed and will not be emitted
static void foo() { }
^
Addresses rdar://8733476.
llvm-svn: 129794
named by the nested-name-specifier is same or base of the class in which the member expression appears.
It seems we also had an ill-formed test case, mon dieu! Fixes rdar://8576107.
llvm-svn: 129493
for __unknown_anytype resolution to destructively modify the AST. So that's
what it does now, which significantly simplifies some of the implementation.
Normal member calls work pretty cleanly now, and I added support for
propagating unknown-ness through &.
llvm-svn: 129331
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
llvm-svn: 127747
operands to a binary expression; it doesn't make sense in all
contexts. The right answer would be to see if the user forgot at ().
Fixes <rdar://problem/9136502>.
llvm-svn: 127740
declaration as this results in a confusing error message,
instead of message related to missing property declaration.
// rdar://9106929
llvm-svn: 127682
UnresolvedLookupExpr and UnresolvedMemberExpr.
Also, improve the computation that checks whether the base of a member
expression (either unresolved or dependent-scoped) is implicit. The
previous check didn't cover all of the cases we use in our
representation, which threw off source-location information for these
expressions (which, in turn, caused some breakage in libclang's token
annotation).
llvm-svn: 126681
CXXDependentScopeMemberExpr, and clean up instantiation of
nested-name-specifiers with dependent template specialization types in
the process.
llvm-svn: 126663
don't let calls to such functions go down the normal type-checking path.
Test this out with __builtin_classify_type and __builtin_constant_p.
llvm-svn: 126539
expressions. Consider the code:
int64_t i = 10 << 30;
This compiles fine, but most developers expect it to produce the value
for 10 gigs, not -2 gigs. This is actually undefined behavior because
the LHS is a signed integer type.
The warning is currently gated behind -Wshift-overflow.
There is a special case where only the sign bit is overridden that gets
a custom error message and is by default ignored. This case is much less
likely to cause observed buggy behavior, it's just undefined behavior
according to the spec. This warning can be enabled with
-Wshift-sign-overflow.
Original patch by Oleg Slezberg, with style tweaks and some correctness
fixes by me.
llvm-svn: 126342
diagnostics that occur in unreachable code (e.g., -Warray-bound).
We only pay the cost of doing the reachability analysis when we issue one of these diagnostics.
llvm-svn: 126290
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
llvm-svn: 126139
initializers just because they don't have a proper out-of-line definition.
Such code is technically ill-formed but is too common and too unlikely to be
a problem to be seriously worth worrying about.
llvm-svn: 126137
without defining them. This should be an error, but I'm paranoid about
"uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable
declarations, just for safety's sake. Doing so produces an invalid module
if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal
functions without definitions.
llvm-svn: 126016
that was ignored in a few places (most notably, code
completion). Introduce Selector::getNameForSlot() for the common case
where we only care about the name. Audit all uses of
getIdentifierInfoForSlot(), switching many over to getNameForSlot(),
fixing a few crashers.
Fixed <rdar://problem/8939352>, a code-completion crasher.
llvm-svn: 125977
or union, place the qualifier on the outermost member reference
expression, which actually contains the entity name.
Fixes PR9188/<rdar://problem/8990184>.
llvm-svn: 125822
making them be template instantiated in a more normal way and
make them handle attributes like other decls.
This fixes the used/unused label handling stuff, making it use
the same infrastructure as other decls.
llvm-svn: 125771
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
different types. We omit the warning when the enum types are anonymous.
Unlike GCC, this warning does not distinguish between C++ and C/ObjC for
controling whether it is on by default, it is always on by default.
Original patch contributed by Richard Trieu (@ Google), I fixed some
style issues, and cleaned it up for submission.
llvm-svn: 125739
LabelDecl and LabelStmt. There is a 1-1 correspondence between the
two, but this simplifies a bunch of code by itself. This is because
labels are the only place where we previously had references to random
other statements, causing grief for AST serialization and other stuff.
This does cause one regression (attr(unused) doesn't silence unused
label warnings) which I'll address next.
This does fix some minor bugs:
1. "The only valid attribute " diagnostic was capitalized.
2. Various diagnostics printed as ''labelname'' instead of 'labelname'
3. This reduces duplication of label checking between functions and blocks.
Review appreciated, particularly for the cindex and template bits.
llvm-svn: 125733
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
id-expression, e.g.,
CurrentClass<T>::member
Previously, if CurrentClass<T> was dependent and not complete, we
would treat it as a dependent-scoped declaration reference expression,
even if CurrentClass<T> referred to the current instantiation.
Fixes PR8966 and improves type checking of templates.
llvm-svn: 124867
right for anonymous struct/union members led to me discovering some
seemingly broken code in that area of Sema, which I fixed, partly by
changing the representation of member pointer constants so that
IndirectFieldDecls aren't expanded. This led to assorted cleanups with
member pointers in CodeGen, and while I was doing that I saw some random
other things to clean up.
llvm-svn: 124785
Macros frequently contain extra '()' to make instantiation less error prone.
This warning was flagging a ton of times on postgresql because of its use of macros.
llvm-svn: 124695
might be queried in places where we absolutely require a valid
location (e.g., for template instantiation). Fixes some major
brokenness in the use of __is_convertible_to.
llvm-svn: 124465
For example:
class A{
public:
A& operator=(const A& that) {
if (this != &that) {
this->A::~A();
this->A::A(that); // <=== explicit constructor call.
}
return *this;
}
};
More work will be needed to support an explicit call to a template constructor.
llvm-svn: 123735
For example:
void f(long long){ printf("long long"); }
void f(unsigned long long) { printf("unsigned long long"); }
int main() {
f(0xffffffffffffffffLL);
}
Will print "long long" using MSVC.
This patch also fixes 16 compile errors related to overloading issues when parsing the MSVC 2008 C++ standard lib.
llvm-svn: 123231
the declaration-specifiers and on the declarator itself are moved
to the appropriate declarator chunk. This permits a greatly
simplified model for how to apply these attributes, as well as
allowing a much more efficient query for the GC attribute.
Now all qualifier queries follow the same basic strategy of
"local qualifiers, local qualifiers on the canonical type,
then look through arrays". This can be easily optimized by
changing the canonical qualified-array-type representation.
Do not process type attributes as decl attributes on declarations
with declarators.
When computing the type of a block, synthesize a prototype
function declarator chunk if the decl-spec type was not a
function. This simplifies the logic for building block signatures.
Change the logic which inserts an objc_read_weak on a block
literal to only fire if the block has a __weak __block variable,
rather than if the return type of the block is __weak qualified,
which is not actually a sensible thing to ask.
llvm-svn: 122871
int x = 42;
x = x; // Warns here.
The warning avoids macro expansions, templates, user-defined assignment
operators, and volatile types, so false positives are expected to be low.
The common (mis-)use of this code pattern is to silence unused variable
warnings, but a more idiomatic way of doing that is '(void)x;'.
A follow-up to this will add a note and fix-it hint suggesting this
replacement in cases where the StmtExpr consists precisely of the self
assignment.
llvm-svn: 122804
unknown type and there is a possibility that
at runtime method is resolved to a deprecated or
unavailable method. Addreses // rdar://8769853
llvm-svn: 122294
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
whether the expression contains an unexpanded parameter pack, in the
same vein as the changes to the Type hierarchy. Compute this bit
within all of the Expr subclasses.
This change required a bunch of reshuffling of dependency
calculations, mainly to consolidate them inside the constructors and
to fuse multiple loops that iterate over arguments to determine type
dependence, value dependence, and (now) containment of unexpanded
parameter packs.
Again, testing is painfully sparse, because all of the diagnostics
will change and it is more important to test the to-be-written visitor
that collects unexpanded parameter packs.
llvm-svn: 121831
class to be passed around. The line between argument and return types and
everything else is kindof vague, but I think it's justifiable.
llvm-svn: 121752
space better. Remove this reference. To make that work, change some APIs
(most importantly, getDesugaredType()) to take an ASTContext& if they
need to return a QualType. Simultaneously, diminish the need to return a
QualType by introducing some useful APIs on SplitQualType, which is
just a std::pair<const Type *, Qualifiers>.
llvm-svn: 121478
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121121
FunctionArrayLvalueConversion but without the function/array decay. Generally
this is only appropriate for use sites that know the type of the expression
and thus that it can't be subject to the decays.
Also make sure we do lvalue-to-rvalue on the bases of ivar references.
llvm-svn: 121035
build one when either of the operands calls itself type-dependent;
previously we were building when one of the operand types was dependent,
which is not always the same thing and which can lead to unfortunate
inconsistencies later. Fixes PR8739.
llvm-svn: 120990
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ. So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.
In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.
This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.
Ted Kremenek kindly contributed the analyzer workarounds in this patch.
llvm-svn: 120890
Check for compatible gcc, Altivec and Neon vectors before handling the
lax-vector-conversions case. Otherwise there is no way to avoid the
warnings from -Wvector-conversions.
llvm-svn: 120633
a specific language. We are adding such language info. by
extensing Builtins.def and via a language flag added
to LIBBUILTIN/BUILTIN and check for that when deciding
a name is builtin or not. Implements //rdar://8689273.
llvm-svn: 120429
- Default argument expressions pick up the value kind of the incoming
expression, not the value kind of the parameter it initializes.
- When building a template argument for substitution, A::x is an rvalue
if x is an instance method.
- Anonymous struct/union paths pick up value kind the same way that
normal member accesses do; extract out a common code path for this.
Enable the value-kind assertion, now that it passes self-host.
llvm-svn: 120055
A new AST node is introduced:
def IndirectField : DDecl<Value>;
IndirectFields are injected into the anonymous's parent scope and chain back to
the original field. Name lookup for anonymous entities now result in an
IndirectFieldDecl instead of a FieldDecl.
There is no functionality change, the code generated should be the same.
llvm-svn: 119919
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
assert(a || b && "bad");
since this is safe. This way we avoid a big source of such warnings which in this case are practically useless.
Note that we don't handle *all* cases where precedence wouldn't matter because of constants since
this is a bit costly to check, and IMO clarifying precedence with parentheses is good for
readability in general.
llvm-svn: 119533
implicit conversions; the last batch was specific to promotions.
I think this is the full set we need. I do think dividing the cast
kinds into floating and integral is probably a good idea.
Annotate a *lot* more C casts with useful cast kinds.
llvm-svn: 119036
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
ensuring that they cover all of their child nodes. There's still a
clang_getCursor()-related issue with CXXFunctionalCastExprs with
CXXConstructExprs as children (see FIXME in the test case); I'll look
at that separately.
llvm-svn: 118132
until after we've checked/promoted the argument. Hopefully fixes the
Emacs regression due to my recent change that expanded type-checking
in the presence of K&R function definitions.
llvm-svn: 117353
function definition, we should still use a prototype to type-check and
convert the function arguments, if such a prototype exists. Fixes
PR8314.
llvm-svn: 117305
within a default argument), recurse into default arguments. Fixes
PR8401, a regression I introduced in r113700 while refactoring our
handling of "used" declarations in default arguments.
llvm-svn: 116817
that are suppressed during template argument deduction. This change
queues diagnostics computed during template argument deduction. Then,
if the resulting function template specialization or partial
specialization is chosen by overload resolution or partial ordering
(respectively), we will emit the queued diagnostics at that point.
This addresses most of PR6784. However, the check for unnamed/local
template arguments (which existed before this change) is still only
skin-deep, and needs to be extended to look deeper into types. It must
be improved to finish PR6784.
llvm-svn: 116373
properties.
1. Generates the AST for lexical info. of accessing
getter/setter methods using dot-syntax notation.
This fixes //rdar: //8528170.
2. Modifes rewriter to handle the AST putout in 1.
3. Supportes in rewriter ObjCImplicitSetterGetter ASTs.
llvm-svn: 116237
waiting until we think we need it: we didn't catch all of the places
where we actually needed it, and we probably wouldn't ever. Fixes a
C++ PCH crasher.
llvm-svn: 115621
LHS and when conditional expression is an array. Since
it will be decayed, saved expression must be saved with
decayed expression. This is necessary to preserve semantics
of this extension (and prevent an IRGen crash which expects
an array to always be decayed). I am sure there will be other
cases in c++ (aggregate conditionals for example) when saving of the
expression must happen after some transformation on conditional
expression has happened.
Doug, please review. Fixes // rdar://8446940
llvm-svn: 114296
are expanded from macros (and if so, omit the warning). Previously we were just looking at the
location of the binary expression.
Fixes <rdar://problem/8435950>.
llvm-svn: 114044
"used", at the time that the default argument itself is used, also
mark destructors that will be called by this expression. This fixes a
regression that I introduced in r113700, which broke WebKit, and fixes
<rdar://problem/8427926>.
llvm-svn: 113883
declarations in potentially-evaluated subexpressions, about
recursion. Fixes the release-mode self-host failure I introduced in
r113700.
llvm-svn: 113708
used in the default function argument as "used". Instead, when we
actually use the default argument, make another pass over the
expression to mark any used declarations as "used" at that point. This
addresses two kinds of related problems:
1) We were marking some declarations "used" that shouldn't be,
because we were marking them too eagerly.
2) We were failing to mark some declarations as "used" when we
should, if the first time it was instantiated happened to be an
unevaluated context, we wouldn't mark them again at a later point.
I've also added a potentially-handy visitor class template
EvaluatedExprVisitor, which only visits the potentially-evaluated
subexpressions of an expression. I bet this would have been useful for
noexcept...
Fixes PR5810 and PR8127.
llvm-svn: 113700
follows objective's semantics and is not overload'able
with an assignment operator. Fixes a crash and a missing
diagnostics. Radar 8379892.
llvm-svn: 113555
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 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
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 '&' 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
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
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
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
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
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
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
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
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
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
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
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
__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
"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
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
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
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
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
temporaries. There are actually several interrelated fixes here:
- When converting an object to a base class, it's only an lvalue
cast when the original object was an lvalue and we aren't casting
pointer-to-derived to pointer-to-base. Previously, we were
misclassifying derived-to-base casts of class rvalues as lvalues,
causing various oddities (including problems with reference binding
not extending the lifetimes of some temporaries).
- Teach the code for emitting a reference binding how to look
through no-op casts and parentheses directly, since
Expr::IgnoreParenNoOpCasts is just plain wrong for this. Also, make
sure that we properly look through multiple levels of indirection
from the temporary object, but destroy the actual temporary object;
this fixes the reference-binding issue mentioned above.
- Teach Objective-C message sends to bind the result as a temporary
when needed. This is actually John's change, but it triggered the
reference-binding problem above, so it's included here. Now John
can actually test his return-slot improvements.
llvm-svn: 104434
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
llvm-svn: 104406
template names. We were completely missing naming classes for many unqualified
lookups, but this didn't trigger code paths that need it. This removes part of
an optimization that re-uses the template name lookup done by the parser to
determine if explicit template arguments actually form a template-id.
Unfortunately the technique for avoiding the duplicate lookup lost needed data
such as the class context in which the lookup succeeded.
llvm-svn: 104117
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
llvm-svn: 104022
ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
llvm-svn: 103870
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Fixes PR7114 and PR6564.
llvm-svn: 103718
if/switch/while/do/for statements. Previously, we would end up either:
(1) Forgetting to destroy temporaries created in the condition (!),
(2) Destroying the temporaries created in the condition *before*
converting the condition to a boolean value (or, in the case of a
switch statement, to an integral or enumeral value), or
(3) In a for statement, destroying the condition's temporaries at
the end of the increment expression (!).
We now destroy temporaries in conditions at the right times. This
required some tweaking of the Parse/Sema interaction, since the parser
was building full expressions too early in many places.
Fixes PR7067.
llvm-svn: 103187
"bottom-up" when implicit casts and comparisons are inserted, compute them
"top-down" when the full expression is finished. Makes it easier to
coordinate warnings and thus implement -Wconversion for signedness
conversions without double-warning with -Wsign-compare. Also makes it possible
to realize that a signedness conversion is okay because the context is
performing the inverse conversion. Also simplifies some logic that was
trying to calculate the ultimate comparison/result type and getting it wrong.
Also fixes a problem with the C++ explicit casts which are often "implemented"
in the AST with a series of implicit cast expressions.
llvm-svn: 103174
typedef int functype(int, int);
functype func;
also instantiate the synthesized function parameters for the resulting
function declaration.
With this change, Boost.Wave builds and passes all of its regression
tests.
llvm-svn: 103025
assignment operators.
Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.
This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:
- For a class subobject, call the appropriate copy-assignment
operator, after overload resolution has determined what that is.
- For an array of scalar types or an array of class types that have
trivial copy assignment operators, construct a call to
__builtin_memcpy.
- For an array of class types with non-trivial copy assignment
operators, synthesize a (possibly nested!) for loop whose inner
statement calls the copy constructor.
- For a scalar type, use built-in assignment.
This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.
Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.
llvm-svn: 102853
information required to implicitly define a C++ special member
function. Use it rather than explicitly setting CurContext on entry
and exit, which is fragile.
Use this RAII object for the implicitly-defined default constructor,
copy constructor, copy assignment operator, and destructor.
llvm-svn: 102840
classes, since we only warn (not error) on offsetof() for non-POD
types. We store the base path within the OffsetOfExpr itself, then
evaluate the offsets within the constant evaluator.
llvm-svn: 102571
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
complete, return an error rather than falling back to building a
dependent declaration reference, since we might not be in a dependent
context. Fixes a fiendish crash-on-invalid in Boost.FunctionTypes that
I wasn't able to reduce to anything useful.
llvm-svn: 102491
UnresolvedLookupExpr and UnresolvedMemberExpr by substituting the
naming class we computed when building the expression in the
template...
... which we didn't always do correctly. Teach
UnresolvedMemberExpr::getNamingClass() all about the new
representation of injected-class-names in templates, so that it can
return a naming class that is the current instantiation.
Also, when decomposing a template-id into its template name and its
arguments, be sure to set the naming class on the LookupResult
structure.
Fixes PR6947 the right way.
llvm-svn: 102448
using declaration, look at its underlying declaration to determine the
lookup result kind (e.g., overloaded, unresolved). Fixes at least one
issue in Boost.Bimap.
llvm-svn: 102317
support dependent receivers for class and instance messages, along
with dependent message arguments (of course), and check as much as we
can at template definition time.
This commit also deals with a subtle aspect of template instantiation
in Objective-C++, where the type 'T *' can morph from a dependent
PointerType into a non-dependent ObjCObjectPointer type.
llvm-svn: 102071
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
llvm-svn: 101972
TryStaticImplicitCast (for references, class types, and everything
else, respectively) into a single invocation of
InitializationSequence.
One of the paths (for class types) was the only client of
Sema::TryInitializationByConstructor, which I have eliminated. This
also simplified the interface for much of the cast-checking logic,
eliminating yet more code.
I've kept the representation of C++ functional casts with <> 1
arguments the same, despite the fact that I hate it. That fix will
come soon. To satisfy my paranoia, I've bootstrapped + tested Clang
with these changes.
llvm-svn: 101549
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
llvm-svn: 101274
that adds parentheses from the main diagnostic down to a new
note. This way, when the fix-it represents a choice between two
options, each of the options is associted with a note. There is no
default option in such cases. For example:
/Users/dgregor/t.c:2:9: warning: & has lower precedence than ==; ==
will be
evaluated first [-Wparentheses]
if (x & y == 0) {
^~~~~~~~
/Users/dgregor/t.c:2:9: note: place parentheses around the &
expression to
evaluate it first
if (x & y == 0) {
^
( )
/Users/dgregor/t.c:2:9: note: place parentheses around the ==
expression to
silence this warning
if (x & y == 0) {
^
( )
llvm-svn: 101249
name-lookup ambiguities when there are multiple base classes that are
all specializations of the same class template. This is part of a
general cleanup for ambiguities in template-name lookup. Fixes
PR6717.
llvm-svn: 101065
LookupInObjCMethod. Doing so allows all sorts of invalid code
to slip through to codegen. This patch does not change the
AST representation of super, though that would now be a natural
thing to do since it can only be in the receiver position and
in the base of a ObjCPropertyRefExpr.
There are still several ugly areas handling super in the parser,
but this is definitely a step in the right direction.
llvm-svn: 100959
typo correction. However, now that the code has been factored out
of LookupMemberExpr, it can recurse to itself instead of to
LookupMemberExpr! Remove grossness.
llvm-svn: 100958
pointer to an objc interface out to a method in SemaExprObjC.
This is *much* uglier than it should be due to grossness in
LookupMemberExpr :(
llvm-svn: 100957
we don't have enough information to tell them how to use 'strncmp'. Instead, change the
diagnostic to indicate they should use 'strncmp'.
llvm-svn: 100890
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
isn't any extra work to perform. Also, don't check for unused
parameters when the warnings will be suppressed anyway. Improves
performance of -fsyntax-only on 403.gcc's combine.c by ~2.5%.
<rdar://problem/7836787>
llvm-svn: 100686
that protected members be used on objects of types which derive from the
naming class of the lookup. My first N attempts at this were poorly-founded,
largely because the standard is very badly worded here.
llvm-svn: 100562
the underlying/instantiated decl) through a lot of API, including "intermediate"
MemberExprs required for (e.g.) template instantiation. This is necessary
because of the access semantics of member accesses to using declarations:
only the base class *containing the using decl* need be accessible from the
naming class.
This allows us to complete an access-controlled selfhost, if there are no
recent regressions.
llvm-svn: 99936
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
llvm-svn: 99920
cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.
Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.
Fixes <rdar://problem/7806091>.
llvm-svn: 99849
entering a function or block definition, not on every single declaration.
Unfortunately we don't have previous-lookup results around when it's time
to make this decision, so we have to redo the lookup. The alternative is
to use delayed diagnostics.
llvm-svn: 99172
This object controls when the warnings are executed, allowing the client code
in Sema to selectively disable warnings as needed.
Centralizing the logic for analysis-based warnings allows us to optimize
when and how they are run.
Along the way, remove the redundant logic for the 'check fall-through' warning
for blocks; now the same logic is used for both blocks and functions.
llvm-svn: 99085
nested-name-specifier. For example, this allows member access in
diamond-shaped hierarchies like:
struct Base {
void Foo();
int Member;
};
struct D1 : public Base {};
struct D2 : public Base {};
struct Derived : public D1, public D2 { }
void Test(Derived d) {
d.Member = 17; // error: ambiguous cast from Derived to Base
d.D1::Member = 17; // error: okay, modify D1's Base's Member
}
Fixes PR5820 and <rdar://problem/7535045>. Also, eliminate some
redundancy between Sema::PerformObjectMemberConversion() and
Sema::PerformObjectArgumentInitialization() -- the latter now calls
the former.
llvm-svn: 97674
which has the label map, switch statement stack, etc. Previously, we
had a single set of maps in Sema (for the function) along with a stack
of block scopes. However, this lead to funky behavior with nested
functions, e.g., in the member functions of local classes.
The explicit-stack approach is far cleaner, and we retain a 1-element
cache so that we're not malloc/free'ing every time we enter a
function. Fixes PR6382.
Also, tweaked the unused-variable warning suppression logic to look at
errors within a given Scope rather than within a given function. The
prior code wasn't looking at the right number-of-errors count when
dealing with blocks, since the block's count would be deallocated
before we got to ActOnPopScope. This approach works with nested
blocks/functions, and gives tighter error recovery.
llvm-svn: 97518
a fixme and PR6451.
Only perform jump checking if the containing function has no errors,
and add the infrastructure needed to do this.
On the testcase in the PR, we produce:
t.cc:6:3: error: illegal goto into protected scope
goto later;
^
t.cc:7:5: note: jump bypasses variable initialization
X x;
^
llvm-svn: 97497
equality comparisons, and conditional operators, produce a composite
pointer type with the appropriate additional "const" qualifiers if the
pointer types would otherwise be incompatible. This is a small
extension (also present in GCC and EDG in a slightly different form)
that permits code like:
void** i; void const** j;
i == j;
with the following extwarn:
t.cpp:5:5: warning: comparison of distinct pointer types ('void **' and
'void const **') uses non-standard composite pointer type
'void const *const *' [-pedantic]
i == j;
~ ^ ~
Fixes PR6346, and I'll be filing a core issue about this with the C++
committee.
llvm-svn: 97177
CXXPseudoDestructorExpr.
Update template instantiation for pseudo-destructor expressions to use
this source information and to make use of
Sema::BuildPseudoDestructorExpr when the base expression is dependent
or refers to a scalar type.
llvm-svn: 97079
pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr
node directly. Currently, this only affects pseudo-destructor
expressions when they are parsed, but not after template
instantiation. That's coming next...
Improve parsing of pseudo-destructor-names. When parsing the
nested-name-specifier and we hit the sequence of tokens X :: ~, query
the actual module to determine whether X is a type-name (in which case
the X :: is part of the pseudo-destructor-name but not the
nested-name-specifier) or not (in which case the X :: is part of the
nested-name-specifier).
llvm-svn: 97058
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
llvm-svn: 96766
