week in:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090302/013580.html
That patch caused the output of the diagnostics to change. Since
'DeclarationName' can already reason about Selectors and the Diagnostics logic
reasons about DeclarationName, there is no additional code needed to get the
diagnostics working by making Selector::getIdentifierInfo() private.
llvm-svn: 66992
always, refactored the existing logic to tease apart the parser action
and the semantic analysis shared by the parser and template
instantiation.
llvm-svn: 66987
- C++ function casts, e.g., T(foo)
- sizeof(), alignof()
More importantly, this allows us to verify that we're performing
overload resolution during template instantiation, with
argument-dependent lookup and the "cached" results of name lookup from
the template definition.
llvm-svn: 66947
instantiation for binary operators. This change moves most of the
operator-overloading code from the parser action ActOnBinOp to a new,
parser-independent semantic checking routine CreateOverloadedBinOp.
Of particular importance is the fact that CreateOverloadedBinOp does
*not* perform any name lookup based on the current parsing context (it
doesn't take a Scope*), since it has to be usable during template
instantiation, when there is no scope information. Rather, it takes a
pre-computed set of functions that are visible from the context or via
argument-dependent lookup, and adds to that set any member operators
and built-in operator candidates. The set of functions is computed in
the parser action ActOnBinOp based on the current context (both
operator name lookup and argument-dependent lookup). Within a
template, the set computed by ActOnBinOp is saved within the
type-dependent AST node and is augmented with the results of
argument-dependent name lookup at instantiation time (see
TemplateExprInstantiator::VisitCXXOperatorCallExpr).
Sadly, we can't fully test this yet. I'll follow up with template
instantiation for sizeof so that the real fun can begin.
llvm-svn: 66923
- language recognition was recognizing prefixes incorrectly.
- -x none wasn't working.
- test for "can lipo" was backwords.
- missed a '"' in -ccc-print-phases
llvm-svn: 66911
really horrible extensions that are disabled by default but that can
be accepted by -fheinous-gnu-extensions (but which always emit a
warning when enabled).
As our first instance of this, implement PR3788/PR3794, which allows
non-lvalues in inline asms in contexts where lvalues are required. bleh.
llvm-svn: 66910
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>
llvm-svn: 66899
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.
llvm-svn: 66896
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.
llvm-svn: 66885
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.
llvm-svn: 66862
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.
llvm-svn: 66851
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.
llvm-svn: 66842
- 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
llvm-svn: 66818
- 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.
llvm-svn: 66817
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.
llvm-svn: 66814
- Use OPT_ prefix for ids.
- Reference groups and aliases by shortend id (on the theory that
this is more readable).
- Rename the special option ids to more protected names.
llvm-svn: 66767
class members to the corresponding in-class declaration.
Diagnose the erroneous use of 'static' on out-of-line definitions of
class members.
llvm-svn: 66740
- This is an ABI incompatiblity, but this is not likely to be a huge
deal in practice. For now we at least generate self consistent code
instead of crashing.
- <rdar://problem/6657601> x86-32 ABI: Bitfields in small structures
are not passed correctly
llvm-svn: 66713
TypedViewRegion has a valid rvalue type. Also renamed instance variable 'T' to
'LvalueType' to make it unambiguous of its purpose.
This fixes some crashes I was seeing after:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090309/013771.html
This is because 'isBoundable()' is defined in TypedRegion (the parent class) in
terms of the rvalue type (which could be null), while for TypedViewRegion it
should be defined in terms of the lvalue type.
llvm-svn: 66712
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?
llvm-svn: 66662
offset may be different that the base. Ultimately we need a better solution for
these issues, but this point-by-point fixes are gradually outlining the scope of
the problem.
llvm-svn: 66638
path-sensitivity, beyond checking to see if the value is "unknown" also check if
the ConstraintManager can handle the SVal. This allows us to recover some
path-sensitivity by actually discarding some information.
llvm-svn: 66627
definitions. We were rejecting tentative definitions of incomplete
(which is bad), and now we don't.
This fix is partial because we don't do the end-of-translation-unit
initialization for tentative definitions that don't ever have any
initializers specified.
llvm-svn: 66584
context of a template-id for which we need to instantiate default
template arguments.
In the TextDiagnosticPrinter, don't suppress the caret diagnostic if
we are producing a non-note diagnostic that follows a note diagnostic
with the same location, because notes are (conceptually) a part of the
warning or error that comes before them.
llvm-svn: 66572
only print the template instantiation backtrace for the first error.
Also, if a base class has failed to type-check during instantiation,
just drop that base class and continue on to check other base classes.
llvm-svn: 66563
'struct A<double, int>'
In the "template instantiation depth exceeded" message, print
"-ftemplate-depth-N" rather than "-ftemplate-depth=N".
An unnamed tag type that is declared with a typedef, e.g.,
typedef struct { int x, y; } Point;
can be used as a template argument. Allow this, and check that we get
sensible pretty-printing for such things.
llvm-svn: 66560
to a diagnostic that will be invoked after the diagnostic (if it is
not suppressed). The hooks are allowed to produce additional
diagnostics (typically notes) that provide more information. We should
be able to use this to help diagnostic clients link notes back to the
diagnostic they clarify. Comments welcome; I'll write up documentation
and convert other clients (e.g., overload resolution failures) if
there are no screams of protest.
As the first client of post-diagnostic hooks, we now produce a
template instantiation backtrace when a failure occurs during template
instantiation. There's still more work to do to make this output
pretty, if that's even possible.
llvm-svn: 66557
done in sema, and is reflected by the existing PR3258. In the meantime,
fix PR3682 by disabling a bogus assertion (which doesn't account for +
operands).
llvm-svn: 66533
asm. This allows us to properly handle the case when an optimizer duplicates
the asm, such as here:
void bar() {
int i;
for (i = 0; i < 3; ++i)
asm("foo %=" : : "r"(0));
}
we now produce:
_bar:
xorl %eax, %eax
## InlineAsm Start
foo 0
## InlineAsm End
## InlineAsm Start
foo 1
## InlineAsm End
## InlineAsm Start
foo 2
## InlineAsm End
ret
instead of:
_bar:
xorl %eax, %eax
## InlineAsm Start
foo 1
## InlineAsm End
## InlineAsm Start
foo 1
## InlineAsm End
## InlineAsm Start
foo 1
## InlineAsm End
ret
This also fixes a fixme by eliminating a static.
llvm-svn: 66528
- Group control flow and event PathDiagnosticPieces into PathDiagnosticMacroPieces.
- Afterwards, eliminate any PathDiagnosticMacroPieces from a PathDiagnostic that
contain no informative events.
HTMLDiagnostics:
- Use new information about PathDiagnosticMacroPieces to specially format
message bubbles for macro expansions containing interesting events.
llvm-svn: 66524
(default: 99). Beyond this limit, produce an error and consider the
current template instantiation a failure.
The stack we're building to track the instantiations will, eventually,
be used to produce instantiation backtraces from diagnostics within
template instantiation. However, we're not quite there yet.
This adds a new Clang driver option -ftemplate-depth=NNN, which should
eventually be generated from the GCC command-line operation
-ftemplate-depth-NNN (note the '-' rather than the '='!). I did not
make the driver changes to do this mapping.
llvm-svn: 66513
such as replacing 'T' in vector<T>. There are a few aspects to this:
- Extend TemplateArgument to allow arbitrary expressions (an
Expr*), and switch ClassTemplateSpecializationType to store
TemplateArguments rather than it's own type-or-expression
representation.
- ClassTemplateSpecializationType can now store dependent types. In
that case, the canonical type is another
ClassTemplateSpecializationType (with default template arguments
expanded) rather than a declaration (we don't build Decls for
dependent types).
- Split ActOnClassTemplateId into ActOnClassTemplateId (called from
the parser) and CheckClassTemplateId (called from
ActOnClassTemplateId and InstantiateType). They're smart enough to
handle dependent types, now.
llvm-svn: 66509
a warning and then threw away the AST. While I'm in there, tighten up the
code to actually reject completely bogus cases (sending a message to a
struct). We still allow sending a message to an int, which doesn't make
sense but GCC allows it and is easy to support.
llvm-svn: 66468
end of line instead of just the end of buffer. Scratch buffers contain
embedded \0's between tokens which are logic line separators. If a
normal text buffer contains \0's, it doesn't make a lot of sense to include
them in the caret diag output anyway.
llvm-svn: 66374
Daniel Dunbar