Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Even though 'ClangDiagnosticConsumer' filters out 'clang::diag::err_module_not_found' from being emitted by the Swift compiler, delegating to Swift's module-loading logic for error-handling, we must also ensure that we reset Clang's 'DiagnosticEngine''s error count. Otherwise, if we do not, final stages of IRGen will query Clang's code-gen to finalize its 'Module', which Clang will not do if its internal DiagnosticEngine contains errors. This will cause Swift's IRGen to fail, even though the only error emitted was one Swift intended to suppress.
Emitting Swift diagnostics in Clang buffers requires making those
buffers valid places to put Swift SourceLocs, which means making a
mirror of those buffers in the Swift SourceManager. This isn't a copy;
instead, any Clang SourceManagers that are involved are kept alive
until the importer is torn down. (There might be more than one because
of diagnostics emitted during module building.)
For a long time we only emitted diagnostics in Clang buffers if the
diagnostics came from Clang, but then we added another case for custom
Swift names that fail to import. I'm about to add another such
diagnostic, so let's formalize this buffer mapping first.
No intended functionality change.
This caused non-deterministic crashes when a high number of modules
containing diagnostics were compiled for the first time. The 9-entry
test case results in a crash on 64-bit macOS when run under Guard
Malloc without this change.
rdar://problem/33515925
We don't want to show "included from <bridging-header>" to the user--
that's just not helpful--but we /do/ want to see any unexpected
diagnostics that happen to be reported in the importer's synthetic
buffers. This would have helped us track down rdar://problem/34664596
much sooner.
For the multiple-files mode -emit-pch is still invoked in separate frontend invocation but with using a persistent PCH.
Subsequent frontend invocations use the persistent PCH but they don't need to validate it.
For all-files mode (e.g. WMO) the frontend invocation uses a persistent PCH that it also validates.
When Objective-C interop is enabled, modules will continue to be referred to as “Objective-C modules”. But when interop is disabled, they will be referred to as “C modules”.
Updated the existing test for the current behavior that doesn’t expect to fail on linux and doesn’t require objc_interop, so that it checks to different diagnostics on the two systems.
...that Clang didn't catch for us. The Clang side of things is now looser so
that we don't have to mirror our import logic over there, but that means
invalid cases can slip through.
Part of rdar://problem/21091469
Swift SVN r29535
We don't handle a line 0 in Swift, and this led to LLDB crashing. I'm not
actually sure why Clang was emitting an error on line 0, either; the full
location was "<built-in>:0:4" and the error was
module 'CoreFoundation' found in both '.../CoreFoundation-17XE9QM744UO5.pcm'
and '.../CoreFoundation-2BVMOFFOYI8X.pcm'
which turned out to be another manifestation of rdar://problem/19817341
(this was an older LLDB build). No test cases because I'm not sure how to
trigger this, especially not since the previous Radar was fixed, but I'll
clone it to track down why Clang is using such an unusual location.
rdar://problem/19951280
Swift SVN r25766
In particular, the fake "<module-includes>" buffers all have that same name.
Use the buffer itself to provide identity. (We are already deliberately
keeping the buffers alive via their source managers.)
rdar://problem/19716081
Swift SVN r25200
The ClangDiagnosticConsumer forwards diagnostics from Clang's diagnostic machinery
to Swift's. It deliberately filters out things that happen in our top-level dummy
buffer (usually trivial things like "module imported here"). Unfortunately, it was
doing so by checking against the current SourceManager's "main file". When building
Clang modules (compiling PCM files), we're dealing with a new SourceManager, whose
main file is the module map file.
Instead, just check against the (very unlikely) name of our dummy input file,
like we do for imported headers.
rdar://problem/18867749
Swift SVN r23121
This rare crash happens when
1. A diagnostic is reported when building a Clang module.
2. The diagnostic is mapped to a Swift diagnostic by mirroring the Clang
source buffer as a Swift source buffer (via non-owning reference).
3. The Clang CompilerInstance used specifically to build the module is
destroyed.
4. Some /new/ buffer is allocated in the same memory spot as the old buffer.
5. Some new Clang diagnostic occurs in the new buffer.
6. The Swift source manager asserts when trying to set up a virtual name
for the diagnostic in the second imported buffer, because there's already
a name for that region.
The fix, because we don't expect diagnostics from modules to appear very
often, is to keep any clang::SourceManagers alive if diagnostics are emitted
in their buffers. We can revisit this if/when Swift's source manager
(currently built on llvm::SourceMgr) has the ability to remove buffers.
Many thanks to Greg for noticing the problem, tracking it down, and providing
a diff to make it fail reproducibly under GuardMalloc. I've tried to preserve
the spirit of that diff in the new logic in ~SourceManager, which will also
fail reliably with GuardMalloc (and probably ASan).
rdar://problem/18285805
Swift SVN r21958
This is already a fatal error, so it doesn't matter how many diagnostics we
dump after that. It's better not to lie to the rest of the compiler about
whether the load succeeds.
No immediate Radar, but this fixes a crash in the test case I'm about to
commit, and possibly some other mystery "dependency missing" crashes in
XREF resolution.
Swift SVN r20919
If importing a Clang module fails, we should report that at the location of
the import statement. This doesn't do that fully because it isn't transitive
(if Swift module Foo imports Swift module Bar, which fails to import Clang
module Baz, we don't get an error in user source), but it's a step forward
for the simple cases.
Swift SVN r20575
...or at least the same machinery as #line. We add a (referential) mirror
of the Clang buffer to Swift's source manager, then remap that particular
line to whatever Clang currently thinks is the presumed location for that
line. (This means we respect Clang line directives too.)
This also modifies Swift's source manager to be more forgiving about adding
the same virtual file range twice; it will tell you when you try to do it.
<rdar://problem/16596800>
Swift SVN r20572
Now that bridging headers from ASTs are always present and bridging headers
from the command line are checked in advance, we no longer need to worry
about the Clang instance failing to find the bridging header. That's good,
because this wasn't implemented correctly anyway: if a bridging header
imported a module, we could get an error.
Swift SVN r20129
...so don't report a second "module missing" error from Swift itself.
We do still treat the Clang module failing to build as a fatal error.
<rdar://problem/16175035>
Swift SVN r18231
We're not mapping source locations over correctly yet, so the file name
where an error occurs gets shoved into the diagnostic text, but that's
fine for now.
This also silences the "module 'Blah' not found" error coming from the
importer whenever Swift itself can be responsible for importing the module.
Still to do: if we can't build a Clang module, we shouldn't report that
error and then say it can't be found.
<rdar://problem/14509389>
Swift SVN r18230
