So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221704 91177308-0d34-0410-b5e6-96231b3b80d8
... instead of a DIScope that might wrap something that's not actually
a DIScope (eg. a DIGlobalVariable);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221481 91177308-0d34-0410-b5e6-96231b3b80d8
When we are generating the global initializer functions, we call
CGDebugInfo::EmitFunctionStart() with a valid decl which is describing
the initialized global variable. Do not update the DeclCache with this
key as it will overwrite the the cached variable DIGlobalVariable with
the newly created artificial DISubprogram.
One could wonder if we should put artificial subprograms in the DIE tree
at all (there are vaild uses for them carrying line information though).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221385 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a corner-case where __uuidof as a template argument would
result in us trying to emit a GLValue as an RValue. This would lead to
a crash down the road.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220585 91177308-0d34-0410-b5e6-96231b3b80d8
The previous IR representation used the non-lexical decl context, which
placed the definitions in the same scope as the declarations (ie: within
the class) - this was hidden by the fact that LLVM currently doesn't
respect the context of global variable definitions at all, and always
puts them at the top level (as direct children of the compile_unit).
Having the correct lexical scope improves source fidelity and simplify
backend global variable emission (with changes coming shortly).
Doing something similar for non-member global variables would help
simplify/cleanup things further (see FIXME in the commit) and provide
similar source fidelity benefits to the final debug info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220488 91177308-0d34-0410-b5e6-96231b3b80d8
I haven't done any actual impact analysis of this change as it's a
strict improvement, but I'd be curious to know how much it helps.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220408 91177308-0d34-0410-b5e6-96231b3b80d8
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219900 91177308-0d34-0410-b5e6-96231b3b80d8
When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219736 91177308-0d34-0410-b5e6-96231b3b80d8
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219101 91177308-0d34-0410-b5e6-96231b3b80d8
By leaving these members out of the member list, we avoid them being
emitted into type unit definitions - while still allowing the
definition/declaration to be injected into the compile unit as expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219100 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the debug info emission is powered essentially from function
definitions - if we emit the definition of a function, we emit the types
of its parameters, the members of those types, and so on and so forth.
For types that aren't referenced even indirectly due to this - because
they only appear in temporary expressions, not in any named variable, we
need to explicitly emit/add them as is done here. This is not the only
case of such code, and we might want to consider handling "void
func(void*); ... func(new T());" (currently debug info for T is not
emitted) at some point, though GCC doesn't. There's a much broader
solution to these issues, but it's a lot of work for possibly marginal
gain (but might help us improve the default -fno-standalone-debug
behavior to be even more aggressive in some places). See the original
review thread for more details.
Patch by jyoti allur (jyoti.yalamanchili@gmail.com)!
Differential Revision: http://reviews.llvm.org/D2498
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218390 91177308-0d34-0410-b5e6-96231b3b80d8
Due to the possible presence of return-by-out parameters, using the LLVM
argument number count when numbering debug info arguments can end up
off-by-one. This could produce two arguments with the same number, which
would in turn cause LLVM to emit only one of those arguments (whichever
it found last) or assert (r215157).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215227 91177308-0d34-0410-b5e6-96231b3b80d8
There are no vtable offset offsets in the MS ABI, but vbtable offsets
are analogous. There are no consumers of this information yet, but at
least we don't crash now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215149 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r215137.
This doesn't work at all, an offset-offset is probably different than an
offset. I'm scared that this passed our normal test suite.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215141 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an assertion when generating full debug info in the MS ABI
for classes with virtual bases.
Fixes PR20579.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215137 91177308-0d34-0410-b5e6-96231b3b80d8
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214274 91177308-0d34-0410-b5e6-96231b3b80d8
This is the last patch to unique the type array of a subroutine type.
This is the paired commit with llvm r214132.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214133 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211610 91177308-0d34-0410-b5e6-96231b3b80d8
This looks like the right way for this check to work, but there is
another semi-obvious bug, I would think: why is CurLoc not zero'd out
between functions? The possibility for it to bleed between them seems
problematic. (& indeed I caused tests to fail when I fixed this a
different way, by setting CurLoc to SourceLocation() and the end of
EmitFunctionEnd... )
The changes to debug-info-blocks.m are due to a mismatch between the
source manager's file naming and CGDebugInfo's default handling when no
-main-file-name is specified. This actually reveals somewhat of a bug in
the debug info when using source files from standard in, too. See the
comment in CGDebugInfo::CreateCompileUnit for more details.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208742 91177308-0d34-0410-b5e6-96231b3b80d8
While constructing ObjC Interface types we might create the declaration
of some normal C++ types, thus adding things to the ReplaceMap. Make
sure we process the ReplaceMap after the ObjC interfaces.
In theory we know at this point, since we're at the end of the TU, that
we won't be upgrading any declarations to definitions, so we could just
construct non-temporary nodes, but that would require extra state in
CGDebugInfo to conditionalize the creation of declaration nodes which
seems annoying/more work than is appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208226 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208114 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking the compiler-rt build. Reverting while I
investigate/fix.
This reverts commit r208065.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208106 91177308-0d34-0410-b5e6-96231b3b80d8
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208065 91177308-0d34-0410-b5e6-96231b3b80d8
CGDebugInfo and DIBuilder were lax in their handling of temporary
MDNodes. All temporary nodes need to be deleted, which means they need
to be RAUW'd with a permanent node. This was not happening.
To ensure this, leverage DIBuilder's new ability to create both
permanent and temporary declarations. Ensure all temporary declarations
are RAUW'd, even with itself. (DIDescriptor::RAUW handles the case where
it is replaced with itself and creates a new, duplicate permanent node
to replace itself with)
This means that all temporary declarations must be added to the
ReplacementMap even if they're never upgraded to definitions - so move
the point of insertion into the map to the point of creation of the
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208055 91177308-0d34-0410-b5e6-96231b3b80d8
This takes a different approach than the
completedType/requiresCompleteType work which relies on AST callbacks to
upgrade the type declaration to a definition. Instead, just defer
constructing the definition to the end of the translation unit.
This works because the definition is never needed by other debug info
(so far as I know), whereas the definition of a struct may be needed by
other debug info before the end of the translation unit (such as
emitting the definition of a member function which must refer to that
member function's declaration).
If we had a callback for whenever an IVar was added to an ObjC interface
we could use that, and remove the need for the ObjCInterfaceCache, which
might be nice. (also would need a callback for when it was more than
just a declaration so we could get properties, etc).
A side benefit is that we also don't need the CompletedTypeCache
anymore. Just rely on the declaration-ness of a type to decide whether
its definition is yet to be emitted.
There's still the PR19562 memory leak, but this should hopefully make
that a bit easier to approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208015 91177308-0d34-0410-b5e6-96231b3b80d8
Items were being redundantly added to the replacement map (both when the
declaration was created, and then again when its definition was
constructed) which caused extra handling to be required when walking the
map (as elements may've already been replaced due to prior entries). By
avoiding adding the duplicates, the checks in the replacement handling
can be replaced with assertions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208000 91177308-0d34-0410-b5e6-96231b3b80d8
parts of Clang. I don't really have any opinion about whether using that
macro is good or bad, but its odd that this is the only one, and Eric
seemed happy with just nuking it for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206806 91177308-0d34-0410-b5e6-96231b3b80d8
specializations collect all arguments and not just the ones from the
class template partial specialization from which this class template
specialization was instantiated. The debug info does not represent the
partial specialization otherwise and so specialized parameters would
go missing.
rdar://problem/16636569.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206430 91177308-0d34-0410-b5e6-96231b3b80d8
are not associated with any source lines.
Previously, if the Location of a Decl was empty, EmitFunctionStart would
just keep using CurLoc, which would sometimes be correct (e.g., thunks)
but in other cases would just point to a hilariously random location.
This patch fixes this by completely eliminating all uses of CurLoc from
EmitFunctionStart and rather have clients explicitly pass in a
SourceLocation for the function header and the function body.
rdar://problem/14985269
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205999 91177308-0d34-0410-b5e6-96231b3b80d8
sure that a debugger can find them when stepping through code,
for example from the included testcase:
12 int test_it() {
13 c = 1;
14 d = 2;
-> 15 a = 4;
16 return (c == 1);
17 }
18
(lldb) p a
(int) $0 = 2
(lldb) p c
(int) $1 = 2
(lldb) p d
(int) $2 = 2
and a, c, d are all part of the file static anonymous union:
static union {
int c;
int d;
union {
int a;
};
struct {
int b;
};
};
Fixes PR19221.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205952 91177308-0d34-0410-b5e6-96231b3b80d8
We already got the type alias correct (though I've included a test case
here) since Clang represents that like any other typedef - but type
alias templates weren't being handled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205691 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted in 205664 and seems to be fixed by 205668... though
that may be more by accident than anything well founded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205669 91177308-0d34-0410-b5e6-96231b3b80d8
While the folding set would deduplicate the nodes themselves and LLVM
would handle not emitting the same global twice, it still meant creating
a long/redundant list of global variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205668 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205655.
Breaks the compiler-rt build with an assertion failure in LLVM...
reverting while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205664 91177308-0d34-0410-b5e6-96231b3b80d8
See the comment for CodeGenFunction::tryEmitAsConstant that describes
how in some contexts (lambdas) we must not emit references to the
variable, but instead use the constant directly - because of this we end
up emitting a constant for the variable, as well as emitting the
variable itself.
Should we just skip putting the variable on the stack at all and omit
the debug info for the constant? It's not clear to me - what if the
address of the local is taken?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205651 91177308-0d34-0410-b5e6-96231b3b80d8
This was committed 4 years ago in 108916 with insufficient testing to
explain why the "getTypeAsWritten" case was appropriate. Experience says
that it isn't - the presence or absence of an explicit instantiation
declaration was causing this code to generate either i<int> or i<int,
int>.
That didn't seem to be a useful distinction, and omitting the template
arguments was destructive to debuggers being able to associate the two
types across translation units or across compilers (GCC, reasonably,
never omitted the arguments).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205447 91177308-0d34-0410-b5e6-96231b3b80d8
We don't want to encourage the code to emit a lexical block for
a function that needs one in order for the line table to change,
we need to grab the line information from the body of the pattern
that we were instantiated from, this code should do that.
Modify the test case to ensure that we're still looking in the
right place for all of the scopes and also that we haven't
created a lexical block where we didn't need one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205368 91177308-0d34-0410-b5e6-96231b3b80d8
instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204874 91177308-0d34-0410-b5e6-96231b3b80d8
location that the next call emitLocation() would default to. Otherwise
setLocation() may wrongly believe that the current source file didn't
change, when in fact it did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204517 91177308-0d34-0410-b5e6-96231b3b80d8
* detect out of line definitions correctly
* detect member function explicit specializations correctly
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202779 91177308-0d34-0410-b5e6-96231b3b80d8
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202769 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
of the current compilation unit.
As a side effect this enables many more LTO uniquing opportunities.
This reapplies r199757 with a better testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199760 91177308-0d34-0410-b5e6-96231b3b80d8
of the current compilation unit.
As a side effect this enables many more LTO uniquing opportunities.
rdar://problem/15851206
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199757 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
class and use it pervasively to restore debug locations.
Fixes an interaction between cleanup and EH that caused the location
to not be restored properly after emitting a landing pad.
rdar://problem/15208190
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199444 91177308-0d34-0410-b5e6-96231b3b80d8
C and C++ don't emit an extra lexical scope for the compound statement
that is the body of an Objective-C method.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198699 91177308-0d34-0410-b5e6-96231b3b80d8
It controls everything that -flimit-debug-info used to, plus the
vtable type optimization. The old -fno-limit-debug-info option is now an
alias to -fstandalone-debug and vice versa.
Standalone is the default on Darwin until dtrace is updated to work with
non-standalone debug info (rdar://problem/15758808).
Note: I kept the LimitedDebugInfo name in CodeGenOptions::DebugInfoKind
because NoStandaloneDebugInfo sounded even more confusing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198655 91177308-0d34-0410-b5e6-96231b3b80d8
the lexical block formed by the compound statement that is the function
body.
rdar://problem/15010825
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198461 91177308-0d34-0410-b5e6-96231b3b80d8
These members will still be lazily added to the relevant DWARF DIEs in
LLVM but when enumerating the members they will not appear. This allows
DWARF type units to be more consistent - the type unit will never
contain these special members (so all instances of the type should have
the same DIEs without some having some special members and others having
others) and the special members will be added to the skeletal
declaration that appears in the relevant compile_unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197844 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196466 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar. The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.
Fixes PR17996.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2332
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196451 91177308-0d34-0410-b5e6-96231b3b80d8
GCC ToT doesn't do this & it's worth about 3.2% on Clang's DWO file size
with Clang. Some or all of this may be due to things like r190715 which
could have source fixes/improvements, but it's not clear that's the case
and that doesn't help other source bases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190716 91177308-0d34-0410-b5e6-96231b3b80d8
By removing the possibility of strange partial definitions with no
members that older GCC's produced for the otherwise unreferenced outer
types of referenced inner types, we can simplify debug info generation
and correct this bug. Newer (4.8.1 and ToT) GCC's don't produce this
quirky debug info, and instead produce the full definition for the outer
type (except in the case where that type is dynamic and its vtable is
not emitted in this TU).
During the creation of the context for a type, we may revisit that type
(due to the need to visit template parameters, among other things) and
used to end up visiting it first there. Then when we would reach the
original code attempting to define that type, we would lose debug info
by overwriting its members.
By avoiding the possibility of latent "defined with no members" types,
we can be sure than whenever we already have a type in a cache (either a
definition or declaration), we can just return that. In the case of a
full definition, our work is done. In the case of a partial definition,
we must already be in the process of completing it. And in the case of a
declaration, the completed/vtable/etc callbacks can handle converting it
to a definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190122 91177308-0d34-0410-b5e6-96231b3b80d8
Debug info emission was tripping over an IRGen bug (fixed in r189996)
that was resulting in duplicate emission of static data members of class
templates in namespaces.
We could add more test coverage to debug info for this issue
specifically, but I think the underlying IRGen test is more targeted and
sufficient for the issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190001 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189013.
This is causing a segfault crash in a test case I have. Reverting while
I investigate the issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189906 91177308-0d34-0410-b5e6-96231b3b80d8
We use CXX mangler to generate unique identifier for external C++ struct,
union, class and enum. Types with unique identifier are added to retained
types by DIBuilder.
Testing cases are updated to reflect the unique identifier generated for types.
The order of MDNodes is changed because of retained types and testing cases
are updated accordingly.
Testing case debug-info-uuid.cpp now emits error with Itanium mangler, since
uuid is not yet handled in Itanium mangler. And it will check for the error
message.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189622 91177308-0d34-0410-b5e6-96231b3b80d8
We had further discussions on how to retain types, whether to do it in front end
or in DIBuilder. And we agree to do it in DIBuilder so front ends
generating unique identifier do not need to worry about retaining them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189609 91177308-0d34-0410-b5e6-96231b3b80d8
We use CXX mangler to generate unique identifier for external C++ struct,
union, class and enum. Types with unique identifier are added to RetainedTypes
to make sure they are treated as used even when all uses are replaced with
the identifiers.
A single type can be added to RetainedTypes multiple times. For example, both
createForwardDecl and createLimitedType can add the same type to RetainedTypes.
A set is used to avoid duplication when updating AllRetainTypes in DIBuilder.
Testing cases are updated to reflect the unique identifier generated for types.
The order of MDNodes is changed because of retained types and testing cases
are updated accordingly.
Testing case debug-info-uuid.cpp now emits error with Itanium mangler, since
uuid is not yet handled in Itanium mangler.
We choose to update RetainedTypes in clang, then at finalize(), we update
AllRetainTypes in DIBuilder. The other choice is to update AllRetainTypes
in DIBuilder when creating a DICompositeType with unique identifier. This
option requires using ValueHandle for AllRetainTypes in DIBuilder since
the created DICompositeType can be modified later on by setContainingType etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189600 91177308-0d34-0410-b5e6-96231b3b80d8
Both functions will take a Type pointer instead of a Decl pointer. This helps
with follow-up type uniquing patches, which need the Type pointer to call
CXX mangler to generate unique identifiers.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189519 91177308-0d34-0410-b5e6-96231b3b80d8
In the transition from declaration (with some members) to definition, we
were overwriting the list of members with the empty list when attaching
template parameters.
The fix is in llvm::DICompositeType::addMember (along with asserts that
cause this bug to be covered by existing Clang test cases), including
adding some asserts to catch this sort of issue which found issues fixed
in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189494 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r189320.
Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping
these around - though it still seems like those tasks could be solved by
a tool just using the symbol table. In a very small number of cases,
thunks may be inlined & debug info might be able to save profilers &
similar tools from misclassifying those cases as part of the caller.
The extra changes here plumb through the VarDecl for various cases to
CodeGenFunction - this provides better fidelity through a few APIs but
generally just causes the CGF::StartFunction to fallback to using the
name of the IR function as the name in the debug info.
The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The
two names that go missing (in favor of only emitting those names as
linkage names) are names that can be demangled - emitting them only as
the linkage name should encourage tools to do just that.
Again, thanks to Dinesh Dwivedi for investigation/work on this issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189421 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously the backend wouldn't get to see the underlying GlobalValue
that corresponds to the template argument because it would be hidden by
a cast at the IR level. Instead strip the pointer casts off of the
value until we see the underlying GlobalValue.
Reviewers: dblaikie, echristo, majnemer
Reviewed By: majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189200 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This allows us to handle the general case where a non-type template
argument evaluates to a constant expression which isn't integral or a
declaration.
This fixes PR16939.
Reviewers: dblaikie, rsmith
Reviewed By: dblaikie
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1453
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189165 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r188687 (reverts r188642 (reverts 188600 (reverts
188576))).
With added test coverage & fix for -gline-tables-only.
Thanks Michael Gottesman for reverting this patch when it demonstrated
problems & providing a reproduction/details to help me track this down.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188739 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r188642.
This change is causing LTO builds to cause our 16 GB machines to swap and OOM
all weekend. I am going to work with Dave Blaikie to resolve the issue.
Sorry Dave =(.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188687 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r188600.
r188640/r188639 fixed the root cause of the crash-on-valid that r188600
originally introduced. This now appears to bootstrap debug clang
successfully to the best of my testing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188642 91177308-0d34-0410-b5e6-96231b3b80d8
A partner to r188639, this is a somewhat heavy-handed fix to the general
issue, since even after that prior change the issue does still
unavoidably arise with template parameters (see test case).
There are other ways we could consider addressing this (see FIXME).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188640 91177308-0d34-0410-b5e6-96231b3b80d8
Possible minor reduction in debug info & avoid some cases where creating
a context chain could lead to the type the context chain is being
created for, being created. (this is still possible with template
parameters - tests/fixes/improvements to follow)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188639 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes a crash-on-valid introduced by r188486 (which should've occurred
earlier but for a blatant bug where calling createFwdDecl from the
requireCompleteType callback was useless under -flimit-debug-info and we
were just getting lucky with other later callbacks requiring the type
anyway).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188622 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r188576.
Reverting while I investigate a selfhosting buildbot failure on Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188600 91177308-0d34-0410-b5e6-96231b3b80d8
Updated test case to not rely on line numbers in more cases (it's hard
to use the @ check syntax for debug info test cases (due to the
interesting ordering of metadata) and this case in particular (given the
hash-line directive)) - left a few in there to cover the line number
information for these.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188585 91177308-0d34-0410-b5e6-96231b3b80d8
This is the correct type (as is demonstrated by the fact that the caller
didn't need to change) & will be useful in a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188575 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than having a cast immediately inside the function, push that
type requirement out to the callers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188492 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than going through the whole getOrCreateType machinery to
manifest a type, cut straight to the implementation because we know we
have to do work.
While the previous implementation was sufficient for the two cases
(completeness and required completeness) we have already (the general
machinery could inspect the type for those attributes & go down the full
definition path), a pending change (to emit info for types when we emit
their vtables) won't have that luxury & we'll need to force the creation
rather than relying on the general purpose routine.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188486 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change, at best a slight (questionable) optimization,
but necessary for correctness of future work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188474 91177308-0d34-0410-b5e6-96231b3b80d8
This includes special members (copy/default ctor, copy assign, default
ctor) and template specializations for member function templates.
Good for a 5% decrease (1.80 to 1.71 GB) in size on Clang+LLVM's .dwo
files (when using fission).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188085 91177308-0d34-0410-b5e6-96231b3b80d8
Without an ODR, the -flimit-debug-info debug info size optimization of
emitting declarations for fully defined types when only a declaration is
needed by the TU, is incorrect. Emit the full definition whenever it's
available in non-C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187611 91177308-0d34-0410-b5e6-96231b3b80d8
We emit definitions with no members when a nested type is
referenced/required (GCC does the same, to be fair) but failed to attach
the template arguments in such a case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187608 91177308-0d34-0410-b5e6-96231b3b80d8
use the conversion to bool to check if we've managed to get a type
that isn't default constructed - as we meant to in the first place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186556 91177308-0d34-0410-b5e6-96231b3b80d8
inspired by CodegenFunction::LexicalScope.
- NoLocation temporarily turns off debug locations altogether.
This is useful for emitting instructions that should be
counted towards the function prologue.
- BuiltinLocation temporarily switches to an artificial debug location
that has a valid scope, but no line information. This is useful when
emitting compiler-generated helper functions that have no source
location associated with them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186552 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the core benefit of -flimit-debug-info by taking a more
systematic approach to avoid emitting debug info definitions for types
that only require declarations. The previous ad-hoc approach (3 cases
removed in this patch) had many holes.
The general approach (adding a bit to TagDecl and callback through
ASTConsumer) has been discussed with Richard Smith - though always open
to revision.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186262 91177308-0d34-0410-b5e6-96231b3b80d8
Test coverage for non-dependent pack expansions doesn't demonstrate a
failure prior to this patch (a follow-up commit improving debug info
will cover this commit specifically) but covers a related hole in our
test coverage.
Reviewed by Richard Smith & Eli Friedman.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186261 91177308-0d34-0410-b5e6-96231b3b80d8
Do not generate VLAs as complex variables any more, as they are now
correctly represented as breg+0 locations in the backend.
(Paired commit with LLVM: r185966)
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185967 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change. It should suffice to check the type of a debug info
metadata, instead of calling Verify.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185463 91177308-0d34-0410-b5e6-96231b3b80d8
The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the underlying logic, and placed a burden on users of
the resulting RecordLayout. This commit rips out almost all of the
old code, and replaces it with simple checks in
RecordLayoutBuilder::LayoutBitField.
This commit also fixes <rdar://problem/14252115>, a bug where class
inheritance would cause us to lay out bitfields incorrectly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185018 91177308-0d34-0410-b5e6-96231b3b80d8
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184763 91177308-0d34-0410-b5e6-96231b3b80d8
There's still a problem here - since we're not appropriately using the
signedness/range of the enum to chooset the encoding and emission of
enumerators, but GCC has some bugs around this too so I assume that's
not /such/ a high priority though I may get to it soon out of
completeness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184695 91177308-0d34-0410-b5e6-96231b3b80d8
This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184509 91177308-0d34-0410-b5e6-96231b3b80d8
This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184367 91177308-0d34-0410-b5e6-96231b3b80d8
limiting debug info.
FIXME: There is still work left to do here, the testcase should work even with -flimit-debug-info.
rdar://problem/14101097
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184252 91177308-0d34-0410-b5e6-96231b3b80d8
- factor the name construction part out from constructSetterName
- rename constructSetterName to the more appropriate constructSetterSelector
no functionality change intended.
rdar://problem/14035789
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183582 91177308-0d34-0410-b5e6-96231b3b80d8
There seems to have been some erroneous code attempting to describe the
ABI of parameters (non-trivial record parameters are passed by
reference). This would break the type of the function (especially when
it caused a mismatch between the type of a declaration & a definition)
causing PR14763 and PR14645.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183329 91177308-0d34-0410-b5e6-96231b3b80d8
In an effort to make -flimit-debug-info more consistent I over-shot the
mark & made types used via typedefs never produce definitions in the
debug info (even if the type was used in a way that would require a
definition).
The fix for this is to do exactly what I was hoping to do at some point
- plumb the declaration/definition choice through the various layers of
"CreateType" in CGDebugInfo. In this way we can produce declarations
whenever they are sufficient & definitions otherwise - including when
qualifiers are used, for example (discovered in PR14467). This may not
be complete (there may be other types/situations where we need to
propagate the "declaration/definition" choice) but it lays the basic
foundation which we can enhance in future iterations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183296 91177308-0d34-0410-b5e6-96231b3b80d8
To make this more consistent with 'getOrCreateType' & clarify the
distinction between the two. The only thing I couldn't quite communicate
in the name is that getOrCreateTypeDeclaration may actually produce a
full definition (in -fno-limit-debug-info) but the point is to call it
whenever only a declaration is needed & the implementation can choose
whether to provide a declaration or definition.
(also, unfortunately, getOrCreateType can produce declarations too - we
should sure this up by making it not do that - any caller that can
tolerate a declaration should be calling getOrCreateTypeDeclaration
instead)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182674 91177308-0d34-0410-b5e6-96231b3b80d8
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182673 91177308-0d34-0410-b5e6-96231b3b80d8
- The return type should be a pointer to the class type.
- Make the condition more specific.
rdar://problem/13359718
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182504 91177308-0d34-0410-b5e6-96231b3b80d8
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182329 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )
This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).
This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182231 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r181393 (git 3923d6a87f).
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181947 91177308-0d34-0410-b5e6-96231b3b80d8
We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181747 91177308-0d34-0410-b5e6-96231b3b80d8
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181644 91177308-0d34-0410-b5e6-96231b3b80d8
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181634 91177308-0d34-0410-b5e6-96231b3b80d8
This was added, untested (though the relevant crash was tested), in
r128725/PR9600. Removing it doesn't cause failures & nothing I can
imagine could cause this check to ever return 'true' (we should never be
dealing with dependent types here). The subsequent change to check
"isIncompleteType" (r128855/PR9608) makes a lot more sense.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181542 91177308-0d34-0410-b5e6-96231b3b80d8
Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181393 91177308-0d34-0410-b5e6-96231b3b80d8
correctly represented as breg+0 locations in the backend.
(Paired commit with LLVM: r180815)
rdar://problem/13658587
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180817 91177308-0d34-0410-b5e6-96231b3b80d8
Not that the DI* hierarchy is terribly type safe, but this makes the contract a
little clearer I think.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179835 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r178497 since the backend has been fixed.
Also add a test to ensure that we're emitting template information for unions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178587 91177308-0d34-0410-b5e6-96231b3b80d8
* Store the .block_descriptor (instead of self) in the alloca so we
can guarantee that all captured variables are available at -O0.
* Add the missing OpDeref for the alloca.
rdar://problem/12767564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178361 91177308-0d34-0410-b5e6-96231b3b80d8
* Let DIType for block-captured self to point to the completed cached
interface type.
rdar://problem/12767564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178360 91177308-0d34-0410-b5e6-96231b3b80d8
is enabled. Also add a new -test-coverage cc1 flag which makes testing coverage
possible and add our first clang-side coverage test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177470 91177308-0d34-0410-b5e6-96231b3b80d8
This way the register allocator will not optimize away the debug info
for captured variables.
Fixes rdar://problem/12767564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177086 91177308-0d34-0410-b5e6-96231b3b80d8
differentiate multiple inlined call sites on the same line
in the debug info.
Fixes rdar://problem/13036237
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176895 91177308-0d34-0410-b5e6-96231b3b80d8
Generate forward declarations that are RAUW'd by finalize().
We thus avoid outputting the same type several times in multiple
stages of completion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176820 91177308-0d34-0410-b5e6-96231b3b80d8
that adds ivars to an interface.
Fixes rdar://13175234
This is an update to r176116 that performs a smart caching of interfaces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176584 91177308-0d34-0410-b5e6-96231b3b80d8
and through to the debug info in the module. In order to make the
testcase a bit more efficient allow the filename to go through
compilation for compile and not assemble jobs and turn off the
extract for cases where we don't create an object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175935 91177308-0d34-0410-b5e6-96231b3b80d8
r173593 made us a little too eager to associate all code at the end of a
function with the user-written 'return' line. This caused problems with
breakpoints as they'd be set in exception handling code preceeding the
actual non-exception return handling code, leading to the breakpoint never
being hit in non-exceptional execution.
This change restores the pre-r173593 exception handling line information where
the cleanup code is associated with the '}' not the return line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174206 91177308-0d34-0410-b5e6-96231b3b80d8
One of the gotchas (see changes to CodeGenFunction) was due to the fix in
r139416 (for PR10829). This only worked previously because the top level
lexical block would set the location to the end of the function, the debug
location would be updated (as per r139416), the location would be set to
the end of the function again (but that would no-op, since it was the same
as the previous location), then the return instruction would be emitted using
the debug location.
Once the top level lexical block was no longer emitted, the end-of-function
location change was causing the debug loc to be updated, regressing that bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173593 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like r161368 fixed this for one case but not all. This change generalizes
the solution over all the unwrapping cases. Now that preserving the qualifiers
is done independent of the particular type being unwrapped I won't bother
adding test cases for each one but at least demonstrate that this change was
necessary & sufficient to fix the bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173002 91177308-0d34-0410-b5e6-96231b3b80d8
order. Describe static data members to metadata using new interfaces.
Part of PR14471.
Patch by Paul Robinson!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172591 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for using this to construct the function type for
pointers to member functions to include the implicit/artificial 'this'
parameter in that case as well. (feedback from GDB indicates that this might be
all that's necessary to get it to behave well with Clang's pointer-to-member
function debug output)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171809 91177308-0d34-0410-b5e6-96231b3b80d8
Using added LLVM functionality in r171698. This works in GDB for member
variable pointers but not member function pointers. See the LLVM commit and
GDB bug 14998 for details.
Un-xfailing cases in the GDB 7.5 test suite will follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171699 91177308-0d34-0410-b5e6-96231b3b80d8
Catch some cases I'd missed in r171605 related to unnamed parameters of record
type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5
test suite. Fix to the test suite to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171633 91177308-0d34-0410-b5e6-96231b3b80d8
I wasn't sure where to put the test case for this, but this seemed like as good
a place as any. I had to reorder the tests here to make them legible while
still matching the order of metadata output in the IR file (for some reason
making it virtual changed the ordering).
Relevant commit to fix up LLVM to actually respect 'artificial' member
variables is coming once I write up a test case for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170154 91177308-0d34-0410-b5e6-96231b3b80d8
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169311 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169219 91177308-0d34-0410-b5e6-96231b3b80d8
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168825 91177308-0d34-0410-b5e6-96231b3b80d8
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168119 91177308-0d34-0410-b5e6-96231b3b80d8
temporarily since it breaks the gdb bots.
This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167887 91177308-0d34-0410-b5e6-96231b3b80d8
If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167807 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful because unnamed bitfields can have effects on the
offsets which are not otherwise reflected in the DWARF information.
<rdar://problem/12629719>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167503 91177308-0d34-0410-b5e6-96231b3b80d8
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166236 91177308-0d34-0410-b5e6-96231b3b80d8
Make clang emit a flag for DW_AT_object_pointer for the artificial
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163755 91177308-0d34-0410-b5e6-96231b3b80d8
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163668 91177308-0d34-0410-b5e6-96231b3b80d8
that the types aren't artificial the args are, but this is currently
represented by an artificial type.)
Found by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163585 91177308-0d34-0410-b5e6-96231b3b80d8
reference, so &* on an empty WeakVH binds a reference to a dereferenced null
pointer. So don't do that; we have a perfectly good implicit conversion to
Value*.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162079 91177308-0d34-0410-b5e6-96231b3b80d8
there's something going on there. Remove the unconditional line entry
and only add one if we're emitting cleanups (any other statements
would be handled normally).
Fixes rdar://9199234
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160033 91177308-0d34-0410-b5e6-96231b3b80d8
CreateEnumType doesn't participate in caching so the descriptor for the enum
gets recomputed for every reference of an element of an enum, only to get
discarded when it gets turned into an MDNode.
No functionality change except performance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158832 91177308-0d34-0410-b5e6-96231b3b80d8
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158793 91177308-0d34-0410-b5e6-96231b3b80d8
While this code is valid C++98, it is not valid C++11. The problem can be
reduced to:
class MDNode;
class DIType {
operator MDNode*() const {return 0;}
};
class WeakVH {
WeakVH(MDNode*) {}
};
int main() {
DIType di;
std::pair<void*, WeakVH> p(std::make_pair((void*)0, di)));
}
This was not detected by any of the bots we have because they either compile
C++98 with libstdc++ (which allows it), or C++11 with libc++ (which incorrectly
allows it). I ran into the problem when compiling with VS 2012 RC.
Thanks to Richard for explaining the issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158245 91177308-0d34-0410-b5e6-96231b3b80d8
The integral APSInt value is now stored in a decomposed form and the backing
store for large values is allocated via the ASTContext. This way its not
leaked as TemplateArguments are never destructed when they are allocated in
the ASTContext. Since the integral data is immutable it is now shared between
instances, making copying TemplateArguments a trivial operation.
Currently getting the integral data out of a TemplateArgument requires creating
a new APSInt object. This is cheap when the value is small but can be expensive
if it's not. If this turns out to be an issue a more efficient accessor could
be added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158150 91177308-0d34-0410-b5e6-96231b3b80d8
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158104 91177308-0d34-0410-b5e6-96231b3b80d8
to get a const char* if necessary.
This avoids unnecessary conversions when we want to use the result of getName as
a StringRef.
Part of rdar://10796159
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156227 91177308-0d34-0410-b5e6-96231b3b80d8
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.
Reviewed by Eric Christopher.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156160 91177308-0d34-0410-b5e6-96231b3b80d8
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155808 91177308-0d34-0410-b5e6-96231b3b80d8
The mangler doesn't like non-prototyped functions so only use a mangled
name for prototyped functions.
rdar://11079003
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154570 91177308-0d34-0410-b5e6-96231b3b80d8
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration. Use the current scope
location as a separate parameter so that we can match it up
better in the line table with the beginning of the scope.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart
and for the new metadata parameter and add a new testcase to
make sure we've got the right line numbers for synthesized
properties.
Part of rdar://11026482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153917 91177308-0d34-0410-b5e6-96231b3b80d8
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart.
Fixes rdar://11026482
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153714 91177308-0d34-0410-b5e6-96231b3b80d8
function templates as well.
A future commit will mangle the added name with the template args
like classes are mangled.
Fixes rdar://10986010
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152683 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
This currently doesn't handle capturing the 'this' pointer for any
enclosing class.
Steal the lambda-expressions.cpp testcase and debugify it and try
to use more variables to proof it against random changes.
Part of rdar://10900684
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151702 91177308-0d34-0410-b5e6-96231b3b80d8
handled by the caching and rauw. Also fix one cache that wasn't
being added to highlighted by this patch. Update all testcases
accordingly.
This should fix the deall failure.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150977 91177308-0d34-0410-b5e6-96231b3b80d8
emit less than complete types on purpose on occasion and so
our caches aren't useful for this kind of lazy emitting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150856 91177308-0d34-0410-b5e6-96231b3b80d8
"Add a completed/incomplete type difference. This allows us to have
partial types for contexts and forward decls while allowing us to
complete types later on for debug purposes.
This piggy-backs on the metadata replacement and rauw changes
for temporary nodes and takes advantage of the incremental
support I added in earlier. This allows us to, if we decide,
to limit adding methods and variables to structures in order
to limit the amount of debug information output into a .o file.
The caching is a bit complicated though so any thoughts on
untangling that are welcome."
with a fix:
- Remove all RAUW during type construction by adding stub versions
of types that we later complete.
and some TODOs:
- Add an RAUW cache for forward declared types so that we can replace
them at the end of compilation.
- Remove the code that updates on completed types because we no
longer need to have that happen. We emit incomplete types on
purpose and only want to know when we want to complete them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150752 91177308-0d34-0410-b5e6-96231b3b80d8
partial types for contexts and forward decls while allowing us to
complete types later on for debug purposes.
This piggy-backs on the metadata replacement and rauw changes
for temporary nodes and takes advantage of the incremental
support I added in earlier. This allows us to, if we decide,
to limit adding methods and variables to structures in order
to limit the amount of debug information output into a .o file.
The caching is a bit complicated though so any thoughts on
untangling that are welcome.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150631 91177308-0d34-0410-b5e6-96231b3b80d8
difference in the qual type. This is a workaround for the fact that
the type isn't artificial but the this decl is, however, we don't
have any way of representing it in the current metadata. For now,
however, just don't cache the full type.
Fixes rdar://10831526 and probably a couple of others.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150159 91177308-0d34-0410-b5e6-96231b3b80d8
David Blaikie