* [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
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.
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.
...instead of sometimes hardcoding them and sometimes using Strings.h.
The exceptions are the libraries that sit below Frontend; these can
continue using strings.
...but don't hook it up to anything yet.
This is the very very start of the module stability / textual
interfaces feature described at
https://forums.swift.org/t/plan-for-module-stability/14551/
For now I've just made it a frontend option (not a driver option),
which is good enough for testing.
Introduces the -name-bind frontend action that is intended as an intermediary between the parse-only actions and a full typechecking pass. In this phase, module imports will be validated and resolved, making it possible to emit full make-style dependencies files among other things.
Note that all information available to a parse-only pass is available to name binding, but because it does not continue-on to typecheck input files, full semantic information is not.
Parse-only invocations do not support the proper creation of dependency files or reference dependency files because they have not yet run name binding. Ban these invocations by diagnostic and add a new diagnostic specifically for reference dependencies.
TBD validation is effectively an expensive assertion, and is currently only
tuned for Apple platforms. However, we don't want it to regress more, and it
would be nice to start getting validation from people using master
snapshots. Together, this means that turning it on by default for the cases
mentioned above is an appropriate course of action.
At the very least, this has the benefit of running validation across the stdlib,
the overlays and the whole testsuite on each build, so people making changes to
the compiler that change symbols are hopefully alerted.
One limitation here is that this is only validating that the TBD is a superset
of the true set of symbols: it could include spurious symbols that aren't
actually in the binary. This case is less problematic for Swift than symbols
missing from the TBD file, and so we've focused energy on this. Once we've fixed
the extra-symbols problems and are confident in it, this validation can be
upgraded to validate that too.
Half of rdar://problem/40431434.
Introduce a command-line option to visualize the complete set of output
request dependencies evaluated by a particular compile action. This is
exposing existing visualization facilities to the (-frontend) command line.
The initial version of the debugger testing transform instruments
assignments in a way that allows the debugger to sanity-check its
expression evaluator.
Given an assignment expression of the form:
```
a = b
```
The transform rewrites the relevant bits of the AST to look like this:
```
{ () -> () in
a = b
checkExpect("a", stringForPrintObject(a))
}()
```
The purpose of the rewrite is to make it easier to exercise the
debugger's expression evaluator in new contexts. This can be automated
by having the debugger set a breakpoint on checkExpect, running `expr
$Varname`, and comparing the result to the expected value generated by
the runtime.
While the initial version of this testing transform only supports
instrumenting assignments, it should be simple to teach it to do more
interesting rewrites.
There's a driver script available in SWIFT_BIN_DIR/lldb-check-expect to
simplfiy the process of launching and testing instrumented programs.
rdar://36032055
This means moving the output path into SupplementaryOutputPaths, and
using the same sort of diagnostic dispatching that serialized
diagnostics use. This is part of what's needed to run the migrator
in batch mode.
- Outlaw duplicate input files, fix driver, fix tests, and add test.
- Reflect that no buffer is present without a (possibly pseudo) named file.
- Reflect fact that every input has a (possible pseudo) name.
- Break up CompilerInstance::setup.
Don't bail on dups.
- Moved getOutputFilenamesFromCommandLineOrFilelist & readOutputFileLIst to better places in the file.
- Capitalization changes.
- Make actionIsImmediate static.
- Add braces around sections of CompilerInstance::setup to clarify scopes of local variables.
