- Added some handling of flags that become invalid when changing the conversion specifier.
- Changed fixit behavior to remove unnecessary length modifiers.
- Separated some tests out and added some comments.
modified:
lib/Analysis/PrintfFormatString.cpp
test/Sema/format-strings-fixit.c
llvm-svn: 105807
(but not their types; that's later).
NOTE: Right now, variables in the global namespace don't get mangled, even
though they're supposed to be. This is because the default mangler
implements the shouldMangleDeclName() method that tells clang not to mangle
them. This will be fixed in a later patch.
llvm-svn: 105805
- Refactored LengthModifier to be a class.
- Added toString methods in all member classes of FormatSpecifier.
- FixIt suggestions keep user specified flags unless incorrect.
Limitations:
- The suggestions are not conversion specifier sensitive. For example, if we have a 'pad with zeroes' flag, and the correction is a string conversion specifier, we do not remove the flag. Clang will warn us on the next compilation.
A test/Sema/format-strings-fixit.c
M include/clang/Analysis/Analyses/PrintfFormatString.h
M lib/Analysis/PrintfFormatString.cpp
M lib/Sema/SemaChecking.cpp
llvm-svn: 105680
being a subsequence of another standard conversion sequence. Instead
of requiring exact type equality for the second conversion step,
require type *similarity*, which is type equality with cv-qualifiers
removed at all levels. This appears to match the behavior of EDG and
VC++ (albeit not GCC), and feels more intuitive. Big thanks to John
for the line of reasoning that supports this change: since
cv-qualifiers are orthogonal to the second conversion step, we should
ignore them in the type comparison.
llvm-svn: 105678
- We actually pretend that we have two separate types for LLVM assembly/bitcode because we need to use the standard suffixes with LTO ('clang -O4 -c t.c' should generate 't.o').
It is now possible to do something like:
$ clang -emit-llvm -S t.c -o t.ll ... assorted other compile flags ...
$ clang -c t.ll -o t.o ... assorted other compile flags ...
and expect that the output will be almost* identical to:
$ clang -c t.c -o t.o ... assorted other compile flags ...
because all the target settings (default CPU, target features, etc.) will all be initialized properly by the driver/frontend.
*: This isn't perfect yet, because in practice we will end up running the optimization passes twice. It's possible to get something equivalent out with a well placed -mllvm -disable-llvm-optzns, but I'm still thinking about the cleanest way to solve this problem more generally.
llvm-svn: 105584
- This magically enables using 'clang -cc1' as a replacement for most of 'llvm-as', 'llvm-dis', 'llc' and 'opt' functionality.
For example, 'llvm-as' is:
$ clang -cc1 -emit-llvm-bc FOO.ll -o FOO.bc
and 'llvm-dis' is:
$ clang -cc1 -emit-llvm FOO.bc -o -
and 'opt' is, e.g.:
$ clang -cc1 -emit-llvm -O3 -o FOO.opt.ll FOO.ll
and 'llc' is, e.g.:
$ clang -cc1 -S -o - FOO.ll
The nice thing about using the backend tools this way is that they are guaranteed to exactly match how the compiler generates code (for example, setting the same backend options).
llvm-svn: 105583
a member template, and you try to call the member template with an explicit
template argument. See PR7247
For example, this downgrades the error to a warning in:
template<typename T> struct set{};
struct Value {
template<typename T>
void set(T value) {
}
};
void foo() {
Value v;
v.set<double>(3.2); // Warning here.
}
llvm-svn: 105518
added as the last output step, instead of just hacking it into the link step.
- Among other things, this fixes dSYM generation when using multiple -arch options.
llvm-svn: 105475
a simple, quick check to determine whether the expression starting
with '[' can only be an Objective-C message send. If so, don't parse
it as an array subscript expression. This improves recovery for, e.g.,
[a method1]
[a method2]
so that we now produce
t.m:10:13: error: expected ';' after expression
[a method]
^
instead of some mess about expecting ']'.
llvm-svn: 105221
RegionStoreManager::RetrieveElement() that handles indexing into a larger scalar
object to only consult the direct binding of a super region if it is a scalar.
This isn't perfect yet, and a big FIXME is attached to the code. This causes
the test case for PR 7218 now to pass.
llvm-svn: 105195
isn't possible to compute.
This patch is mostly refactoring; the key change is the addition of the code
starting with the comment, "Check whether the function has a computable LLVM
signature." The solution here is essentially the same as the way the
vtable code handles such functions.
llvm-svn: 105151
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
llvm-svn: 105128
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
llvm-svn: 104941
Flag synthesized struct decl. as non-empty so
CXX side of ir gen does not skip its Null initialization.
Fixes radar 8027844 for objc++'s collection statement.
llvm-svn: 104837
any arguments that are default-argument expressions. The can show up
when we have a new expression whose constructor arguments are not
type-dependent and whose allocated type is not dependent and has a
constructor with default arguments. Fixes PR7202.
llvm-svn: 104690
diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.
llvm-svn: 104684
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
variables should have that linkage. Otherwise, its static local
variables should have internal linkage. To avoid computing this excessively,
set a function's linkage before we emit code for it.
Previously we were assigning weak linkage to the static variables of
static inline functions in C++, with predictably terrible results. This
fixes that and also gives better linkage than 'weak' when merging is required.
llvm-svn: 104581
- I think this can be cleaned up, since this means we may notify the consumer about the vtable twice, but I didn't see an easy fix for this without more substantial refactoring.
- Doug, please review!
llvm-svn: 104577
This works around a crash where malloc reused the memory of an erased BB for a
new BB leaving old cleanup information pointing at the new block.
llvm-svn: 104472
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
llvm-svn: 104471
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
llvm-svn: 104443
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
'-fasm' and explicitly map from that flag to -fgnu-keywords in the driver. Turn
off the driver in the lexer test for this madness and add a test to the driver
that the translation actually works.
llvm-svn: 104428
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
llvm-svn: 104409
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
not make copies non-POD arguments or arguments passed by reference:
just copy the pointers directly. This eliminates another source of the
dreaded memcpy-of-non-PODs. Fixes PR7188.
llvm-svn: 104327
'self' variable arising from uses of the 'super' keyword. Also reorganize
some code so that BlockInfo (now CGBlockInfo) can be opaque outside of
CGBlocks.cpp.
Fixes rdar://problem/8010633.
llvm-svn: 104312
sure that the anonymous struct/union record declaration gets
instantiated before the variable declaration, and that it and its
fields (recursively) get entries in the local instantiation map. Fixes
PR7088.
llvm-svn: 104305
matching G++'s behavior.
Warn when -pedantic or -Wc++-hex-floats is passed, and
don't warn if -pedantic -Wno-c++-hex-floats are both passed.
llvm-svn: 104295
recursively, e.g. so that members of anonymous unions inside anonymous structs
still get initialized. Also generate default constructor calls for anonymous
struct members when necessary.
llvm-svn: 104292
subobject. Previously, we could only properly bind to a base class
subobject while extending the lifetime of the complete object (of a
derived type); for non-static data member subobjects, we could memcpy
(!) the result and bind to that, which is rather broken.
Now, we pull apart the expression that we're binding to, to figure out
which subobject we're accessing, then construct the temporary object
(adding a destruction if needed) and, finally, dig out the subobject
we actually meant to access.
This fixes yet another instance where we were memcpy'ing rather than
doing the right thing. However, note the FIXME in references.cpp:
there's more work to be done for binding to subobjects, since the AST
is incorrectly modeling some member accesses in base classes as
lvalues when they are really rvalues.
llvm-svn: 104219
class type (that uses a return slot), pass the return slot to the
callee directly rather than allocating new storage and trying to copy
the object. This appears to have been the cause of the remaining two
Boost.Interprocess failures.
llvm-svn: 104215
instance variables:
- Use isRecordType() rather than isa<RecordType>(), so that we see
through typedefs in ivar types.
- Mark the destructor as referenced
- Perform C++ access control on the destructor
llvm-svn: 104206
create a temporary copy of both the "true" and "false" results. Fixes
the Boost.Interprocess failures.
Daniel did all the hard work of tracking down the issue, I get to type
up the trivial fix for this horrible miscompile.
llvm-svn: 104184
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
involves extending implicit conversion sequences to model vector
conversions and vector splats, along with teaching the C++ conditional
operator-checking code about vector types.
Fixes <rdar://problem/7983501>.
llvm-svn: 104081
design limitation in how we handle Objective-C class extensions. This was causing the CursorVisitor
to essentially visit an @property twice (once in the @interface, the other in the class extension).
Fixes <rdar://problem/7410145>.
llvm-svn: 104055
non-function-local declarations with names similar to what the user
typed. For example, this allows us to correct 'supper' to 'super' in
an Objective-C message send, even though the C function 'isupper' has
the same edit distance.
llvm-svn: 104023
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
Revert much of the implementation of C++98/03 [temp.friend]p5 in
r103943 and its follow-ons r103948 and r103952. While our
implementation was technically correct, other compilers don't seem to
implement this paragraph (which forces the instantiation of friend
functions defined in a class template when a class template
specialization is instantiated), and doing so broke a bunch of Boost
libraries.
Since this behavior has changed in C++0x (which instantiates the
friend function definitions when they are used), we're going to skip
the nowhere-implemented C++98/03 semantics and go straight to the
C++0x semantics.
This commit is a band-aid to get Boost up and running again. It
doesn't really fix PR6952 (which this commit un-fixes), but it does
deal with the way Boost.Units abuses this particular paragraph.
llvm-svn: 104014
make it miss (invalid) things like:
<<<<<<<
>>>>>>>
and crash if
<<<<<<<
was at the end of the line. When we find a >>>>>>> that is not at the
end of the line, make sure to reset Pos so we don't crash on something
like:
<<<<<<< >>>>>>>
This isn't worth making testcases for, since each would require a new file.
rdar://7987078 - signal 11 compiling "<<<<<<<<<<"
llvm-svn: 103968
within class templates be instantiated along with each class template
specialization, even if the functions are not used. Do so, as a baby
step toward PR6952.
llvm-svn: 103943
initializer, don't fold paramters. Their initializers are just default
arguments which can be overridden. This fixes some spectacular regressions due
to more things making it into the constant folding.
llvm-svn: 103904
__cxa_guard_abort along the exceptional edge into (in effect) a nested
"try" that rethrows after aborting. Fixes PR7144 and the remaining
Boost.ProgramOptions failures, along with the regressions that r103880
caused.
The crucial difference between this and r103880 is that we now follow
LLVM's little dance with the llvm.eh.exception and llvm.eh.selector
calls, then use _Unwind_Resume_or_Rethrow to rethrow.
llvm-svn: 103892
__cxa_guard_abort along the exceptional edge into (in effect) a nested
"try" that rethrows after aborting. Fixes PR7144 and the remaining
Boost.ProgramOptions failures.
llvm-svn: 103880
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
return statements. We perform NRVO only when all of the return
statements in the function return the same variable. Fixes some link
failures in Boost.Interprocess (which is relying on NRVO), and
probably improves performance for some C++ applications.
llvm-svn: 103867
throw, it should use invoke when needed. The fixes the
Boost.Statechrt failures that motivated PR7132, but there are a few
side issues to tackle as well.
llvm-svn: 103803
user directive is needed to force a property implementation.
It is decided based on those propeties which are declared in
the class (or in its protocols) but not those which must be
default implemented by one of its super classes. Implements radar 7923851.
llvm-svn: 103787
declarator is incorrect. Not being a typename causes the parser to
dive down into the K&R identifier list handling stuff, which is almost
never the right thing to do.
Before:
r.c:3:17: error: expected ')'
void bar(intptr y);
^
r.c:3:9: note: to match this '('
void bar(intptr y);
^
r.c:3:10: error: a parameter list without types is only allowed in a function definition
void bar(intptr y);
^
After:
r.c:3:10: error: unknown type name 'intptr'; did you mean 'intptr_t'?
void bar(intptr y);
^~~~~~
intptr_t
r.c:1:13: note: 'intptr_t' declared here
typedef int intptr_t;
^
This fixes rdar://7980651 - poor recovery for bad type in the first arg of a C function
llvm-svn: 103783
Argyrios Kyrtzidis