Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66906 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also changed BlockDecl API to be more consistent (wrt FunctionDecl).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
conditions. Currently the analyzer does not reason well about
promotions/truncations of symbolic values, so at branch conditions when we see:
if (condition)
and condition is something like a 'short' or 'char', essentially ignore the
promotion to 'int' so that we track constraints on the original symbolic value.
We only ignore the casts if the underlying type has the same or fewer bits as
the converted type.
This fixes:
<rdar://problem/6619921>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris).
The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66896 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66894 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).
Will replace with something better today...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66893 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is 64-bit. I used his suggestion of doing a direct bitwidth/signedness
conversion of the 'offset' instead of just changing the sign. For more
information, see:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-March/004587.html
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66892 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66891 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66889 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66888 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66887 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to perform). Still doesn't do anything interesting.
- This code came out much cleaner than in ccc with the reworked
phases & mapping of types to lists of compilation steps (phases) to
perform.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66884 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66882 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
provide information about what steps should be done for a particular
file type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66881 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66880 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66879 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
defaults to off. When enabled, it emits range info along
with the file/line/col information for a diagnostic. This
allows tools that textually parse the output of clang to know
where the ranges are, even if they span multiple lines. For
example, with:
$ clang exprs.c -fprint-source-range-info
We now produce:
exprs.c:21:11:{21:12-21:13}: warning: use of unary operator that may be intended as compound assignment (+=)
var =+ 5; // expected-warning {{use of unary operator that may be intended as compound assignment (+=)}}
^~
exprs.c:22:11:{22:12-22:13}: warning: use of unary operator that may be intended as compound assignment (-=)
var =- 5; // expected-warning {{use of unary operator that may be intended as compound assignment (-=)}}
^~
exprs.c:36:13:{36:3-36:12}: error: assignment to cast is illegal, lvalue casts are not supported
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue casts are not supported}}
~~~~~~~~~ ^
exprs.c:41:4:{41:3-41:4}: error: called object type 'int' is not a function or function pointer
X(); // expected-error {{called object type 'int' is not a function or function pointer}}
~^
exprs.c:45:15:{45:8-45:14}{45:17-45:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
P = (P-42) + Gamma*4; // expected-error {{invalid operands to binary expression ('int *' and '_Complex float')}}
~~~~~~ ^ ~~~~~~~
exprs.c:61:7:{61:16-61:22}: error: invalid application of '__alignof' to bitfield
R = __alignof(P->x); // expected-error {{invalid application of '__alignof' to bitfield}} expected-warning {{extension used}}
^ ~~~~~~
Note the range info after the column in the initial diagnostic.
This is obviously really annoying if you're not a tool parsing the
output of clang, which is why it is off by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66862 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66860 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, add some FIXMEs, improve doxygen & comments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66856 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
source being a non-pointer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66854 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66853 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time.
Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.
Instantiation of these expressions is completely wrong. I'll work on
that next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66851 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
include the triplet so that people that run multiple targets in
parallel, say i386 and x86_64 can distinguish between the two.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66849 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
print-{multi-{directory,lib,os-directory}, search-dirs} as unsupported
instead of handling separately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66848 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66846 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ExplodedGraph::TrimGraph:
- Just do a DFS both ways instead of BFS-DFS. We're just determining what subset
of the nodes are reachable from the root and reverse-reachable from the bug
nodes. DFS is more efficient for this task.
BugReporter:
- MakeReportGraph: Do a reverse-BFS instead of a reverse-DFS to determine the
approximate shortest path through the simulation graph. We were seeing some
weird cases where too many loops were being reported for simple bugs. Possibly
we will need to replace this with actually computing the shortest path in
terms of line numbers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66842 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66837 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bitmap generation for basic ivars seem to
work now. This is work in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the selector for the property setter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66834 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
can more efficiently reconstruct an IntegerLiteral from it during template instantiation
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(TypedViewRegion::getLValueType() was not implemented).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Who wouldn't want correctness to hang critically on two easily
ignored characters?
Thanks Doug!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- PathDiagnosticControlFlowPiece now consists of a "start" and "end" location
to indicating the branch location and where the branch goes.
BugReporter:
- Updated BugReporter to construct PathDiagnosticControlFlowPiece objects with
"end" locations.
PlistDiagnostics:
- Plists now contain the bug "type" (not just bug "category")
- Plists now encode control-flow pieces differently than events; now the
"start" and "end" locations are recorded
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66818 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Compare to driverdriver.c if bored; not completely fair since the
driver gets a bit more code in other places to handle binding archs
(for Xarch) but not completely unfair either.
Fear not, extra Action classes will have a happy home for their
vtables soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiation. This is roughly the structure we want to expression
instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
be CompoundStmts. I think this is a valid assumption, and felt that the API
should reflect it. Others please validate this assumption to make sure I didn't
break anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66813 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66807 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66806 91177308-0d34-0410-b5e6-96231b3b80d8
|