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`.
Add a staging option for enabling upcoming changes in the solver in
support of using the protocols designated in Policy.swift to guide
operator type checking.
The previous statement happened to work out of sheer luck. `MainModule` is
initialized by the call to `getMainModule()`. The expression could be evaluated
in any order, and in the Visual Studio case, was evaluated with the index
*first*. At this point `MainModule` was uninitialized (fortunately, it was set
to NULL). As a result, the `getName` call would fail. Ensure that the
`MainModule` is initialized first by using a local variable.
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.
The use of `std::move` forces the complete definition of the `SILModule` type.
Move the definition out-of-line to allow a forward declaration of `SILModule`
instead.
When provided, this flag warns about implicit overrides, where a
declaration overrides another declaration but is not marked with the
‘override’ keyword. The warning can be suppressed by either providing
‘override’ or ‘@_nonoverride’.
At present, this only happens with overrides in protocols.
LLDB needs the -swift-version because the -D__swift__ macro affects
how Clang modules are built. This currently has the really odd effect
that when debugging a Swift program that is not using the very latest
Swift version, the first "po" takes several seconds, because the
module cache needs to be rebuilt.
rdar://problem/40241256
* [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
Having this be a single buffer hardcoded in the SourceManager and set
by all clients is silly. SourceFiles with the 'Main' kind are allowed
to have hashbang lines (`#!`), other files are not. And anyone
manually setting up a Lexer can decide for themselves.
No intended behavioral change.
This is helpful in experimenting with constraint solver changes that
might help us remove some of these unsound options. It's not ever mean
to be enabled, but if we're able to remove the things guarded by the
option we can eventually remove the option.
Continuing work from #18344, be more conservative about when we load
SwiftOnoneSupport. Specifically, -emit-silgen and -emit-sibgen, despite
not going through the SIL Optimizer, may silently introduce dependencies
on SwiftOnoneSupport.
Because we want to support the ability to posthumously compile SILGen
and SIBGen'd files with these implicit dependencies, and because SIL
is not yet capable of expressing the dependency itself, we must always
assume we need to load SwiftOnoneSupport.
Add an abstraction to retrieve a name suitable for display for a given
source location for use with diagnostics, debug locations, and magic
file literals.
Adds the -vfsoverlay frontend option that enables the user to pass
VFS overlay YAML files to Swift. These files define a (potentially
many-layered) virtual mapping on which we predicate a VFS.
Switch all input-based memory buffer reads in the Frontend to the new
FileSystem-based approach.
SwiftOnoneSupport is an implicit dependency of no-opt builds that is usually
only loaded when frontend actions that emit optimization-sensitive outputs are
run.
Force the implicit dependency to be explicit when -track-system-dependencies is
used in concert with frontend actions that requires SIL passes be run.
I made this change by removing the SILOption and then doing a compile, fix loop. I
purposely did not move around the code to make the refactoring really easy to
see.
