a massive memory leak when using a BumpPtrAllocator in ASTContext.
Added a FIXME, as the Destroy method for TemplateArgumentList isn't getting called.
This means we will instead leak when using the MallocAllocator.
llvm-svn: 104633
This class only supports name mangling (which is apparently used during C/ObjC
codegen). For now only the Itanium C++ ABI is supported. Patches to add a
second C++ ABI are forthcoming.
llvm-svn: 104630
variables within blocks. We loosely follow GCC's mangling, but since
these are always internal symbols the names don't really matter. I
intend to revisit block mangling later, because GCC's mangling is
rather verbose. <rdar://problem/8015719>.
llvm-svn: 104610
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
variables should have that linkage. Otherwise, its static local
variables should have internal linkage. To avoid computing this excessively,
set a function's linkage before we emit code for it.
Previously we were assigning weak linkage to the static variables of
static inline functions in C++, with predictably terrible results. This
fixes that and also gives better linkage than 'weak' when merging is required.
llvm-svn: 104581
- I think this can be cleaned up, since this means we may notify the consumer about the vtable twice, but I didn't see an easy fix for this without more substantial refactoring.
- Doug, please review!
llvm-svn: 104577
there are already two spaces before the token where the : was expected,
put the : in between the spaces. This means we get it right in both
of these cases:
t.c:2:17: error: expected ':'
return a ? b c;
^
:
t.c:3:16: error: expected ':'
return a ? b c;
^
:
In the later case, the diagnostic says to insert ": ", in the former
case it says to insert ":" between the spaces. This fixes rdar://8007231
llvm-svn: 104569
major buckets to catch parser and sema issues, add inline asm
category, and make diag groups take precedence over the
sweeping categories just added.
llvm-svn: 104561
fatal error: too many errors emitted, stopping now [-ferror-limit=]
Tell the user that this is controlled with -ferror-limit=, like above.
llvm-svn: 104528
This works around a crash where malloc reused the memory of an erased BB for a
new BB leaving old cleanup information pointing at the new block.
llvm-svn: 104472
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
llvm-svn: 104471
pointers in the ASTContext, so that the folding sets stored inside
them will be deallocated when the ASTContext is destroyed (under
-disable-free). <rdar://problem/7998824>.
llvm-svn: 104465
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
llvm-svn: 104443
Douglas Gregor