The default code generation model for Embedded Swift is "inlinable".
DeferredCodeGen made the default code generation model
"implementation", and there was no spelling for "interface".
Introduce the experimental feature CodeGenerationModel=<model>, which
can be any of those three options. The default remains "inlinable", but
one can now specify "implementation" (which keeps most everything in
SIL) or "interface" (which only keeps the generic things in SIL). The
"interface" mode is more like non-embedded Swift for non-generic
declarations, emitting them into the IR (only) but not SIL. Generic
declarations would remain in SIL.
Implements rdar://172433062.
Add support for named location markers in the diagnostic verifier's
-verify mode. A marker is defined by placing `// #name` in a comment
and referenced with `@#name` in expected-diagnostic comments.
This enables stable references to diagnostic locations that don't break
when lines are added or removed, and supports cross-file references
where an expected-error in one file references a marker in another.
This adds support for the following case:
```
expected-expansion@:1:2{{
expected-warning@3{{foo}}
expected-sometimes-warning@4{{bar}}
expected-warning@5{{foobar}}
}}
```
This would work when parsing the additional "sometimes-" prefix, but for
invokations that didn't parse that prefix the "}}" on that line would
close the expansion, and `expected-warning@5{{foobar}}` would be parsed
as a top level statement.
Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload of test SDKSettings files need to be updated across several repositories and forks and branches. It’s tedious to be careful to update those with real values so that the tests are properly regression testing older SDKs. It’s important to be careful so that the tests are accurate, e.g. to prevent the scenario where DarwinSDKInfo starts reading a new key out of SDKSettings and assumes that it’s always available everywhere, when in reality it was only added a few releases ago and will break with older SDKs. If the test SDKSettings files continue to be updated ad hoc, it’s going to be really easy to copy/paste a default value everywhere, and then clients will see incorrect behaviors with the real SDKs, or even compiler crashes if the key is unconditionally read. Preemptively add all of the maybe-possibly-compiler relevant keys to the test SDKSettings files from the real SDKs so that the test files are an accurate representation and shouldn't need to be touched in the future. Where the test SDKSettings have intentionally doctored data, add a Comments key explaining what is changed from the real SDK, and alter the SDK name with a tag indicating the change.
rdar://168700857
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
In multi-threaded WMO builds, the frontend didn't properly handle per-file
supplementary outputs specified via output file maps or command-line
arguments.
This enables swift-driver to use -supplementary-output-file-map for
per-file outputs in multi-threaded WMO, instead of generating multiple
individual flags that the frontend rejects.
It's useful to know where a conformance is coming from when doing semantic
analysis. The main motivating use case is this: imagine a module that
declares a type:
```swift
// SomeTypeModule
struct SomeType {}
```
Then a second module that adds a conformance:
```swift
// SomeTypeConformanceModule
extension SomeType: @retroactive Codable {
// implementation of requirements
}
```
Then a third module that uses that conformance:
```swift
import SomeTypeModule
import SomeTypeConformanceModule
func f() {
_ = try? JSONEncoder().encode(SomeType())
}
```
There's currently nothing in the printed AST that indicates that the import
of `SomeTypeConformanceModule` is required. Printing the declaring context
for conformances lets us get that signal from the substitution map at the
call site in `f()`.
Also removed a place where we redundantly output `retroactive`.
By calling `printCommon` twice, this inserts a JSON object into
another JSON object without a key. This asserts inside LLVM's
JSON helper, but only if the compiler is built with assertions
enabled (which Xcode's compiler doesn't).
This also fixes the S-expression version, which is similarly busted:
```
(pattern_entry
(async_let type="Int" (pattern_any type="Int")
(original_init=call_expr type="Int" ...
```
This avoids infinite recursion when a function captures itself; e.g.,
```swift
func foo() {
func bar() {
bar()
}
bar()
}
```
It also just avoids printing unnecessarily verbose information,
since those decls would have already been dumped elsewhere in the
tree.
`ModuleType`s show up in some rare places, like the left-hand-side of
a `DotSyntaxBaseIgnoredExpr` for a module-qualified function call.
ASTMangler does not support these because they're not real types.
`verifyUnknown()` and `verifyUnrelated()` would not remove the
diagnostics after reporting their errors, leading to the same
diagnostics then being emitted a second time. This removes them from the
list after emitting them, just like `verifyFile()` does.
This makes it more explicit and consistent, which are good properties
for test output. It makes it easier both for humans and
update-verify-tests to see what exactly is going on. This does not
affect how diagnostics are displayed to users normally.
This won't affect diagnostic printing, as the diagnostic engine checks
the GeneratedSourceInfoKind and stops expanding if it's an
AttributeFromClang kind. This helps the diagnostic verifier expand to
the original location in source code however.
...-verify-additional-file
It's not expected that users add macro expansion buffer names to
-verify-additional-file. The recommended approach is to add the actual
source file that the macro was expanded in, and use expected-expansion.
This adds the -Rmacro-expansions flag. It provides similar functionality
to -dump-macro-expansions, but instead of dumping the macro expansion to
stderr, it emits it line by line as remarks. This is useful for testing
with -verify, where both macro expansion content and warnings need to be
tested at the same time.
There are a few places in the AST dumper where it prints hexadecimal
pointer addresses. This can be useful when dumping nodes in the
debugger, but it makes the output nondeterministic when can cause
problems for build systems that cache outputs.
In the JSON format only, replace these pointers with the string
`"replaced-pointer-XX"`, where `XX` is an increasing integer ID.
We keep track of the pointers that have been replaced so that the
same pointer always maps to the same ID; this means that those
nodes can still be related to each other when reading the AST
later, if needed.
We have long switched to delegate the checking of whether a module is up-to-date to the build system (SwiftDriver) and stopped serializing file dependencies for interface-built binary modules.
Resolves rdar://162881032
`llvm::Twine` is not valid after the end of the statement. Pass it
directly as a parameter without storing it in a local variable to
prevent UAF. Also updates DiagnosticVerifier tests to capture all
relevant output.
This commit adds -sil-output-path and -ir-output-path frontend options that
allow generating SIL and LLVM IR files as supplementary outputs during normal
compilation.
These options can be useful for debugging and analysis tools
workflows that need access to intermediate compilation artifacts
without requiring separate compiler invocations.
Expected behaviour:
Primary File mode:
- SIL: Generates one .sil file per source file
- IR: Generates one .ll file per source file
Single-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates one .ll file for the entire module
Multi-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates separate .ll files per source file
File Maps with WMO:
- Both SIL and IR outputs using first entry's naming, which is
consistent with the behaviour of other supplementary outputs.
rdar://160297898
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
When the diagnostic verifier encounters a fatal error, it reports:
<unknown>:0: error: fatal error encountered while in -verify mode
If we capture this, and fail to match this against an expected-error,
the diagnostic verifier complains:
<unknown>:0: error: unexpected error produced: fatal error encountered while in -verify mode
<unknown>:0: error: diagnostic produced elsewhere: fatal error encountered while in -verify mode
The current workaround is to use -verify-ignore-unknown, but that in
turn may mask actual errors coming from unknown source locations.
Ignoring these errors about errors removes the need for that workaround.
If someone has configured their build to add some vendor macro, for
example, the vendor macro will appear in `customConditions`, which will
make the test fail.
Modify the test slightly to check for `customConditions` containing
`"SOMETHING"`, instead of only being `["SOMETHING"]` and nothing else.
This should still allow the test to pass in Swift CI, but allows vendor
macros to work too.
Introduce the ability to form a `StaticBuildConfiguration` from
language options. Add a frontend option `-print-static-build-config`
to then print that static build configuration as JSON in a manner that
can be decoded into a `StaticBuildConfiguration`.
Most of the change here is in sinking the bridged ASTContext queries
of language options into a new BridgedLangOptions. The printing of the
static build configuration only has a LangOptions (not an ASTContext),
so this refactoring is required for printing.
Parser errors with large Swift module map files can be hard to diagnose.
Refactor the parser to return an llvm::Error so clearer diagnostics can
be passed to the user.
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Optional language features don't have a specific "-enable-*" flag, because
they're rare and don't fit the same upcoming/experimental distinction. Add
a flag_name field to provide the flag name as well.
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
Doug Gregor
Alejandro Alonso
Hiroshi Yamauchi
Saleem Abdulrasool
Henrik G. Olsson
Desel72
Tony Allevato
Anthony Latsis
Henrik G. Olsson
Ian Anderson
Ben Cohen
Ben Cohen
Ryan Mansfield
Artem Chikin
John Hui
Daniel Rodríguez Troitiño
Richard Howell
Allan Shortlidge
Hamish Knight
Erik Eckstein
Arnold Schwaighofer