I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
The Swift 4 Migrator is invoked through either the driver and frontend
with the -update-code flag.
The basic pipeline in the frontend is:
- Perform some list of syntactic fixes (there are currently none).
- Perform N rounds of sema fix-its on the primary input file, currently
set to 7 based on prior migrator seasons. Right now, this is just set
to take any fix-it suggested by the compiler.
- Emit a replacement map file, a JSON file describing replacements to a
file that Xcode knows how to understand.
Currently, the Migrator maintains a history of migration states along
the way for debugging purposes.
- Add -emit-remap frontend option
This will indicate the EmitRemap frontend action.
- Don't fork to a separte swift-update binary.
This is going to be a mode of the compiler, invoked by the same flags.
- Add -disable-migrator-fixits option
Useful for debugging, this skips the phase in the Migrator that
automatically applies fix-its suggested by the compiler.
- Add -emit-migrated-file-path option
This is used for testing/debugging scenarios. This takes the final
migration state's output text and writes it to the file specified
by this option.
- Add -dump-migration-states-dir
This dumps all of the migration states encountered during a migration
run for a file to the given directory. For example, the compiler
fix-it migration pass dumps the input file, the output file, and the
remap file between the two.
State output has the following naming convention:
${Index}-${MigrationPassName}-${What}.${extension}, such as:
1-FixitMigrationState-Input.swift
rdar://problem/30926261
Add a -verify-debug-info option that invokes dwarfdump --verify as the last step after running dsymutil. dwarfdump is invoked with same options clang 802.0.35 uses to invoke it:
dwarfdump --verify --debug-info --eh-frame --quiet
A warning is produced if -verify-debug-info is set and no debug option is also set.
dwarfdump is failing to validate the debug info in the test verify-debug-info.swift. The failure is:
error: .debug_line[0x0000007d].row[0].file = 1 is not a valid index
https://bugs.swift.org/browse/SR-2396
This is purely designed to cheaply compute dependency graphs between
modules, and thus only lists the top-level names (i.e. not submodules)
and doesn't do any form of semantic analysis.
Commands like -emit-sil and -emit-module (on its own) do not produce object files.
When -embed-bitcode is also set, the driver runs a backend job to generate a module that fails.
This commit emits a warning instead and ignores the -embed-bitcode option.
https://bugs.swift.org/browse/SR-3352
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for two such reasons:
1. When whole module compilation is enabled, since optimizations for
WMO require a full rebuild.
2. When embedding LLVM IR bitcode, which needs to be re-generated.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the build record file is
malformed.
Sorry -- I meant to include this with the previous commit. LLVM is
moving away from llvm::sys:TimeValue in favor of std::chrono. For consistency
with LLVM, I used the new llvm::sys::TimePoint type in most places.
There are a few places, like the SourceKit files modified here, where it
makes more sense to use std::chrono directly.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled
altogether.
Add a message for one such reason: when the arguments passed to the Swift
compiler don't match the ones used previously.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the inputs passed to the
Swift compiler don't match the ones used previously.
SR-2855 suggests `-driver-show-incremental` not only print information
about why certain files are included in incremental compilation, but
also print out why incremental compilation may be disabled altogether.
Add a message for one such reason: when the version of the Swift
compiler being used to incrementally compile doesn't match the one used
to compile previously.
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
The scope map models all of the name lookup scopes within a source
file. It can be queried by source location to find the innermost scope
that contains that source location. Then, one can follow the parent
pointers in the scope to enumerate the enclosing scopes.
The scope map itself is lazily constructed, only creating scope map
nodes when required implicitly (e.g, when searching for a particular
innermost scope) or forced for debugging purposes.
using a lazily-constructed tree that can be searched by source
location. A search within a particular source location will
