It has an extension .package.swiftinterface and contains package decls
as well as SPIs and public/inlinable decls. When a module is loaded
from interface, it now looks up the package-name in the interface
and checks if the importer is in the same package. If so, it uses
that package interface found to load the module. If not, uses the existing
logic to load modules.
Resolves rdar://104617854
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
Introduce a new behavior when printing references to modules with an
`export_as` definition. Use the `export_as` name in the public swiftinterface
and the real module name in the private swiftinterface.
This has some limits but should still be an improvement over the current
behavior. First, the we use the `export_as` names only for references to clang
decls, not Swift decls with an underlying module defining an `export_as`.
Second, we always print the `export_as` name in the public swiftinterface,
even in the original swiftinterface file when the `export_as` target is likely
not know, so that generated swiftinterface is still broken.
This behavior is enabled by the flags `-enable-experimental-feature ModuleInterfaceExportAs`
or the `SWIFT_DEBUG_USE_EXPORTED_MODULE_NAME_IN_PUBLIC_ONLY` env var. We may
consider turning it on by default in the future.
rdar://98532918
In AliasModuleNames, avoid wrongfully printing aliased names for modules
that were not aliased. This can happen in the case of modules indirectly
imported via a reexport.
rdar://102262019
Ambiguities are introduced in generated swiftinterfaces when a type
shares a name with a module (i.e. XCTest). This workaround uses the
module-alias feature to avoid these ambiguities. Writing module
references with a distinguishable prefix should allow normal
type-checking to avoid the usual ambiguities.
We should still aim for a proper fully-qualified named syntax, but this
may help in the mean time.
rdar://101969500
* [SILOptimizer] Add prespecialization for arbitray reference types
* Fix benchmark Package.swift
* Move SimpleArray to utils
* Fix multiple indirect result case
* Remove leftover code from previous attempt
* Fix test after rebase
* Move code to compute type replacements to SpecializedFunction
* Fix ownership when OSSA is enabled
* Fixes after rebase
* Changes after rebasing
* Add feature flag for layout pre-specialization
* Fix pre_specialize-macos.swift
* Add compiler flag to benchmark build
* Fix benchmark SwiftPM flags
are printed with the `any` keyword.
For now, printing `any` is off by default in order to turn on explicit
existential types with minimal changes to the test suite. The option
will also allow control over how existential types are printed in
Swift interfaces.
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
For more fine grained annoations. For now, it's handled as the same as
'Keyword' name kind.
Fix an issue where 'extension' wasn't marked as "keyword".
Also, move 'static' priting out of 'SkipIntroducerKeywords' guard
because 'static' is not an declaration introducer.
The patch introduces a new setting instead of changing existing settings
because the generated interfaces in the IDE have slightly different
requirements; the extended type there is unconditionally not printed
qualified (even if it is ambiguous). This is likely because the
ambiguity heuristic is very weak; it doesn't even do name lookup.
Simplifying that logic would be nice, but then we'd need to update
a bunch of IDE/print* tests and end up with more more visual clutter
in the IDE.
Introducing the new setting means we can change the behavior for
swiftinterface files without affecting the behavior for IDE interfaces.
Fixes rdar://79093752.
Since 865e80f9c4 we are keeping track of internal closure labels in the closure’s type. With this change, wer are also serializing them to the swiftmodules.
Furthermore, this change adjusts the printing behaviour to print the parameter labels in the swiftinterfaces.
Resolves rdar://63633158
If have a function that takes a trailing closure as follows
```
func sort(callback: (_ left: Int, _ right: Int) -> Bool) {}
```
completing a call to `sort` and expanding the trailing closure results in
```
sort { <#Int#>, <#Int#> in
<#code#>
}
```
We should be doing a better job here and defaulting the trailing closure's to the internal names specified in the function signature. I.e. the final result should be
```
sort { left, right in
<#code#>
}
```
This commit does exactly that.
Firstly, it keeps track of the closure's internal names (as specified in the declaration of `sort`) in the closure's type through a new `InternalLabel` property in `AnyFunctionType::Param`. Once the type containing the parameter gets canonicalized, the internal label is dropped.
Secondly, it adds a new option to `ASTPrinter` to always try and print parameter labels. With this option set to true, it will always print external paramter labels and, if they are present, print the internal parameter label as `_ <internalLabel>`.
Finally, we can use this new printing mode to print the trailing closure’s type as
```
<#T##callback: (Int, Int) -> Bool##(_ left: Int, _ right: Int) -> Bool#>
```
This is already correctly expanded by code-expand to the desired result. I also added a test case for that behaviour.
When generating a module interface, emit `#if` around any declarations
that are tied to specific, named language features. This allows module
interfaces to be processed by older Swift compilers that do not
support these newer features, such as async/await or actors.
The amount of effort required to correctly handle a new kind of
feature varies somewhat drastically based on the feature itself. The
"simple" case is where a particular declaration can only exist if a
feature is available. For example, and `async` declaration is fairly
easy to handle; a `@_marker` protocol's conformances are not.
Fixes rdar://73326633.
Clang types need special treatment because multiple Clang modules can contain the same type declarations from a textually included header, but not all of these modules may be visible.
This fixes
https://bugs.swift.org/browse/SR-13032
The newly added test breaks without this fix.
When DiagnosticEngine needs to diagnose something about an imported declaration, it uses ASTPrinter to print the declaration’s interface into a source buffer and then diagnoses it there. However, this code only printed public declarations, so it failed to account for features like `@testable import` which allow less-than-public declarations to be imported. Errors involving these declarations would therefore be diagnosed at <unknown>:0.
This commit changes DiagnosticEngine to determine the access level of the declaration it needs to print and, if it is below `Public`, instead prints a separate interface whose minimum access level is low enough to include the desired declaration.
