The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Modify ReferenceDependenciesEmitter::emit to write to a temporary file and then atomically rename it in place using the atomicallyWritingToFile helper function.
This resolves SR-8707, where .swiftdeps files could be truncated if the compiler job was killed in the middle of a write.
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
Textual module interfaces don't actually depend on SILGen, so we
shouldn't need to run SILGen (or serialize an entire binary module) if
we're just trying to emit a textual interface. On the other hand, if
we /are/ going to run SILGen and then SIL diagnostics, we shouldn't
delay those diagnostics by spending time emitting a textual interface,
or for that matter a TBD file.
Using this, update all the ModuleInterface tests that use
`-emit-module -o /dev/null` to use `-typecheck` instead, except for
those using `-merge-modules`.
No functionality change. Unfortunately we still need the flag in
SILModule itself because of the ability to create an empty SILModule
and parse SIL into it incrementally, which can happen before there's
a FileUnit to use as the associated DeclContext instead of a
CompilerInstance's main module.
This was only used by the integrated REPL, and is now a dead option.
The "StartElem" option for performTypeChecking is still used for
reading SIL files, which have AST and SIL blocks alternate.
The special 'Builtin' module is implicitly imported via -parse-stdlib,
and can't be found via normal import resolution, so we shouldn't print
it in a textual interface.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
Package up the logic that generates a full Clang module name, so that
(a) we don't have to deal with clang::Module in quite as many places
in the /Swift/ compiler, and (b) we can avoid the cost of a temporary
string in a few places.
The main places where this is /not/ adopted is where we don't just
want to know the parent module name, but actually the module itself.
This is mostly indexing-related queries, which use the very similar
ModuleEntity class also defined in Module.h. I didn't quite see an
obvious way to unify these, but that might be where we want to go.
No functionality change.
* [TBDGen] Allow user-provided dylib version flags
This patch adds two frontend arguments, -tbd-compatibility-version and
-tbd-current-version, both of which accept SemVer versions.
These will show up in the generated TBD file for a given module as
current-version: 2.7
compatibility-version: 2.0
These flags both default to `1.0.0`.
* Reword some comments
* Add test for invalid version string
* Expand on comments for TBD flags
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
This was removed upstream in https://reviews.llvm.org/D47789 since the only
place this flag was used was in the windows implementation where the behavior
triggered by this could be hidden in the implementation instead of being an
argument. As such, this code doesn't compile on master-next.
Since this has an acceptable default argument given the current stable, we can
just fix this on master and everything will work.
rdar://42862352
This replaces the use of a Clang utility function that was
inexplicably a non-static member function of CompilerInstance. It
would be nice to sink this all the way to LLVM and share the
implementation across both projects, but the Clang implementation does
a handful of things we don't need, and it's hard to justify including
them in an LLVM-level interface. (I stared at
llvm/Support/FileSystem.h for a long time before giving up.)
Anyway, Serialization and FrontendTool both get their atomic writes
now without depending on Clang, and without duplicating the
scaffolding around the Clang API. We should probably adopt this for
all our output files.
No functionality change.
