kinds of statements (in the instantiation logic). No functionality
change, but now we'll get linker errors if we add a statement but
forget to introduce its instantiation logic.
llvm-svn: 72031
template, introduce that member function into the template
instantiation stack. Also, add diagnostics showing the member function
within the instantiation stack and clean up the qualified-name
printing so that we get something like:
note: in instantiation of member function 'Switch1<int, 2, 2>::f'
requested here
in the template instantiation backtrace.
llvm-svn: 72015
delta tree.
The issue is roughly a conflict in ReplaceText between two kinds of
uses. One, it should be possible to replace a replacement: for example, the
ObjC rewriter calls ReplaceStmt for an expression, then replaces the resulting
expression with another expression. Two, it should be possible to
replace text that already has text inserted before it: for example, the
HTML rewriter inserts a bunch of tags at the beginning of the line, then
tries to escape the first character on the line. This patch
distinguishes the two cases by storing the deltas separately;
essentially, replacements and insertions no longer interfere with
each other.
Another possibility would be to add some sort of flag to ReplaceText, but
this seems a bit more intuitive and flexible.
There are a few downsides to the current solution: one is that there isn't
any way to remove/replace an insertion without touching additional
surrounding text; if such an operation turns out to be useful, an
additional method or flag can be added. Another is that an insertion
and replacing a string of length zero are distinct operations; I'm not
sure how to resolve this, or whether it will be confusing in practice.
This is relatively sensitive code, so please test and tell me if
anything breaks.
llvm-svn: 72000
alternatives, but please correct me if I'm wrong.
I eventually plan to assert in mergeTypes that we aren't in C++ mode
because composite types are fundamentally not a part of C++. The
remaining callers for code in the regression tests are
Sema::WarnConflictingTypedMethods and CodeGenFunction::EmitFunctionProlog;
I'm not quite sure what the correct approach is for those callers.
llvm-svn: 71946
This patch isn't quite ideal in that it eliminates the warning for
constructs like "int a = {1};", where the braces are in fact redundant.
However, that would have required a bunch of refactoring, and it's
much less likely to cause confusion compared to redundant nested braces.
llvm-svn: 71939
Daniel Dunbar