When reading a swiftmodule that's part of the main module the compiler
should have access to all internal details. In that case, read the
underlying type to opaque types.
This was caught by `SILOptimizer/specialize_opaque_result_types2.sil`
which has a merge-module like behavior reading it sib files as input.
Clients of a resilient module using opaque types don't need access to
the underlying type unless it's used in an inlinable context. Plus, the
underlying type can reference internal details which can lead to crashes
when they reference implementation-only dependencies. To clean up this
behavior, let's only serialize the underlying type if used by an
inlinable function.
rdar://105128784
The macro name resolution in the source lookup cache was only looking at
macros in the current module, meaning that any names introduced by peer
or declaration macros declared in one module but used in another would
not be found by name lookup.
Switch the source lookup cache over to using the same
`forEachPotentialResolvedMacro` API that is used by lookup within
types, so we have consistent name-lookup-level macro resolution in both
places.
... except that would be horribly cyclic, of course, so introduce name
lookup flags to ignore top-level declarations introduced by macro
expansions. This is semantically correct because macro expansions are
not allowed to introduce new macros anyway, because that would have
been a terrible idea.
Fixes rdar://107321469. Peer and declaration macros at module scope
should work a whole lot better now.
Add a private discriminator to the mangling of an outermost-private `MacroExpansionDecl` so that declaration macros in different files won't have colliding macro expansion buffer names.
rdar://107462515
This is used to teach the checker that the thing being checked is supposed to be
uninitialized at the mark_must_check point so that we don't put a destroy_addr
there.
The way this is implemented is that we always initially add
assignable_but_not_consumable but in DI once we discover that the assign we are
guarding is an init, we convert the assignable to its initable variant.
rdar://106525988
On both input moduel source-files and interface files.
This currently yields dramatic scanning performance improvements at no cost - we do not require an AST during scan.
Implementation-only dependencies may be referenced from internal decls.
When that module is imported as @testable, clients see the internal
decls and may fail accessing them if the transitive implementation-only
dependencies are not loaded.
Let's consider such transtive implementation-only dependencies as
optional for @testable imports. As such, the compiler will attempt to
load them for test targets, and won't fail if the dependency is missing.
We can make these dependencies required for non-public imports, but it
could be project breaking to do so for implementation-only dependencies.
Considering them as optional is a decent compromise.
rdar://79459263
When using the -testable-import-module argument to insert a testable
import, there's no ImportDecl on which to show the diagnostics when
loading transitive dependencies. Clean up the logic to still load
dependencies in such a case.
A @testable import allows a client to call internal decls which may
refer to non-public dependencies. To support such a use case, load
non-public transitive dependencies of a module when it's imported
@testable from the main module.
This replaces the previous behavior where we loaded those dependencies
for any modules built for testing. This was risky as we would load more
module for any debug build, opening the door to a different behavior
between debug and release builds. In contrast, applying this logic to
@testable clients will only change the behavior of test targets.
rdar://107329303
The new diagnoseSerializedASTLoadFailureTransitive diagnose problems for
transitive dependencies only: missing dependency, missing underlying
module, or circular dependency.
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
