A ‘forwarding module’ is a YAML file that’s meant to stand in for a .swiftmodule file and provide an up-to-date description of its dependencies, always using modification times.
When a ‘prebuilt module’ is first loaded, we verify that it’s up-to-date by hashing all of its dependencies. Since this is orders of magnitude slower than reading mtimes, we’ll install a `forwarding module` containing the mtimes of the now-validated dependencies.
The dependency file that is being generated should not escape : and # in
the filename. This makes the behaviour of the filename escaping similar
to clang and GCC and fixes incorrect quoting of paths on Windows.
NOTE: This is not in the mandatory passes (which run before this). This will
enable me to strip out ownership after we serialize without touching frontend
code. It also makes Onone and O use the same code paths for serialization
instead of one happening in the driver (Onone today) and the other in a SIL pass
(-O, -Osize).
The reason that I updated the sil-func-extractor test is that I found a bug in
how we emit sib files, namely if you try to emit a sib file to stdout, the
llvm-bcanalyzer flags it as malformed. If I output the .sib into a file rather
than trying to use stdout, everything works.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
Makes it easier to test the caching behavior, and may also be useful
for "prebuilding" swiftinterfaces in the future, or having the Driver
kick off a bunch of separate builds as proper tasks.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
The order of evaluation of arguments is undefined by the language
specification. Windows evaluates right to left rather than left to
right. This means that the argument was getting moved away before
initializing the first formal argument. Use a temporary to construct
the value to avoid the use-after-move.
- Many tests got broken because of two things:
- AST dump now outputs to stdout, but many tests expected stderr. This was a straightforward fix.
- Many tests call swift with specific parameters; specifically, many call `swift frontend` directly. This makes them go through the compiler in unexpected ways, and specifically it makes them not have primary files, which breaks the new AST dump implementation. This commit adds the old implementation as a fallback for those cases, except it dumps to `stdout` to maintain some consistence.
Finally, the `/test/Driver/filelists.swift` failed for unknown reasons. It seems its output now had some lines out of order, and fixing the order made the test pass. However, as the reasons why it failed are unknown, this fix might not have been a good idea. Corrections are welcome.
- Adds a space after the `for`;
- Changes `Instance` to use `getASTContext` directly.
- The `getFileOutputStream` method already checks for the `"-"` file name and returns `stdout` in that case. Replace the current (redundant) check with that one, and therefore replace the current default (`stderr`) with `stdout`.
This adds two things:
- Calling `swiftc -dump-ast foo.swift [...] -o foo.ast` will dump the AST to the file `foo.ast`, instead of dumping it to `stderr` as usual.
- Calling `swiftc -dump-ast -output-file-map=outputFileMap.json *.swift [...]`, given an `outputFileMap.json` file that contains entries in the form `"ast-dump": "foo.ast"`, will dump the ASTs of the input files to their respective output files in the file map.
This should serve as a valid workaround to a bug mentioned in [the forums](https://forums.swift.org/t/error-when-dumping-the-ast-for-hundreds-of-files/17578) where the AST dump functionality crashes when called with too many input files. A few implementation details were also discussed in the same forum post.
As an aside, this also fixes a comment in `include/swift/Basic/PrimarySpecificPaths.h` that was incorrect.
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.
* [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
