Adrian Prantl [Thu, 16 May 2013 00:41:29 +0000 (00:41 +0000)]
Set the debug location for landing pad code to the canonical EH location.
It used to point to the first call that caused the landing pad to
be generated.
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
Jordan Rose [Wed, 15 May 2013 23:22:55 +0000 (23:22 +0000)]
Remove unused, awkward CFGStmtVisitor and subclasses.
This class is a StmtVisitor that distinguishes between block-level and
non-block-level statements in a CFG. However, it does so using a hard-coded
idea of which statements might be block-level, which probably isn't accurate
anymore. The only implementer of the CFGStmtVisitor hierarchy was the
analyzer's DeadStoresChecker, and the analyzer creates a linearized CFG
anyway (every non-trivial statement is a block-level statement).
This also allows us to remove the block-expr map ("BlkExprMap"), which
mapped statements to positions in the CFG. Apart from having a helper type
that really should have just been Optional<unsigned>, it was only being
used to ask /if/ a particular expression was block-level, for traversal
purposes in CFGStmtVisitor.
Jordan Rose [Wed, 15 May 2013 18:08:15 +0000 (18:08 +0000)]
[analyzer] Put back DefaultBool's implicit conversion to bool.
DefaultBool is basically just "bool with a default constructor", so it
really should implicitly convert to bool. In fact, it should convert to
bool&, so that it could be passed to functions that take bools by reference.
This time, mark the operator bool& as implicit to promise that it's
deliberate.
Rationale:
a) Having anything other than forward declaration on the same line
as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
does not affect readability.
Hans Wennborg [Wed, 15 May 2013 11:03:04 +0000 (11:03 +0000)]
Better diagnostics for string initialization.
This commit improves Clang's diagnostics for string initialization.
Where it would previously say:
/tmp/a.c:3:9: error: array initializer must be an initializer list
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
char t[] = L"Hi";
^
Daniel Jasper [Wed, 15 May 2013 07:51:51 +0000 (07:51 +0000)]
Improve formatting of function types.
The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.
Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After: #define DEREF_AND_CALL_F(parameter) f(*parameter)
David Blaikie [Wed, 15 May 2013 07:37:26 +0000 (07:37 +0000)]
Use only explicit bool conversion operator
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
Jim Grosbach [Wed, 15 May 2013 02:40:04 +0000 (02:40 +0000)]
ARM: Improve codegen for vget_low_* and vget_high_ intrinsics.
These intrinsics use the __builtin_shuffle() function to extract the
low and high half, respectively, of a 128-bit NEON vector. Currently,
they're defined to use bitcasts to simplify the emitter, so we get code
like:
uint16x4_t vget_low_u32(uint16x8_t __a) {
return (uint32x2_t) __builtin_shufflevector((int64x2_t) __a,
(int64x2_t) __a,
0);
}
While this works, it results in those bitcasts going all the way through
to the IR, resulting in code like:
%1 = bitcast <8 x i16> %in to <2 x i64>
%2 = shufflevector <2 x i64> %1, <2 x i64> undef, <1 x i32>
%zeroinitializer
%3 = bitcast <1 x i64> %2 to <4 x i16>
We can instead easily perform the operation directly on the input vector
like:
Objective-C [diagnostics] [QOI], when method is not
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
Richard Trieu [Tue, 14 May 2013 21:59:17 +0000 (21:59 +0000)]
When computing the size of large arrays, use char units instead of bits.
This prevents an overflow and assertion when the number of bits cannot be
stored in 64-bits.
David Blaikie [Tue, 14 May 2013 21:04:00 +0000 (21:04 +0000)]
Provide operator<< for stream output of DeclarationNames
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
Reid Kleckner [Tue, 14 May 2013 20:30:42 +0000 (20:30 +0000)]
[ms-cxxabi] Mangle in an implicit 'E' for certain types on win64
Most of the complexity of this patch is figuring out which types get the
qualifier and which don't. If we implement __ptr32/64, then we should
check the qualifier instead of assuming all pointers are 64-bit.
Daniel Jasper [Tue, 14 May 2013 10:31:09 +0000 (10:31 +0000)]
Correctly determine ranges for clang-format.
We have been assuming that CharSourceRange::getTokenRange() by itself
expands a range until the end of a token, but in fact it only sets
IsTokenRange to true. Thus, we have so far only considered the first
character of the last token to belong to an unwrapped line. This
did not really manifest in symptoms as all edit integrations
expand ranges to fully lines.
Daniel Jasper [Tue, 14 May 2013 09:30:02 +0000 (09:30 +0000)]
Fix clang-format bug in unwrapped-line merging.
Before (in styles that allow it), clang-format would not merge an
if statement onto a single line, if only the second line was format
(e.g. in an editor integration):
if (a)
return; // clang-format invoked on this line.
Manuel Klimek [Tue, 14 May 2013 09:13:00 +0000 (09:13 +0000)]
First revision of the dynamic ASTMatcher library.
This library supports all the features of the compile-time based ASTMatcher
library, but allows the user to specify and construct the matchers at runtime.
It contains the following modules:
- A variant type, to be used by the matcher factory.
- A registry, where the matchers are indexed by name and have a factory method
with a generic signature.
- A simple matcher expression parser, that can be used to convert a matcher
expression string into actual matchers that can be used with the AST at
runtime.
Many features where omitted from this first revision to simplify this code
review. The main ideas are still represented in this change and it already has
support working use cases.
Things that are missing:
- Support for polymorphic matchers. These requires supporting code in the
registry, the marshallers and the variant type.
- Support for numbers, char and bool arguments to the matchers. This requires
supporting code in the parser and the variant type.
- A command line program putting everything together and providing an already
functional tool.
Manuel Klimek [Tue, 14 May 2013 09:04:24 +0000 (09:04 +0000)]
Implement string literal breaking on unbreakable token sequences.
This fixes indentation where there are for example multiple closing
parentheses after a string literal, and where those parentheses
run over the end of the line.
During testing this revealed a bug in the implementation of
breakProtrudingToken: we don't want to change the state if we didn't
actually do anything.
Tim Northover [Tue, 14 May 2013 08:26:14 +0000 (08:26 +0000)]
AArch64: correct definition of __clear_cache
According to libgcc document __clear_cache takes two char*
pointers. I suspect GCC's actual behaviour is more subtle than that,
but char* should clearly be preferred to void*.
Objective-C error recovery. This patch makes a quick
recovery form duplicate method definition error thus
preventing doc parsing to loop trying to find comment
for the invalid redefinition in a previous declaration.
// rdar://13836387
Richard Smith [Sun, 12 May 2013 23:39:32 +0000 (23:39 +0000)]
Downgrade C++14 "Clarifying memory allocation". We perform non-conforming
optimizations -- in particular, globalopt will remove calls to ::operator
new(size_t) that did not come from new-expressions.
Richard Smith [Sun, 12 May 2013 23:17:59 +0000 (23:17 +0000)]
Fix stack overflow in linkage computation when a function with a deduced return
type returns a lambda defined within itself. The computation of linkage for the
function looked at the linkage of the lambda, and vice versa.
This is solved by not checking whether an 'auto' in a function return type
deduces to a type with unique external linkage. We don't need this check,
because the type deduced for 'auto' doesn't affect whether two
otherwise-identical declarations would name different functions, so we don't
need to give an ostensibly external-linkage function internal linkage for this
reason. (We also don't need unique-external linkage in C++11 onwards at all,
but that's not implemented yet.)
Richard Smith [Sun, 12 May 2013 17:32:42 +0000 (17:32 +0000)]
C++1y: support for 'switch' statements in constexpr functions. This is somewhat
inefficient; we perform a linear scan of switch labels to find the one matching
the condition, and then walk the body looking for that label. Both parts should
be straightforward to optimize.
Richard Smith [Sat, 11 May 2013 05:45:24 +0000 (05:45 +0000)]
C++1y deduced return types: when we deduce a return type for a function which
we loaded from PCH, if we're building another PCH, create an update record to
patch the return type of the earlier declaration.
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
Douglas Gregor [Fri, 10 May 2013 22:15:13 +0000 (22:15 +0000)]
[Modules] When things go horribly wrong when reading a module, point at the module cache.
Sometimes people hack on their system headers. In such cases, they'll
need to delete their module cache, but may not know where it is. Add a
note to show them where it is.
David Blaikie [Fri, 10 May 2013 21:53:14 +0000 (21:53 +0000)]
PR14992: Debug Info: Support more non-type template parameters
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
In this case, when we call systemFunction, we know (because it's a system
function) that it won't free 'p'. However, we /don't/ know whether or not
it will /change/ 'p', so the analyzer is forced to invalidate 'p', wiping
out any bindings it contains. But now the malloc'd region looks like a
leak, since there are no more bindings pointing to it, and we'll get a
spurious leak warning.
The fix for this is to notice when something is becoming inaccessible due
to invalidation (i.e. an imperfect model, as opposed to being explicitly
overwritten) and stop tracking it at that point. Currently, the best way
to determine this for a call is the "indirect escape" pointer-escape kind.
In practice, all the patch does is take the "system functions don't free
memory" special case and limit it to direct parameters, i.e. just the
arguments to a call and not other regions accessible to them. This is a
conservative change that should only cause us to escape regions more
eagerly, which means fewer leak warnings.
This isn't perfect for several reasons, the main one being that this
example is treated the same as the one above:
Currently, "addresses accessible by offsets of the starting region" and
"addresses accessible through bindings of the starting region" are both
considered "indirect" regions, hence this uniform treatment.
Another issue is our longstanding problem of not distinguishing const and
non-const bindings; if in the first example systemFunction's parameter were
a char * const *, we should know that the function will not overwrite 'p',
and thus we can safely report the leak.
projects / clang / log