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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66528 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66524 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66513 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66509 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66468 91177308-0d34-0410-b5e6-96231b3b80d8
Redefinition checking should ignore the leading whitespace and
start of line flags on the first token of an expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66442 91177308-0d34-0410-b5e6-96231b3b80d8
Obj-C metadata variables (which generally should be handled the same,
although they aren't currently).
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66432 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents caret diagnostics from the scratch buffer from
including other tokens in the scratch buffer that occurred beforei
them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66375 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66374 91177308-0d34-0410-b5e6-96231b3b80d8
warning to only trigger when there is whitespace or something else after the + as
suggested by Eli.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66370 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit cleaner, and also "fixes" bad code that compares the
addresses of the string constants.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66346 91177308-0d34-0410-b5e6-96231b3b80d8