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
By default, the frontend tries to figure out if the built module is
likely to be distributed in some way, and uses that to decide whether
to include options that help with debugging (such as local search
paths). There's long been a -serialize-debugging-options that forces
those options to be included even when it looks like a framework is
being built, but the opposite has been absent until now.
Note that both of these options are still /frontend/ options, not
driver options, which means they could still change in the future.
(I'd really like to get to a point where debugging doesn't need to
sniff these options out from the module this way, but there are some
complications we'd need to work out. Swift 1 expediency coming back to
cause trouble again.)
rdar://problem/37954803
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
* [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.
