Constraint resolution fix #84818
Closed
Constraint resolution fix #84818
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
differential thunks. Fixes #84365
…ble Clang modules 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.
…sending)` 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.
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.
…ptional<NonCopyable>` 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
…CPUTrace. This allows tracking async code execution throughout a task's lifetime. rdar://137230240
I missed this when changing the case body vars to be tail allocated, remove the use of `AllocateCopy`.
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 #84051
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
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
Migrate more tests
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 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
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.