- This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.
- Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.
- Review appreciated.
llvm-svn: 102045
in a throw expression. Use EmitAnyExprToMem to emit the throw expression,
which magically elides the final copy-constructor call (which raises a new
strict-compliance bug, but baby steps). Give __cxa_throw a destructor pointer
if the exception type has a non-trivial destructor.
llvm-svn: 102039
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
during message sends) over to the new initialization code and away
from the C-only CheckSingleAssignmentConstraints. The enables the use
of C++ types in method parameters and message arguments, as well as
unifying more initialiation code overall.
llvm-svn: 102035
Objective-C++ have a more complex grammar than in Objective-C
(surprise!), because
(1) The receiver of an instance message can be a qualified name such
as ::I or identity<I>::type.
(2) Expressions in C++ can start with a type.
The receiver grammar isn't actually ambiguous; it just takes a bit of
work to parse past the type before deciding whether we have a type or
expression. We do this in two places within the grammar: once for
message sends and once when we're determining whether a []'d clause in
an initializer list is a message send or a C99 designated initializer.
This implementation of Objective-C++ message sends contains one known
extension beyond GCC's implementation, which is to permit a
typename-specifier as the receiver type for a class message, e.g.,
[typename compute_receiver_type<T>::type method];
Note that the same effect can be achieved in GCC by way of a typedef,
e.g.,
typedef typename computed_receiver_type<T>::type Computed;
[Computed method];
so this is merely a convenience.
Note also that message sends still cannot involve dependent types or
values.
llvm-svn: 102031
Objective-C class message expression into a type from the parser
(which was doing so in two places) to Action::getObjCMessageKind()
which, in the case of Sema, reduces the number of name lookups we need
to perform.
llvm-svn: 102026
sends. Major changes include:
- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.
Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in
Subversion.
llvm-svn: 102021
(if there's a current block). The chief advantage of doing this is that it
lets us pick blocks (e.g. EH blocks) to push to the end of the function so
that fallthrough happens consistently --- i.e. it gives us the flexibility
of ordering blocks as we please without having to change the order in which
we generate code. There are standard (?) optimization passes which can do some
of that for us, but better to generate reasonable code to begin with.
llvm-svn: 101997
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
about it instead of producing tons of garbage from the lexer.
It would be even better for sourcemgr to dynamically transcode (e.g.
from UTF16 -> UTF8).
llvm-svn: 101924
we will print with each error that occurs during template
instantiation. When the backtrace is longer than that, we will print
N/2 of the innermost backtrace entries and N/2 of the outermost
backtrace entries, then skip the middle entries with a note such as:
note: suppressed 2 template instantiation contexts; use
-ftemplate-backtrace-limit=N to change the number of template
instantiation entries shown
This should eliminate some excessively long backtraces that aren't
providing any value.
llvm-svn: 101882
This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525. There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.
llvm-svn: 101877
of buildbots with:
error: 'error' diagnostics expected but not seen:
Line 9: too few elements in vector initialization (expected 8 elements, have 2)
1 warning and 1 error generated.
llvm-svn: 101864
function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.
llvm-svn: 101826
look from an Objective-C class or category to its implementation, to
pick up synthesized ivars. Fixes a problem reported by David
Chisnall.
llvm-svn: 101792
a qualified name. We weren't checking for an empty
nested-name-specifier when dealing with friend class templates
(although we were checking in the other places where we deal with this
paragraph). Fixes a Boost.Serialization showstopper.
llvm-svn: 101724
different kinds (aka garbage). This happens if we're comparing a standard
conversion sequence to an ambiguous one which have the same KindRank.
Found by valgrind.
llvm-svn: 101717
resolution ([over.ics.ref]), we take some shortcuts required by the
standard that effectively permit binding of a const volatile reference
to an rvalue. We have to treat lightly here to avoid infinite
recursion.
Fixes PR6177.
llvm-svn: 101712
reference binding to an rvalue of reference-compatible type, check
parameters after the first for complete parameter types and build any
required default function arguments. We're effectively simulating the
type-checking for a call without building the call itself.
llvm-svn: 101705
reference-compatible type, the implementation is permitted to make a
copy of the rvalue (or many such copies, even). However, even though
we don't make that copy, we are required to check for the presence of
a suitable copy constructor. With this change, we do.
Note that in C++0x we are not allowed to make these copies, so we test
both dialects separately.
Also note the FIXME in one of the C++03 tests, where we are not
instantiating default function arguments for the copy constructor we
pick (but do not call). The fix is obvious; eliminating the infinite
recursion it causes is not. Will address that next.
llvm-svn: 101704
temporary object. This is blindingly obvious from reading C++
[over.match.ctor]p1, but somehow I'd missed it and it took DR152 to
educate me. Adjust one test that was relying on this non-standard
behavior.
llvm-svn: 101688
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing simpler
interfaces for checking implicit conversions:
- It eliminates a case of infinite recursion found in Boost.
- It eliminates the search for the constructor needed to copy a temporary
generated by an implicit conversion from overload
resolution. Overload resolution assumes that, if it gets a value
of the parameter's class type (or a derived class thereof), there
is a way to copy if... even if there isn't. We now model this
properly.
llvm-svn: 101680
implemented precisely the same as GCC, but the distinction GCC makes isn't
useful to represent. This allows parsing code which uses GCC-specific keywords
('asm', etc.) without parsing in a fully GNU mode.
llvm-svn: 101667
checking into a single function and use that throughout. Remove some
now unnecessary diagnostics and update tests with now more accurate
diagnostics.
llvm-svn: 101610
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
and we now include the file name that declares the symbol with no linkage in the USR.
USRs for such symbols are generated only in restructed cases, e.g., anonymous enum declarations,
typedefs, etc.
llvm-svn: 101542
struct may cause it to shrink more than one byte. Before
my recent changes we compiled the new test into:
%0 = type { [6 x i8] }
@x = global %0 { [6 x i8] undef }, align 2 ; <%0*> [#uses=0]
which is obviously bogus. Now we compile it into:
%0 = type <{ i32, i8, i8 }>
@x = global %0 zeroinitializer, align 2 ; <%0*> [#uses=0]
Where the last byte only is tail padding.
llvm-svn: 101536
functional casts over to InitializationSequence, eliminating a caller
of Sema::TryImplicitConversion. We also get access and ambiguity
checking "for free".
More cleanups to come in this routine.
llvm-svn: 101526
large files, this doesn't seem significantly better than just letting
raw_ostream pick a buffer size.
This code predates raw-ostream's automatic buffer sizing; in fact, it
was introduced as part of the code which would eventually become
raw_ostream.
llvm-svn: 101473
libCIndex also has a CMakeLists.txt file which has its own code for using
the exports file. To preserve existing functionality, create a separate
darwin-specific exports file for use by this CMakeLists.txt code.
llvm-svn: 101440
source line wider than the terminal where the associated fix-it line
is longer than the caret line. Previously, we would crash in this
case, which was rather unfortunate. Fixes <rdar://problem/7856226>.
llvm-svn: 101426
intended for redeclarations, fixing those that need it. Fixes PR6831.
This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).
llvm-svn: 101419
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
llvm-svn: 101412
case in GRExprEngine::Visit (in r101129). Instead, enumerate all Stmt cases and have
no 'default' case in the switch statement. When we encounter a Stmt we don't handle,
we should explicitly add it to the switch statement.
llvm-svn: 101378
ASTContext::getTypeSize() rather than ASTContext::getIntWidth() for
the width of an integral type. The former includes padding for bools
(to the target's size) while the latter does not, so we woud end up
zero-extending bools to the target width when we shouldn't. Fixes a
crash-on-valid in the included test.
llvm-svn: 101372
- Used to determine whether the alignment of the type in a bit-field is
respected when laying out structures. The default is true, targets can
override this as needed.
- This is designed to correspond to the PCC_BITFIELD_TYPE_MATTERS macro in
gcc. The AST/Sema implementation only affects one line, unless I have
forgotten something. I'd appreciate further review.
- IRgen still needs to be updated to fully support this (which is effectively
PR5591).
llvm-svn: 101356
- Note that this is a behavior change, previously -mllvm at the driver level forwarded to clang -cc1. The driver does a little magic to make sure that '-mllvm -disable-llvm-optzns' works correctly, but other users will need to be updated to use -Xclang.
llvm-svn: 101354
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
The new fixes from r101222 are:
1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.
2. Swap the order of arguments to OR, to get a tad more constant folding.
llvm-svn: 101339
Stop multiplying constant by 8 accordingly in the header and change
intrinsic definition for what types we expect.
Add to existing palignr test to check that we're emitting the correct things.
llvm-svn: 101332
containing the time taken for the code completion to be sent to a designated server
(which is specified using a compile-time -D flag).
llvm-svn: 101326
that have reference or const scalar members, since those members can
never be initializer or modified. Fixes <rdar://problem/7804350>.
llvm-svn: 101316
ResolveAddressOfOverloadedFunction when asked to complain. Previously,
we had some weird handshake where ResolveAddressOfOverloadedFunction
expected its caller to handle some of the diagnostics but not others,
and yet there was no way for the caller to know which case we were
in. Eliminate this madness, fixing <rdar://problem/7765884>.
llvm-svn: 101312
separate count of "suppressed" errors. This way, semantic analysis
bits that depend on the error count to determine whether problems
occured (e.g., some template argument deduction failures, jump-scope
checking) will not get confused.
The actual problem here is that a missing #include (which is a fatal
error) could cause the jump-scope checker to run on invalid code,
which it is not prepared to do. Trivial fix for both
<rdar://problem/7775941> and <rdar://problem/7775709>.
llvm-svn: 101297
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
than just a bool indicating that correction occurred. No actual
functionality change (it's still always used like a bool), but this
refactoring will be used to support typo correction to keywords.
llvm-svn: 101259
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
- Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.
- No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.
llvm-svn: 101222
receiver is a mis-typed class name. Previously, we would give a non-specific
typo-correction diagnostic from the expression-parsing code, but there
was no fix-it because it was too late to recover. Now, we give a nice
diagnostic
honk.m:6:4: error: unknown receiver 'Hnk'; did you mean 'Honk'?
[Hnk method];
^~~
Honk
honk.m:1:1: note: 'Honk' declared here
@interface Honk
^
which includes a fix-it.
We still need to recover better from mis-typing "super".
llvm-svn: 101211
super message sends in Objective-C. No actual functionality change
here, but it provides a hook so that Sema can typo-correct the
receiver in some cases.
llvm-svn: 101207
- This lets the method focus slightly more on emitting clean IR to honor the policy which has been selected. On 403.gcc's combine.c, x86_64, -O0, this reduces the number of lines in the .ll file (~= # of instructions) by 2.5%.
- No intended functionality change -- at -O3 this should produce equivalent if not identical output. On 403.gcc's combine.c, x86_64, -O3, this isn't quite true and some of the changes are regressions, but I'm not going to worry about that until we move to a new access policy.
- There is still some room for improvement in the generated IR, in particular we can usually fold the sign-extension of the bit-field into one of the component access. See the FIXME.
llvm-svn: 101192
- For now, these policies are computed to match the current IRgen strategy, although the new information isn't being used yet (except in -fdump-record-layouts).
- Design comments appreciated.
llvm-svn: 101178
elements with explicit zero values instead of with tail padding.
On an example like this:
struct foo { int a; int b; };
struct foo fooarray[] = {
{1, 2},
{4},
};
We now lay this out as:
@fooarray = global [2 x %struct.foo] [%struct.foo { i32 1, i32 2 }, %struct.foo { i32 4, i32 0 }]
instead of as:
@fooarray = global %0 <{ %struct.foo { i32 1, i32 2 }, %1 { i32 4, [4 x i8] zeroinitializer } }>
Preserving both the struct type of the second element, but also the array type of the entire thing.
llvm-svn: 101155
Without it, there is no reason for a compiler that supports it to
emit the dead static globals that the rewriter labels attribute(used).
llvm-svn: 101149
for reference binding. The code attempted to handle both the
computation of the ICS and the actual conversion, but the latter is an
anachronism: we now use InitializationSequence for that.
Sema::CheckReferenceInit is now a static function TryReferenceInit
that's only use within overload resolution, and has been simplified
slightly. It still needs to be updated per C++ [over.ics.ref], by
eliminating more of the lvalue/rvalue checks.
llvm-svn: 101136
from a conversion function template specialization to one of exact
match rank. We only know how to test this in C++0x with default
function template arguments, but it's also in the C++03 spec. Fixes
PR6285.
llvm-svn: 101089
copying the type location information from the conversion-type-id into
the type location information for the function type. Do something
similar for constructors and destructors, by giving their "void"
return type source-location information.
In all of these cases, we previously left this type-source information
uninitialized, which led to various unfortunate crashes.
We still aren't tracking good source-location information for the
actual names. That's PR6357.
John, please check my sanity on this.
llvm-svn: 101088
in an input file like this:
# 42
int x;
we were emitting:
# <something>
int x;
(with a space before the int) because we weren't clearing the leading
whitespace flag properly after the \n from the directive was handled.
llvm-svn: 101084
actually turned it on. If a diag is produced by a warning which
is an extension but defaults to on, and has no warning group, don't
print any option info.
llvm-svn: 101071
trailing fields may not be represented in initializer lists, they
are being handled as padding and those fields *must* be zero
initialized.
llvm-svn: 101067
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
sure to introduce them into the current Scope (when we have one) in
addition to the DeclContext for the class, so that they can be found
by name lookup for inline members of the class. Fixes PR6570.
llvm-svn: 101047
correctly diagnose instantiation of a function parameter with Objective-C
class type (since Objective-C classes can't be passed by value).
llvm-svn: 101031
function's type is (strictly speaking) non-dependent. This ensures
that, e.g., default function arguments get instantiated properly.
And, since I couldn't resist, collapse the two implementations of
function-parameter instantiation into calls to a single, new function
(Sema::SubstParmVarDecl), since the two had nearly identical code (and
each had bugs the other didn't!). More importantly, factored out the
semantic analysis of a parameter declaration into
Sema::CheckParameter, which is called both by
Sema::ActOnParamDeclarator (when parameters are parsed) and when a
parameter is instantiated. Previously, we were missing some
Objective-C and address-space checks on instantiated function
parameters.
Fixes PR6733.
llvm-svn: 101029
Daniel Dunbar