The coverage implementation marks functions which won't be emitted as
'deferred', so that it can emit empty coverage regions for them later
(once their linkages are known).
Functions in dependent contexts are an exception: if there isn't a full
instantiation of a function, it shouldn't be marked 'deferred'. We've
been breaking that rule without much consequence because we just ended
up with useless, extra, empty coverage mappings. With PR32679, this
behavior finally caused a crash, because clang marked a partial template
specialization as 'deferred', causing the MS mangler to choke in its
delayed-template-parsing mode:
error: cannot mangle this template type parameter type yet
(http://bugs.llvm.org/show_bug.cgi?id=32679)
Fix this by checking if a decl's context is a dependent context before
marking it 'deferred'.
Based on a patch by Adam Folwarczny!
Differential Revision: https://reviews.llvm.org/D32144
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300723 91177308-0d34-0410-b5e6-96231b3b80d8
For various reasons, involving dllexport and class linkage compuations,
we have to wait until after the semicolon after a class declaration to
emit inline methods. These are "deferred" decls. Before this change,
finishing the tag decl would trigger us to deserialize some PCH so that
we could make a "pretty" IR-level type. Deserializing the PCH triggered
calls to HandleTopLevelDecl, which, when done, checked the deferred decl
list, and emitted some dllexported decls that weren't ready.
Avoid this re-entrancy. Deferred decls should not get emitted when a tag
is finished, they should only be emitted after a real top level decl in
the main file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@267186 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic". This addresses Richard's
post-commit review comments. This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265806 91177308-0d34-0410-b5e6-96231b3b80d8
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265702 91177308-0d34-0410-b5e6-96231b3b80d8
...as that is apparently what MSVC does. This is an updated version of r263738,
which had to be reverted in r263740 due to test failures. The original version
had erroneously emitted functions that are defined in class templates, too (see
the updated "Handle friend functions" code in EmitDeferredDecls,
lib/CodeGen/ModuleBuilder.cpp). (The updated tests needed to be split out into
their own dllexport-ms-friend.cpp because of the CHECK-NOTs which would have
interfered with subsequent CHECK-DAGs in dllexport.cpp.)
Differential Revision: http://reviews.llvm.org/D18430
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264841 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r263738.
This appears to cause a failure in
CXX/temp/temp.decls/temp.friend/p1.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263740 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This flag is enabled by default in the driver when NDEBUG is set. It
is forwarded on the LLVMContext to discard all value names (but
GlobalValue) for performance purpose.
This an improved version of D18024
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18127
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263394 91177308-0d34-0410-b5e6-96231b3b80d8
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262737 91177308-0d34-0410-b5e6-96231b3b80d8
This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262506 91177308-0d34-0410-b5e6-96231b3b80d8
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262493 91177308-0d34-0410-b5e6-96231b3b80d8
Frontend can emit errors when releaseing the Builder. If there are errors before
or when releasing the Builder, we reset the module to stop here before invoking
the backend.
Before this commit, clang will continue to invoke the backend and backend can
crash.
Differential Revision: http://reviews.llvm.org/D16564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259116 91177308-0d34-0410-b5e6-96231b3b80d8
Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches
a point where the representation is required to be known. However,
*pointers* to member pointers may exist without knowing the pointee
type's representation. In these cases, we synthesize an opaque LLVM
type for the pointee type.
However, we can be in a situation where the underlying member pointer's
representation became known mid-way through the program. To account for
this, we attempted to manicure CodeGen's type-cache so that we can
replace the opaque member pointer type with the real deal while leaving
the pointer types unperturbed. This, unfortunately, is a problematic
approach to take as we will violate CodeGen's invariants.
These violations are mostly harmless but let's do the right thing
instead: invalidate the type-cache if a member pointer's LLVM
representation changes.
This fixes PR26313.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258839 91177308-0d34-0410-b5e6-96231b3b80d8
No ABI for C++ currently makes it possible to implement the standard
100% perfectly. We wrongly hid some of our compatible behavior behind
-fms-compatibility instead of tying it to the compiler ABI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249656 91177308-0d34-0410-b5e6-96231b3b80d8
In order to produce debug info for clang modules CGDebugInfo it needs
access to macros passed on the command line and the isysroot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241035 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
Sema calls HandleVTable() with a bool parameter which is then threaded through
three layers. The only effect of this bool is an early return at the last
layer.
Instead, remove this parameter and call HandleVTable() only if the bool is
true. No intended behavior change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226096 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out there will be left-over deferred inline methods if there have
been errors, because in that case HandleTopLevelDecl bails out early.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224649 91177308-0d34-0410-b5e6-96231b3b80d8
While we're here, also move the declaration of DeferredInlineMethodDefinitions
closer to the other member vars and make it a SmallVector. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224533 91177308-0d34-0410-b5e6-96231b3b80d8
We include unused functions and methods in -fcoverage-mapping so that
we can differentiate between uninstrumented and unused. This can cause
problems for uninstantiated templates though, since they may involve
an incomplete type that can't be mangled. This shows up in things like
libc++'s <unordered_map> and makes coverage unusable.
Avoid the issue by skipping uninstantiated methods of a templated
class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222204 91177308-0d34-0410-b5e6-96231b3b80d8
recursively within the emission of another inline function. This ultimately
led to us emitting the same inline function definition twice, which we then
rejected because we believed we had a mangled name conflict.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215579 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214752 91177308-0d34-0410-b5e6-96231b3b80d8
Original message:
Fix iterator invalidation issues that are breaking my modules buildbot's
bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214555 91177308-0d34-0410-b5e6-96231b3b80d8
This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.
It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.
Differential Revision: http://reviews.llvm.org/D4563
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213304 91177308-0d34-0410-b5e6-96231b3b80d8
We would previously fail to emit a definition of bar() for the following code:
struct __declspec(dllexport) S {
void foo() {
t->bar();
}
struct T {
void bar() {}
};
T *t;
};
Note that foo() is an exported method, but bar() is not. However, foo() refers
to bar() so we need to emit its definition. We would previously fail to
realise that bar() is used.
By deferring the method definitions until the end of the top level declaration,
we can simply call EmitTopLevelDecl on them and rely on the usual mechanisms
to decide whether the method should be emitted or not.
Differential Revision: http://reviews.llvm.org/D4038
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210356 91177308-0d34-0410-b5e6-96231b3b80d8
Add driver and frontend support for the GCC -Wframe-larger-than=bytes warning.
This is the first GCC-compatible backend diagnostic built around LLVM's
reporting feature.
This commit adds infrastructure to perform reverse lookup from mangled names
emitted after LLVM IR generation. We use that to resolve precise locations and
originating AST functions, lambdas or block declarations to produce seamless
codegen-guided diagnostics.
An associated change, StringMap now maintains unique mangled name strings
instead of allocating copies. This is a net memory saving in C++ and a small
hit for C where we no longer reuse IdentifierInfo storage, pending further
optimisation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210293 91177308-0d34-0410-b5e6-96231b3b80d8
The previous code that was supposed to handle this didn't work
since parsing of inline method definitions is delayed to the end
of the outer class definition. Thus, when HandleTagDeclDefinition()
got called for the inner class, the inline functions in that class
had not been parsed yet.
Richard suggested that the way to do this is by handling inline
method definitions through a new ASTConsumer callback.
I really wanted to call ASTContext::DeclMustBeEmitted() instead of
checking for attributes, but doing that causes us to compute linkage,
and then we fail with "error: unsupported: typedef changes linkage
of anonymous type, but linkage was already computed" on tests like
this: (from SemaCXX/undefined-internal.cpp) :-/
namespace test7 {
typedef struct {
void bar();
void foo() { bar(); }
} A;
}
Differential Revision: http://reviews.llvm.org/D3809
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209549 91177308-0d34-0410-b5e6-96231b3b80d8
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198686 91177308-0d34-0410-b5e6-96231b3b80d8
We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already
emitted or not.
This fixes a 2010 TODO.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196785 91177308-0d34-0410-b5e6-96231b3b80d8
Vedant Kumar