This change ensures that when loading some module dependency 'Bar' which has a package-only dependency on 'Foo', only the following clients attempt to resolve/load 'Foo':
- Source compilation with package-name equal to that of 'Bar'.
- Textual interface compilation of a *'package'* interface with package-name equal to that of 'Bar'.
Ensuring that the following kinds of clients do not attempt to resolve/load 'Foo':
- Source compilation with package-name different to that of 'Bar'
- Textual interface compilation of a public or private interface, regardless of package name.
This fixes the behavior where previously compilation of a Swift textual interface dependency 'X' from its public or private interface, with an interface-specified package-name, from a client without a matching package-name, resulted in a lookup of package-only dependencies of modules loaded into 'X'. This behavior is invalid if we are not building from the package textual interface, becuase the module dependency graph is defined by the package name of the source client, not individual module dependency package name. i.e. In-package module dependencies are resolved/loaded only if the parent source compile matches the package name.
Resolves rdar://139979180
A begin_apply token may be used by operands that do not end the coroutine:
mark_dependence.
We need an API that gives us only the coroutine-ending uses. This blocks
~Escapable accessors.
end_borrow is considered coroutine-ending even though it does not actually
terminate the coroutine.
We cannot simply ask isLifetimeEnding, because end_apply and abort_apply do not
end any lifetime.
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
We shouldn't be attempting to append SourceFiles
to the module after-the-fact for syntactic macro
expansion, refactor things such that the SourceFile
is created alongside the ModuleDecl.
To allow feature build settings to be composed more flexibly, allow an
`-enable-upcoming-feature` flag to be overridden by a
`-disable-upcoming-feature` flag. Whichever comes last on the command line
takes effect. Provide the same functionality for `-enable-experimental-feature`
as well.
Resolves rdar://126283879.
Code review identified some incorrect UNIMPLEMENTED_CLONEs in DeclAttribute (thank you
Hamish and Rintaro). Fix those, and make sure this can't happen again by checking the type
signatures of clone() in every DeclAttribute subclass.
The Clang importer was directly calling into the parser to parse the
attribute (or modifier) within swift_attr. Aside from being gross, this
isn't possible with ASTGen.
Instead, teach ParseSourceFileRequest to deal with modifiers in the
same way that the Clang importer was hardcoding, and have the Clang
importer pull the attributes/modifiers off of the "missing"
declaration introduced by the request.
One benefit of this approach is that we're only parsing each
swift_attr source buffer once, then cloning the attributes each time
it's used, so we should be doing less work overall.
Fixes rdar://139119159.
This PR adds a variadic macro that builds a SwiftAttr string containing
the names of the template type parameters that need to be escapable for
the type to be considered escapable. It also adds logic to interpret
this annotation.
rdar://139065437
Now that ASTGen should be able to generate most Swift code. Let's
remove "legacy parser" call-in, and remove the unhealthy cyclic
dependency between lib/Parse and ASTGen.
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
Property descriptors for static properties were only recently introduced with
SE-438. Since these symbols are not present in Swift libraries that were
compiled with earlier versions of the compiler, it is not safe for
`#_hasSymbol` to check for the property descriptor symbols, since they can be
absent at either link time or runtime.
Resolves rdar://139749275.
The `-include-submodules` flag causes the synthesized interface to include
implicit Clang submodules of the module being printed. Since these are
automatically made visible when importing the corresponding top-level module,
it's often useful to have them present in the same synthesized Swift
interface instead of having to make separate invocations to get each
submodule separately.
The `-print-fully-qualified-types` causes type names to be printed with
full module qualification. This is useful when using the synthesized
interface for some other kind of analysis, because it ensures that all
type references explicitly indicate which module they came from, instead
of having to guess scoping and import resolution rules to figure out
which module a reference comes from.
