Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65717 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65707 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Niklas Larsson!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65706 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'.' or '->'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65651 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostic messages.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65574 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65571 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65568 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65560 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
same statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65486 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65485 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expressions of the form: 'short x = (y != 10);' While we handle 'int x = (y !=
10)' lazily, the cast to another integer type currently loses the symbolic
constraint. Eager evaluation of the constraint causes the paths to bifurcate and
eagerly evaluate 'y != 10' to a constant of 1 or 0. This should address
<rdar://problem/6619921> until we have a better (more lazy approach) for
handling promotions/truncations of symbolic integer values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65480 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
thing is to wire up pools with their contents.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65425 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that end with terminators.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65410 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the path than the branches taken.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65407 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- For autorelease pool tracking, keep information about the stack of pools
separate from their contents. Also, keep track of the number of times an
autorelease pool will send the "release" message to an object when the pool is
destroyed.
- Update CFRefCount::Update to return a new state instead of a reference count
binding. This will allow us to implement more complicated semantics with
autorelease pools.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
analyzer for array subscript expressions involving bases that are vectors. This
solution is probably a hack: it gets the lvalue of the vector instead of an
rvalue like all other types. This should be reviewed (big FIXME in
GRExprEngine).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65366 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'method' or 'funciton'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
case where an "Execution continues..." diagnostic could result in an empty message bubble.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This doesn't change the current functionality, but better codifies the
autorelease pool stack itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65328 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65322 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
getDesguaredType(). Constify some pointers along the way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65321 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
objects (opt for false negatives).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65304 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65302 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
DoNothing effect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
copy 'rule' if it doesn't already start with 'init', etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK? I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65233 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handle method names that contain 'new', 'copy', etc., but those words might be
the substring of larger words such as 'newsgroup' and 'photocopy' that do not
indicate the allocation of objects. This should address the issues discussed in
<rdar://problem/6552389>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65224 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vanilla reverse-BFS followed by a forward-DFS instead of resulting to strange
histrionics (whose purpose I can no longer remember) in the reverse-BFS stage.
This fixes an assertion failure in BugReporter due to edge cases where no root
was being hit in the reverse-BFS phase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65160 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65110 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
receiver alias if the return type is a location.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65084 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
transitions and then generate a subsequent node that removes the dead symbol
bindings. This should drastically improve caching in the simulation graph when
retain-counted objects are being tracked.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65082 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
PostStmt program point. This allows clients to pass in PostStmtCustom program
points.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65080 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression that allocates an object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65047 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65041 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that this problem arises from time to time. We should find a fundamental
solution for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65035 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
message expression is nil and the return type is struct then the returned value
is undefined or potentially garbage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65003 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
references the tracked object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64980 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64974 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Fix some grammar.
- Fix a bug where a "reference count incremented" diagnostic would not be shown
if the previous typestate was "Released" (only happens in GC mode).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64962 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
semantics of CFMakeCollectable and friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64956 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
retain/releases performed via [... release] and CFRetain(). The former are
no-ops in GC. The checker already handled this, but now we emit nice diagnostics
to the user telling them that these are no-ops.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64937 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
issue I thought it was, but it is still worth ordering Range objects by their APSInt values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64921 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When comparing if one Range is "less" than another, compare the actual APSInt
numeric values instead of their pointer addresses. This ensures that the
ImmutableSet in RangeSet always has a consistent ordering between Ranges. This
is critical for generating the same digest/hash for the contents of the sets.
This was a serious performance bug because it would often cause state caching
to be disabled along complicated paths.
Along the way:
- Put Range and RangeSet in the "anonymous namespace" and mark them hidden
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64890 91177308-0d34-0410-b5e6-96231b3b80d8
|