When clang adds argument dependent lookup candidates, it can perform template
instantiation. For example, it can instantiate a templated friend function and
register it in the enclosing namespace's lookup table.
Fixes https://llvm.org/bugs/show_bug.cgi?id=24954
Reviewed by Richard Smith.
llvm-svn: 263634
This is originally r261551, reverted because of windows bots failing on
unittests. Change the current behavior to do not handle path traversals
on windows.
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the path:
/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.
Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.
Differential Revision: http://reviews.llvm.org/D17104
rdar://problem/24499339
llvm-svn: 263617
If we import a module that has a complete array type and one that has an
incomplete array type, the declaration found by name lookup might be the one with
the incomplete type, possibly resulting in rejects-valid.
Now, the name lookup prefers decls with a complete array types. Also,
diagnose cases when the redecl chain has array bound, different from the merge
candidate.
Reviewed by Richard Smith.
llvm-svn: 262189
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.
When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.
To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.
Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:
"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...
Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.
This is a useful feature for debugging module crashes in machines other than
the one where the error happened.
Differential Revision: http://reviews.llvm.org/D17457
rdar://problem/24499339
llvm-svn: 261552
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the path:
/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.
Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.
Differential Revision: http://reviews.llvm.org/D17104
rdar://problem/24499339
llvm-svn: 261551
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
If we didn't tell ReadOptionsBlock to allow failures then we can't
assume that the stream is not in the middle of a block if it returns
out-of-date. This was causing a crash when we tried to continue reading.
Also, it's just generally a good idea to early-exit if we're doing
implicit module builds, since we will want to immediately rebuild this
module anyway and there's no reason to waste time continuing after
failure.
rdar://problem/24114938
llvm-svn: 260563
Summary: This isn't a FileCheck directive; it does nothing.
Reviewers: jroelofs
Subscribers: cfe-commits, majnemer
Differential Revision: http://reviews.llvm.org/D17051
llvm-svn: 260334
name lookup information have changed since deserialization. For a C++ modules
build, we do not need to re-emit the identifier into the serialized identifier
table if only the name lookup information has changed (and in all cases, we
don't need to re-emit the macro information if only the name lookup information
has changed).
llvm-svn: 259901
When building a PCH with modules enabled this import would assert in the
ASTWriter and (if assertions were disabled) sometimes crash the compiler
that loaded the resulting PCH when trying to lookup the submodule ID.
rdar://problem/24137448
llvm-svn: 259859
Per review feedback the name was wrong and it can be used outside
Objective-C.
Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type. I'm worried that this will also affect
users' code. So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup. This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.
rdar://problem/24425801
llvm-svn: 259734
Original message:
Make CF constant string decl visible to name lookup to fix module errors
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259721
The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.
Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type. This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.
Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.
Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.
rdar://problem/24425801
llvm-svn: 259624
by stripping the path. Follow-up to r258555.
This is safe because only one PCH per CU is currently supported for
module debugging.
rdar://problem/24301262
llvm-svn: 258582
PCH files don't have a module signature and LLVM uses a nonzero DWO id as
an indicator for skeleton / module CUs. This change pins the DWO id for PCH
files to a known constant value.
The correct long-term solution here is to implement a module signature
that is an actual dterministic hash (at the moment module signatures are
just random nonzero numbers) and then enable this for PCH files as well.
<rdar://problem/24290667>
llvm-svn: 258507
can be found in a module.
There are externally visible anonymous types that can be found:
typedef struct { } s; // I can be found via the typedef.
There are anonymous internal types that can be found:
namespace { struct s {}; } // I can be found by name.
rdar://problem/24199640
llvm-svn: 258272
until we are visiting their declcontext.
This fixes a regression introduced in r256962:
When building debug info for a typdef'd anonymous tag type, we would be
visiting the inner anonymous type first thus creating a "typedef changes
linkage of anonymous type, but linkage was already computed" error.
rdar://problem/24199640
llvm-svn: 258152
redeclares an existing tag but are creating a new declaration anyway (because
it has attributes or changes the visibility of the name), don't warn that it
won't be visible outside the current scope. That's not true.
Also narrow down the set of cases where we create these extra declarations when
building modules; previously, all tag declarations but the first in a module
header would get this treatment if -fmodules-local-submodule-visibility. (This
isn't a functional change, but we try to avoid creating these extra
declarations whenever we can.)
llvm-svn: 257403
tag (because the previous declaration was found in a different module), inject
the tag into the appropriate scope (that is, the enclosing scope if we're in a
function prototype scope in C++).
llvm-svn: 257251
building a module. Prior to this change, the private header's content would
only be included if the header were included by another header in the same
module. If not (if the private header is only used by the .cc files of the
module, or is included from outside the module via -Wno-private-header),
a #include of that file would be silently ignored.
llvm-svn: 257222
was visited and all decls have been merged.
We only get a single chance to emit the types for virtual classes because
CGDebugInfo::completeRequiredType() categorically doesn't complete them.
llvm-svn: 256962
have a nested name specifier. Strictly speaking, forward declarations of class
template partial specializations are not permitted at all, but that seems like
an obvious wording defect, and if we allow them without a nested name specifier
we should also allow them with a nested name specifier.
llvm-svn: 255383
This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build systems that
use an include scanning system to determine which files are "needed" by a
compilation, and only provide those files to remote compilation workers. Since
using a module can require any file that is part of that module (or anything it
transitively includes), files that are not found by an include scanner can be
required in a regular build using explicit modules. With this flag, only files
that are actually referenced by transitively-#included files are required to be
present on the build machine.
llvm-svn: 253950
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
llvm-svn: 253512
other than the top level, we issue an error. This breaks a fair amount of C++
code wrapping C libraries, where the C library is #included within a namespace
/ extern "C" combination, because the C library (probably) includes C++
standard library headers which may be within modules.
Without modules, this setup is harmless if (and *only* if) the corresponding
standard library module was already included outside the namespace, so
downgrade the error to a default-error extension in that case, so that it can
be selectively disabled for such misbehaving libraries.
llvm-svn: 253398
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
When linking against text-based dynamic library SDKs the library name of a
framework has now more than one possible filename extensions. This fix tests for
both possible extensions (none, and .tbd).
This fixes rdar://problem/20609975
llvm-svn: 253060
actually hidden before we check its linkage. This avoids computing the linkage
"too early" for an anonymous struct with a typedef name for linkage.
llvm-svn: 253012
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
llvm-svn: 253010
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
llvm-svn: 252960
This failed to solve the problem it was aimed at, and introduced just as many
issues as it resolved. Realistically, we need to deal with the possibility that
multiple modules might define different internal linkage symbols with the same
name, and this isn't a problem unless two such symbols are simultaneously
visible.
The case where two modules define equivalent internal linkage symbols is
handled by r252063: if lookup finds multiple sufficiently-similar entities from
different modules, we just pick one of them as an extension (but we keep them
separate).
llvm-svn: 252957
we can't load that file due to a configuration mismatch, and implicit module
building is disabled, and the user turns off the error-by-default warning for
that situation, then fall back to textual inclusion for the module rather than
giving an error if any of its headers are included.
llvm-svn: 252114
internal linkage entities in different modules from r250884 to apply to all
names, not just function names.
This is really awkward: we don't want to merge internal-linkage symbols from
separate modules, because they might not actually be defining the same entity.
But we don't want to reject programs that use such an ambiguous symbol if those
internal-linkage symbols are in fact equivalent. For now, we're resolving the
ambiguity by picking one of the equivalent definitions as an extension.
llvm-svn: 252063
Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.
Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.
llvm-svn: 251955
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)
llvm-svn: 251898
A 'readonly' Objective-C property declared in the primary class can
effectively be shadowed by a 'readwrite' property declared within an
extension of that class, so long as the types and attributes of the
two property declarations are compatible.
Previously, this functionality was implemented by back-patching the
original 'readonly' property to make it 'readwrite', destroying source
information and causing some hideously redundant, incorrect
code. Simplify the implementation to express how this should actually
be modeled: as a separate property declaration in the extension that
shadows (via the name lookup rules) the declaration in the primary
class. While here, correct some broken Fix-Its, eliminate a pile of
redundant code, clean up the ARC migrator's handling of properties
declared in extensions, and fix debug info's naming of methods that
come from categories.
A wonderous side effect of doing this write is that it eliminates the
"AddedObjCPropertyInClassExtension" method from the AST mutation
listener, which in turn eliminates the last place where we rewrite
entire declarations in a chained PCH file or a module file. This
change (which fixes rdar://problem/18475765) will allow us to
eliminate the rewritten-decls logic from the serialization library,
and fixes a crash (rdar://problem/23247794) illustrated by the
test/PCH/chain-categories.m example.
llvm-svn: 251874
This patch should add support for almost all command-line options and
driver tinkering necessary to produce a correct "clang -cc1"
invocation for watchOS and tvOS.
llvm-svn: 251706
Use the *current* state of "is-moduleness" rather than the state at
serialization time so that if we read a builtin identifier from a module
that wasn't "interesting" to that module, we will still write it out to
a PCH that imports that module.
Otherwise, we would get mysterious "unknown builtin" errors when using
PCH+modules.
rdar://problem/23287656
llvm-svn: 251565
headers. If those headers end up being textually included twice into the same
module, we get ambiguity errors.
Work around this by downgrading the ambiguity error to a warning if multiple
identical internal-linkage functions appear in an overload set, and just pick
one of those functions as the lookup result.
llvm-svn: 250884
via -fmodule-file= to be turned off; in that case, just include the relevant
files textually. This allows module files to be unconditionally passed to all
compile actions via CXXFLAGS, and to be ignored for rules that specify custom
incompatible flags.
llvm-svn: 250577
context (but otherwise at the top level) to be disabled, to support use of C++
standard library implementations that (legitimately) mark their <blah.h>
headers as being C++ headers from C libraries that wrap things in 'extern "C"'
a bit too enthusiastically.
llvm-svn: 250137
We model predefined declarations as not being from AST files, but in most ways
they act as if they come from some implicit prebuilt module file imported
before all others. Therefore, if we see an update to the predefined 'struct
__va_list_tag' declaration (and we've already loaded any modules), it needs a
corresponding update record, even though it didn't technically come from an AST
file.
llvm-svn: 250134
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
when building a module. Clang already records the module signature when
building a skeleton CU to reference a clang module.
Matching the id in the skeleton with the one in the module allows a DWARF
consumer to verify that they found the correct version of the module
without them needing to know about the clang module format.
llvm-svn: 248345
If an import directive was put into wrong context, the error message was obscure,
complaining on misbalanced braces. To get more descriptive messages, annotation
tokens related to modules are processed where they must not be seen.
Differential Revision: http://reviews.llvm.org/D11844
llvm-svn: 248085
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247494
it's not sufficient to prefer the declaration with more default arguments, or
the one that's visible; they might both be visible, but one of them might have
a visible default argument where the other has a hidden default argument.
llvm-svn: 247486
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247465
Vassil Vassilev