Types where pack expansion required nested subsitution could cause the compiler to crash rather than properly expanding the pack. Both for populated types and infinityly expanding types which should generate an error.
This expands the support for these to generate more errors and populated types, and correspondingly expands the test suite
Updates the message to use the type or ValueDecl instead of saying 'this' on 'Found this candidate' messages to provide more information where possible in selecting overloads
Per comment during draft iteration uses getInterfaceType and adds removeSelfParam to ValueDecl.t
Migrate to calling interfaceType and remove SelfParam
Update tests to reflect type information in ambiguity resolution
All but 5 tests now passing. Those 5 either do not refer to overloading errors or do pass even when modified to accept type specification
Move implementation to ValueDecl now that tests largely pass
All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
Currently we create an absolute one -- this prevents to use the partial
toolchain before the installation phase (namely for configurations that
run Swift tests on a different device than the builder).
Addresses rdar://160277259
When storing a closure with type `() throws(any Error) -> ()` as
a fully opaque error, we want to leave it unchanged, instead of
re-abstracting it to throw the error indirectly. Thus, we had
a special carveout here.
However, the carveout was too broad, because if the thrown error
type contained type parameters, the resulting AbstractionPattern
was invalid.
While fixing this I realized this entire hack is unsound in some
cases, if you view the same value as a `() throws(U) -> ()` vs
an `() -> throws(any Error) -> ()`.
Perhaps we should always box the thrown error when maximally
abstracting a closure, but that would also be an ABI break.
- Fixes https://github.com/swiftlang/swift/issues/84051
In libc++, `std::optional` inherits from several mixin base types. Some of those base types do not declare a deleted copy constructor for non-copyable value types, which works fine because clients are not supposed to use those base types directly from C++.
Swift, however, imports all of the transitive base types when importing a C++ type. As part of this, ClangImporter will attempt to instantiate e.g. `std::__optional_copy_assign_base<NonCopyable>`, and will fail with a hard error while doing so.
rdar://152718041
Make sure they are excluded from the reflection metadata (although in
the future we want to make sure indirect fields are included). Make sure
the users cannot refer to the anonymous field, only its members.
If there are no explicit concurrency attributes, isolated parameters,
or captures associated with the closure it should infer `nonisolated(nonsending)`
for the parent conversion injected by the solver (this conversion is injected
because the solver cannot check captures to elide it).
The change pushes `isIsolationInferenceBoundaryClosure` check down
with added benefit of getting preconcurrency context from the parent.
This change re-enables the new semantic of looking up Swift Overlay modules only for "visible" clang modules.
We have investigated the failures we were seeing with this change enabled and addressed them with project-side fixes.
After #83959, we expect noncopyable OpenExistential evaluations to have an outer
FormalEvaluationScope to forward to. However, there was no such
FormalEvaluationScope while emitting a consuming switch subject, causing an assertion
failure to trip. Add a FormalEvaluationScope tightly scoped around the evaluation in
this case, fixing rdar://160080337.
It's permitted for a `witness_method` instruction to have multiple
type-dependent operands. This can happen when for example when one
local archetype is defined in terms of another.
rdar://159211502
- Turn `BindExtensionsForIDEInspectionRequest` into the main extension
binding request.
- Change `ExtendedNominalRequest` such that it's no longer what
extension binding calls into to do the name lookup, instead it calls
directly into `computeExtendedNominal`. `getExtendedNominal` can
then be the entrypoint for `ExtendedNominalRequest` and assumes that
extension binding has already run. This avoids needing to fake the
dependency relationship in the DeclChecker.
This will mainly be useful once extension binding is fully
requestified, but even now it's a good idea to ensure module loading
isn't kicking name lookup.
I missed this in my previous patch that moved extension binding until
after we've mutated the AST for IDE inspection, this ad-hoc extension
binding logic is no longer necessary.
