specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
llvm-svn: 204547
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.
llvm-svn: 204517
at which that PCH imported each visible submodule of the module. Such locations
are needed when synthesizing macro directives resulting from the import.
llvm-svn: 204417
Variables with available_externally linkage can be dropped at will.
This causes link errors, since there are still references to the
instrumentation! linkonce_odr is almost equivalent, so use that
instead.
As a drive-by fix (I don't have an Elf system, so I'm not sure how to
write a testcase), use linkonce linkage for the instrumentation of
extern_weak functions.
<rdar://problem/15943240>
llvm-svn: 204408
The variable is used to set the linkage for variables, and will become
different from function linkage in a follow-up commit.
<rdar://problem/15943240>
llvm-svn: 204407
These functions are in the profile runtime. PGO comes later.
Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.
<rdar://problem/15943240>
llvm-svn: 204390
block as decl and type emission. This allows decl updates include statements
and expressions. No functionality change (but the generated PCM files are
incompatible with earlier versions of Clang).
llvm-svn: 204385
Remove the remaining explicit static initialization from translation
units, at least on Darwin. Instead, create a use of __llvm_pgo_runtime,
which will pull in required code from compiler-rt.
After this commit (and its pair in compiler-rt), a user can define their
own __llvm_pgo_runtime to satisfy this undefined symbol and call the
functions in compiler-rt directly.
<rdar://problem/15943240>
llvm-svn: 204379
We were 'allowing' the following import
@import Sub;
where Sub is a subframework of Foo and we had a -F path inside
Foo.framework/Frameworks and no module map file for Sub. This would
later hit assertion failures in debug builds.
Now we should correctly diagnose this as a module not found error.
llvm-svn: 204368
This change turns -fsanitize-memory-track-origins into
-fsanitize-memory-track-origins=[level] flag (keeping the old one for
compatibility). Possible levels are 0 (off), 1 (default) and 2 (incredibly
detailed). See docs (part of this patch) for more info.
llvm-svn: 204346
The exception is return statements that include control-flow,
which are clearly doing something "interesting".
99% of the cases I examined for -Wunreachable-code that fired
on return statements were not interesting enough to warrant
being in -Wunreachable-code by default. Thus the move to
include them in -Wunreachable-code-return.
This simplifies a bunch of logic, including removing the ad hoc
logic to look for std::string literals.
llvm-svn: 204307
This name, while more verbose, plays more nicely with tools that use
file extensions to determine file types. The existing spelling
'module.map' will continue to work, but the new spelling will take
precedence.
In frameworks, this new filename will only go in a new 'Modules'
sub-directory.
Similarly, add a module.private.modulemap corresponding to
module_private.map.
llvm-svn: 204261
Richard Smith