might be wider than we're supposed to print. In this case, we try to
select the "important" subregion of the source line, which contains
everything that we want to show (e.g., with underlining and the caret
itself) and tries to also contain some of the context.
From the fantastically long line in the test case, we get an error
message that slices down to this:
message-length.c:18:120: warning: comparison of distinct pointer types
('int *' and 'float *')
a_func_to_call(ip == FloatPointer, ip[ALongIndexName],
~~ ^ ~~~~~~~~~~~~
There are a bunch of gee-it-sounds-good heuristics in here, which seem
to do well on the various simple tests I've thrown at it. However,
we're going to need to look at a bunch more diagnostics to tweak these
heuristics.
This is the second part of <rdar://problem/6711348>. Almost there!
llvm-svn: 70597
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
llvm-svn: 70578
- Don't layer TypedViewRegions on top of any region except
SymbolicRegions and AllocaRegions. This follows from my offline
discussion within Zhongxing about how TypedViewRegions really only
represent memory getting re-appropriated for a new purpose.
Fallout from this change:
- Move test case from xfail_rdar_6440393.m to misc-ps-64.m
(it now passes).
- test/Analysis/fields.c now fails for region store (crash).
Marking XFAIL.
- test/Analysis/rdar-6441136-region.c now fails (only runs with region store).
Marking XFAIL.
Diagnosis: The analyzer now correctly identifies an early out-of-bounds memory
access then the one flagged:
rdar-6541136-region.c:17:3: warning: Load or store into an out-of-bound memory position.
*p = 1;
^~
Changing the line:
char *p = (void*) &wonky[1];
to
char *p = (void*) &wonky[0];
(which should delay the buffer overrun) causes region store to crash, probably
because it expects a TypedViewRegion.
- test/Analysis/casts.c (region store) now fails (crash).
Marking XFAIL.
llvm-svn: 70565
location context. This allows us to postpone the decision of whether
or not a context should add a control-flow piece to the diagnostics
when inspecting its subexpressions.
llvm-svn: 70545
applied to ObjCMethodDecls, not just parameters. This allows one to specific
side-effects on the receiver of a message expression. No checker support yet.
llvm-svn: 70505
appear between the return type and the selector. This is a separate code path
from regular attribute processing, as we only want to (a) accept only a specific
set of attributes in this place and (b) want to distinguish to clients the
context in which an attribute was added to an ObjCMethodDecl.
Currently, the attribute 'objc_ownership_returns' is the only attribute that
uses this new feature. Shortly I will add a warning for 'objc_ownership_returns'
to be placed at the end of a method declaration.
llvm-svn: 70504
"aligned" attribute. Previously, we were skipping over these
attributes when we jumped directly to the canonical type. Now,
ASTContext::getTypeInfo walks through typedefs and other
"non-canonical" types manually, looking for "aligned" attributes on
typedefs.
As part of this change, I moved the GNU-specific logic (such as
determining the alignment of void or of a function pointer) out of the
expression evaluator and into ASTContext::getTypeInfo.
llvm-svn: 70497
This fixes <rdar://problem/6839489> 10A345: Clang does not warm about mismatched returns (void return from a bool function)
Will implement -Wreturn-type, -Wno-return-type in another commit.
llvm-svn: 70492
compatible with VC++ and GCC. The codegen/mangling angle hasn't
been fully ironed out yet. Note that we accept int128_t even in
32-bit mode, unlike gcc.
llvm-svn: 70464
- Add an (optional) short description for BugReports for clients that want
to distinguish between long and short descriptions for bugs
- Make the bug report for VLA less obscene for Plist diagnostics by using
the short description
llvm-svn: 70415
type and argument types are missing, and let return type deduction
happen before we give errors for returning from a noreturn block.
Radar 6441502
llvm-svn: 70413
reasoning about OSCompareAndSwap32Barrier/OSCompareAndSwap64Barrier. Essentially
the address of reference to a region (pointer-to-pointer) can be casted to
(int32_t*), and we need to handle the logic to convert the involved locations
back and forth from nonloc::LocAsInteger, nonloc::ConcreteInt, to Loc and
loc::ConcreteInt respectively. This adds some potentially suspect logic to
BasicStoreManager that allows the analyzer to reason about abuses of the C type
system. This should probably be refined, be ported over to RegionStoreManager,
and extended with "path-sensitive type checking" to flag bugs in clearly
incoherent code.
llvm-svn: 70382
1. In a struct field redefinition, don't mark the struct erroneous. The
field is erroneous, but the struct is otherwise well formed.
2. Don't emit diagnostics about functions that are known to be broken already.
Either fix is sufficient to silence the second diagnostic in the example,
but the combination is better :)
llvm-svn: 70371
1. All all variants of -Wformat*, make them imply -Wformat. GCC warns
if you use -Wformatfoo without -Wformat. We just make one imply the
other.
2. Make -Wformat-nonliteral default to off, like gcc. It is an incredible
nuisance.
3. Accept but currently ignore -Wformat-extra-args.
llvm-svn: 70362
- Mirroring LLVM's docs/CommandGuide, a place to put .pod files which
are used to generate man/html/etc documentation for tools provided
as part of clang.
llvm-svn: 70355
which eliminates the storage for IdentifierInfo in the "uninteresting
identifier" cases. Sadly, this only brought back 7k of the 500k we
lost :(
llvm-svn: 70325
line when using a PCH that were not provided when building the PCH
file. If those names were used as identifiers somewhere in the PCH
file, reject the PCH file.
llvm-svn: 70321
for identifiers to separate "interesting" from "uninteresting"
identifiers. However, to cope with compiler invocations where the
predefines buffers mismatch, we need to be able to search the complete
identifier table. Cocoa.h.pch is now about 500k larger that it used to
be :(
llvm-svn: 70320
PCH file and the predefines buffer used when including the PCH
file. We (explicitly) detect conflicting macro definitions (rejecting
the PCH file) and about missing macro definitions (they'll be
automatically pulled from the PCH file anyway).
We're missing some checking to make sure that new macro definitions
won't have any impact on the PCH file itself (e.g., #define'ing an
identifier that the PCH file used).
llvm-svn: 70316
"function designator".
(This causes a minor glitch in the
diagnostics for C++ member pointers, but we weren't printing the
right diagnostic there anyway.)
llvm-svn: 70307
frontend is far enough along that most discrepancies between Clang and GCC are
(at least for C and Objective-C) are intentional. We also now have codegen to
test the frontend.
llvm-svn: 70303
mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.
As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.
llvm-svn: 70292
scheme to be more useful.
The new scheme introduces a set of categories that should be more
readable, and also reflects what we want to consider as an extension
more accurately. Specifically, it makes the "what is a keyword"
determination accurately reflect whether the keyword is a GNU or
Microsoft extension.
I also introduced separate flags for keyword aliases; this is useful
because the classification of the aliases is mostly unrelated to the
classification of the original keyword.
This patch treats anything that's in the implementation
namespace (prefixed with "__", or "_X" where "X" is any upper-case
letter) as a keyword without marking it as an extension. This is
consistent with the standards in that an implementation is allowed to define
arbitrary extensions in the implementation namespace without violating
the standard. This gets rid of all the nasty "extension used" warnings
for stuff like __attribute__ in -pedantic mode. We still warn for
extensions outside of the the implementation namespace, like typeof.
If someone wants to implement -Wextensions or something like that, we
could add additional information to the keyword table.
This also removes processing for the unused "Boolean" language option;
such an extension isn't supported on any other C implementation, so I
don't see any point to adding it.
The changes to test/CodeGen/inline.c are required because previously, we
weren't actually disabling the "inline" keyword in -std=c89 mode.
I'll remove Boolean and NoExtensions from LangOptions in a follow-up
commit.
llvm-svn: 70281
- Add 'LoopTarget' pointer field to CFGBlock. This records if the block is used
as the 'loop back' path back to the head of a loop.
- For ForStmt, encode the loop back target as the increment code.
llvm-svn: 70274
that if we're going to print an extension warning anyway,
there's no point to changing behavior based on NoExtensions: it will
only make error recovery worse.
Note that this doesn't cause any behavior change because NoExtensions
isn't used by the current front-end. I'm still considering what to do about
the remaining use of NoExtensions in IdentifierTable.cpp.
llvm-svn: 70273
Clang version value rather than hard-coding "1.0".
Add PCH and Clang version information into the PCH file. Reject PCH
files with the wrong version information.
llvm-svn: 70264
essentially the same thing we do with pretokenized headers. stat()
caching improves performance of the Cocoa-prefixed "Hello, World" by
45%.
llvm-svn: 70223
as 'objc_ownership_cfretain' except that the method acts like a CFRetain instead
of a [... retain] (important in GC modes). Checker support is wired up, but
currently only for Objective-C message expressions (not function calls).
llvm-svn: 70218
parm var decls in leopard cocoa.h end up using this abbreviation,
which shrinks the bitcode file by about 50K: 7217736->7167120.
Before:
Block ID #12 (DECLS_BLOCK):
Num Instances: 1
Total Size: 2.23595e+07b/2.79494e+06B/698736W
% of file: 38.7233
Num SubBlocks: 0
Num Abbrevs: 0
Num Records: 139387
% Abbrev Recs: 0
After:
Block ID #12 (DECLS_BLOCK):
Num Instances: 1
Total Size: 2.02405e+07b/2.53006e+06B/632516W
% of file: 35.301
Num SubBlocks: 0
Num Abbrevs: 1
Num Records: 139387
% Abbrev Recs: 19.2902
llvm-svn: 70199
file. In particular, only eagerly load source location entries for
files and for the predefines buffer. Other buffers and
macro-instantiation source location entries are loaded lazily.
With the Cocoa-prefixed "Hello, World", we only load 815/26555 source
location entities. This halves the amount of user time we spend in
this "Hello, World" program with -fsyntax-only (down to .007s).
This optimization is part 1 of 2 for the source manager. This
eliminates most of the user time in loading a PCH file. We still spend
too much time initialize File structures (especially in the calls to
stat), so we need to either make the loading of source location
entries for files lazy or import the stat cache from the PTH
implementation.
llvm-svn: 70196
before r69391: typedef redefinition is an error by default, but if
*either* the old or new definition are from a system header, we silence
it.
llvm-svn: 70177
eventually get an option to turn this off, but it is nice for looking at
statistics. For example, the types block now prints:
Block ID #11 (TYPES_BLOCK_ID):
Num Instances: 1
Total Size: 895100b/111888B/27971.9W
% of file: 1.55801
Num SubBlocks: 0
Num Abbrevs: 0
Num Records: 14899
% Abbrev Recs: 0
Code Histogram:
5478 TYPE_FUNCTION_PROTO
2683 TYPE_TYPEDEF
2460 TYPE_POINTER
2047 TYPE_ENUM
1553 TYPE_RECORD
283 TYPE_CONSTANT_ARRAY
274 TYPE_OBJC_INTERFACE
76 TYPE_INCOMPLETE_ARRAY
10 TYPE_VECTOR
9 TYPE_OBJC_QUALIFIED_ID
5 TYPE_FUNCTION_NO_PROTO
5 TYPE_EXT_QUAL
3 TYPE_TYPEOF_EXPR
llvm-svn: 70166
- Deal with the Receiver/ClassInfo shared storage in ObjCMessageExpr
- Implement PCH support for ImplicitParamDecl
- Fix the handling of the body of an ObjCMethodDecl
- Several cast -> cast_or_null fixes
- Make Selector::getIdentifierInfoForSlot work for 1-argument, NULL
selectors.
- Make Selector::getAsString() work with NULL selectors.
- Fix the names of VisitObjCAtCatchStmt and VisitObjCAtFinallyStmt
in the PCH reader and writer; these were never getting called.
At this point, all of the pch-test tests pass for C and Objective-C.
llvm-svn: 70163
offsetof correctly in the presence of anonymous structs/unions.
This could definitely use some cleanup, but I don't really want to mess
with the anonymous union/struct code.
llvm-svn: 70156
Before we emitted:
$ clang t.c -S -m64
llvm: error: Unsupported asm: input constraint with a matching output constraint of incompatible type!
Now we produce:
$ clang t.c -S -m64
t.c:5:40: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'int'
asm volatile("foo " : "=a" (a) :"0" (b));
~~~ ~^~
llvm-svn: 70142
dump their contents for all of the compilable tests in Clang's
testsuite. All of the tests pass for C, but there are still many
failures for Objective-C.
llvm-svn: 70110
necessary and iterate until all types and declarations have been
written. This reduces the Cocoa.h PCH file size by about 4% (since we
don't write types we don't need), and fixes problems where writing a
declaration generates a new type.
This doesn't seem to have any impact on performance either way.
llvm-svn: 70109
declaration rather than printing through the HandleTopLevelDecl
action. Using this, one can deserialize an entire PCH file and dump
it.
llvm-svn: 70108
- This can be used to supply a default value for -std=; the idea is
that this can be used in conjunction with CCC_ADD_ARGS or
QA_OVERRIDE_GCC3_OPTIONS to change the default without having to
modify the build system.
llvm-svn: 70102
most of which are ignored. Instead, move the __COUNTER__ value out to
a PCH-level record (since it is handled eagerly) and move the header
file information into the SourceManager block (which is also,
currently, loaded eagerly).
This results in another 17% performance improvement in the
Cocoa-prefixed "Hello, World" with PCH.
llvm-svn: 70097
PCH file. In the Cocoa-prefixed "Hello, World" benchmark, this takes
us from reading 503 identifiers down to 37 and from 470 macros down to
4. It also results in an 8% performance improvement.
llvm-svn: 70094
Overall, I'm not particularly happy with the current situation regarding
constant expression diagnostics, but I plan to improve it at some point.
llvm-svn: 70089
VerifyIntegerConstantExpression instead of isIntegerConstantExpr.
This makes it ext-warn but tolerate things that fold to a constant
but that are not valid i-c-e's.
There must be a bug in the i-c-e computation though, because it
doesn't catch this case even with pedantic.
This also switches the later code to use EvaluateAsInt which is
simpler and handles everything that evaluate does.
llvm-svn: 70081
identifier's ID. In this case, we know where the identifier's entry is
located in the hash table (it starts right before the identifier
string itself), so skip the hash table lookup and read the entry
directly. The performance improvement here is, gain, hard to quantify,
but it's the right thing to do.
llvm-svn: 70078
"interesting" identifiers (e.g., those where the IdentifierInfo has
some useful information) from "uninteresting" identifiers (where the
IdentifierInfo is just a name). This makes the hash table smaller (so
searching in it should be faster) and, when loading "uninteresting"
identifiers, we skip the lookup in the hash table.
PCH file size is slightly smaller than before (since we don't emit the
contents of the uninteresting IdentifierInfo structures). The
Cocoa.h-prefixed "Hello, World" doesn't show any speedup, although
we're getting to the point where system noise is a bit issue.
llvm-svn: 70075
allocating IdentifierInfos with a pointer into the string data stored
in the PCH file rather than having an entry in the identifier table's
string map. However, we don't actually get these savings at the
moment, because we go through the IdentifierTable when loading
identifiers from the on-disk hash table.
This commit is for record-keeping purposes only. I'll be reverting
this change (and the PCH layout tweak that preceded it) because it
appears that implementing this optimization will collide with another,
future optimization to reduce the size of the on-disk hash table for
identifiers. That optimization is likely to provide more benefit (with
less voodoo).
llvm-svn: 70070
Ted Kremenek