The warnings about deprecated @objc inference in Swift 3 mode can be a
bit annoying; and are mostly relevant to the migration workflow. Make
the warning emission a three-state switch:
* None (the default): don't warn about these issues.
* Minimal (-warn-swift3-objc-inference-minimal): warn about direct
uses of @objc entrypoints and provide "@objc" Fix-Its for them.
* Complete (-warn-swift3-objc-inference-complete): warn about all
cases where Swift 3 infers @objc but Swift 4 will not.
Fixes rdar://problem/31922278.
Based on recommendations in SE-0160, there are two migration workflows:
- Conservative: Maintain @objc visibility that was inferred in Swift 3
by adding @objc to all declarations that were implicitily visible to
the Objective-C runtime. This is invoked in the migrator by adding the
-migrate-keep-objc-visibility flag.
- Minimal: Only declarations that must be visible to Objective-C based
on their uses (or in cases like dynamic vars) are migrated.
rdar://problem/31876357
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
These data files are installed into runtime resource directory so that migrator can pick them automatically according to specific platforms. To support testing, a front-end option -api-diff-data-file can be used to specify the data file to use and it will overwrite the default ones from resource directory.
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
Track the types we've seen instead of the type declarations we've
passed through, which eliminates some holes relating to generic types.
Detect infinite expansions by imposing an arbitrary limit.
Fixes rdar://30355804
The `-warn-swift3-objc-inference` option turns out to be extremely
useful in vetting code for unintended `@objc` entry points, so make it
available directly on `swiftc`.
But, bury the enable/disable flags under `-frontend` (they were
effectively there anyway because the driver wasn't propagating them).
Introduce flags `-enable-swift3-objc-inference` and
`-disable-swift3-objc-inference` to enable/disable the Swift 3 `@objc`
inference rules. Under `-swift-version 3`, default to the former;
under `-swift-version 4`, default to the latter. For testing purposes,
one can provide either flag in eiher language mode.
Add an -enforce-exclusivity=... flag to control enforcement of the law of
exclusivity. The flag takes one of four options:
"checked": Perform both static (compile-time) and dynamic (run-time) checks.
"unchecked": Perform only static enforcement. This is analogous to -Ounchecked.
"dynamic-only": Perform only dynamic checks. This is for staging purposes.
"none": Perform no checks at all. This is also for staging purposes.
The default, for now, is "none".
The intent is that in the fullness of time, "checked" and "unchecked" will
be the only legal options with "checked" the default. That is, static
enforcement will always be enabled and dynamic enforcement will be enabled
by default.
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.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
...in order to generate the correct diagnostics. It would be nice(TM)
if the suppression or warning-to-error mechanism was post-hoc, but it
isn't today, and if we ever get that we can just stop using these
flags.
rdar://problem/25560819
This is a hidden option. It should be used like: -assume-single-threaded
When this function is provided, the compiler assumes that the code will be executed in the single threaded mode. It then performs certain optimizations that can benefit from it, e.g. it marks as non-atomic all reference counting instructions in the user code being compiled.
- Add ImageInspectionStatic.cpp to lookup protocol conformance
and metadata sections in static binaries
- For Linux, build libswiftImageInspectionShared.a and
libswiftImageInspectionStatic.a for linking with libswiftCore.a.
This allows static binaries to be built without linking to
libdl. libswiftImageInspectionShared (ImageInspectionELF.cpp) is
automatically compiled into libswiftCore.so
- Adds -static-executable option to swiftc to use along with
-emit-executable that uses linker arguments in
static-executable-args.lnk. This also requires a libicu
to be compiled using the --libicu which has configure options
that dont require libdl for accessing ICU datafiles
- Static binaries only work on Linux at this time
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
Currently the Swift driver stops invoking frontend commands as soon as one of
them reports an error. Add a flag to control this behavior, so that users can
choose whether to see all the errors at once or bail out early.
Background
----------
Now that Swift AST type support in LLDB has matured, we can stop emitting DWARF
type information by default to reduce compile time and ibject file size.
A future commit will change -g to emit only AST type references.
The full set of debug options will be
-gnone
-gline-tables-only
-g // AST types (= everything that LLDB needs)
-gdwarf-types // AST types + DWARF types (for legacy debuggers)
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
This commit adds the flags -static-stdlib and -no-static-stdlib to
create programs statically linked (or not) with the standard library.
Not is the default, which is also the current behavior.
These flags are currently placebos on non-Darwin platforms.
ASan allows to catch and diagnose memory corruption errors, which are possible
when using unsafe pointers.
This patch introduces a new driver/frontend option -sanitize=address to enable
ASan. When option is passed in, the ASan llvm passes will be turned on and
all functions will gain SanitizeAddress llvm attribute.
* Replace 'Fast' with 'Unchecked' everywhere.
* Update the help text to specify DisableReplacement rather than
Replacement and to document Unchecked.
* Simplify tests slightly and add a tests for Unchecked.
