There is no related test as we don't have reproducer code and we've seen
it only in the debugger, but I believe the fix is sound on its own.
rdar://106430304
Differentiate `internal` and `fileprivate` imports from
implementation-only imports at the module-wide level to offer a
different module loading strategy. The main difference is for non-public
imports from a module with testing enabled to be loaded by transitive
clients.
Ideally, we would only load transitive non-public dependencies on
testable imports of the middle module. The current module loading logic
doesn't allow for this behavior easily as a module may be first loaded
for a normal import and extra dependencies would have to be loaded on
later imports. We may want to refactor the module loading logic to allow
this if needed.
rdar://106514965
Realign the module loading behavior with the one of the package
access-level. If the package name is an empty string, don't accept other
modules with an empty package name as being part of the same module and
don't load package dependencies in such a case.
I don't think this logic is used in practice without merge-modules.
Let's still implement it for the configurations still using
merge-modules and for general consistency.
This is in preparation for wiring up debug info support for noncopyable
values. Originally this flag name made sense since it was set when we performed
consume operator checking. Now I am going to use it for noncopyable types as
well. I think the new name uses_moveable_value_debuginfo actually describes what
the flag is supposed to do, tell IRGen that the value may be moved since it
needs to use moveable value debug info emission.
Calling getImportedModules requires to list the desired kind of imports.
With the new kind of imports this has become cumbersome. Let's simplify
it by offering common sets of imports. Advanced call sites can still
list the desired imports explicitly.
* [Executors][Distributed] custom executors for distributed actor
* harden ordering guarantees of synthesised fields
* the issue was that a non-default actor must implement the is remote check differently
* NonDefaultDistributedActor to complete support and remote flag handling
* invoke nonDefaultDistributedActorInitialize when necessary in SILGen
* refactor inline assertion into method
* cleanup
* [Executors][Distributed] Update module version for NonDefaultDistributedActor
* Minor docs cleanup
* we solved those fixme's
* add mangling test for non-def-dist-actor
This modifies the ClangImporter to introduce an opaque placeholder
representation for forward declared Objective-C interfaces and
protocols when imported into Swift.
In the compiler, the new functionality is hidden behind a frontend
flag -enable-import-objc-forward-declarations, and is on by default
for language mode >6.
The feature is disabled entirely in LLDB expression evaluation / Swift
REPL, regardless of language version.
While a Swift program cannot directly utter one of the unique names
produced by the macro expansion context outside of the macro itself,
utilities such as type reconstruction require the ability to look up
these names. Note that various kinds of macros can introduce unique
names, and update the name lookup facilities for macro-generated names
to account for them.
Fixes rdar://106053984.
The previous behavior kept going even after we reported an invalid
swiftmodule. As such it ended up losing the precise invalid reason and
returned Malformed later on.
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
When loading a swiftmodule A, read its package information to tell if
the current client should load A's dependencies imports by a package
import. Only clients belonging to the same package as A should load
those dependencies, clients outside of the package likely don't have
access to those dependencies.
This is specific to swiftmodules as swiftinterfaces never display a
package-only import. Clients are unaware of package dependencies when
building against a swiftinterface.
rdar://106164813
Swiftmodules built by a mismatching compiler are loaded if the mismatch
is only on the last digit of the compiler version. In such a case, write
a remark directly to stderr to avoid showing this error in IDE but keep
it for debugging purposes.
rdar://105881894
`__shared` and `__owned` would always get mangled, even when they don't have any effect
on ABI, making it unnecessarily ABI-breaking to apply them to existing API to make
calling conventions explicit. Avoid this issue by only mangling them in cases where they
change the ABI from the default.
