...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
