forked from apple/swift
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] swiftwasm from main #5435
Merged
Merged
Conversation
This file contains 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
…eCollection append methods
Verifying SILGen causes `loadAllMembers` to be run, which in turn ends up actually creating the parent PBD of each `VarDecl` in this test. Without verification, we never deserialize that PBD and thus end up with `class` instead of `static` as we should. That's incorrect, but it's an existing failure (rdar://105239467). Resolves rdar://109037827.
We should only be suggesting `Copyable` after `~` in an inheritance clause, in accordance with [SE-0390](https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md) rdar://109063223
…that only constraints one of two primary associated protocol types When completing, we call `getExistentialType` on the contextual type to get a nice and concise description of the contextual parameter’s type that doesn’t contain archetypes and which we can also serialize into a USR so we are able to calculate type relations for code completion results from the code completion cache. When completing in a position that has a contextual type which only constrains one of two primary associated protocol types, this fails because `getExistentialType` (which calls `getDependentUpperBounds`) tries to form a `ParameterizedProtocolType`, which fails since not all primary associated types have been constrained. AFAICT the fix here is to just fall back to the default behavior of returning the plain protocol type instead of `abort`ing. rdar://108835466
add test for warnings emitted when missing consuming attribute use -emit-sil in mock SDK tests for better coverage
…singRecord` for header printing This better matches what the clang importer does normally, avoids a Clang issue where `getPreprocessedEntitiesInRange` returns incorrect results, and avoids the need to enable the preprocessor record. This then lets us re-enable `print_clang_headers.swift`. rdar://102151774
CI has updated macOS and we should no longer have the issue of dyld stubs using our nonstandard argument registers. rdar://102912772
Ref: rdar://108945440
Share the same expansion logic between ASTGen and SwiftCompilerMessageHandling
Add test for api-digester loading a module with package name
You can overload a function based on its `async`-ness, and resolution is carried out based on async-ness of calling context. But during protocol conformance checking, for an `async` requirement we were accidentally choosing the non-`async overload instead of the `async` one. The `async` one is the choice people would expect, since the `async` requirement is in essence the "context" that forwards to the underlying witness. This intended behavior is also inferred from: apple#40088 The problem boiled down to a bad check when categorizing the witness matches prior to ranking them. Resolves rdar://109135488 / apple#60318
[Test] Reenable custom_rr_abi.swift.
[Macros] Update for SwiftSyntaxMacroExpansion module
[Test] Avoid verifying SILGen in cursor info test
[Concurrency] Adopt stable keyword consuming instead of __owned
Originally this was a method to determine if we had emitted a diagnostic when running our gather visitor. It was pretty footgunny since one could easily forget to set it. Instead of doing that, we now maintain a counter in the diagnostic emitter that counts how many diagnostics we have emitted and use that to determine if during the walk if we emitted any additional diagnostics.
Previously we could miss the scopes present in if/switch expressions if they were nested in another expression, such as an AssignExpr. Fix the logic such that we properly walk over a given expression looking for if/switch scopes, the same as what we do for closures. rdar://109192116
…nt-type [CodeComplete] Offer completions after `~` in an inheritance clause
Witness selection should pick exact matches for effect overloads
…ssoc-types-specified [CodeCompletion] Don’t crash when completing in a parameter position that only constraints one of two primary associated protocol types
…ebcf07577c0d56525b8 [move-only] Eliminate dead field.
A bug was preventing you from writing `discard self` in a consuming method of a generic noncopyable type. The main cause was the `isPureMoveOnly` ignored unbound generic types, claiming none of them are noncopyable. Then I also needed to pass the contextual type with the vars bound to the type checker. rdar://108975216
Subscripts today don't support any form of ownership specifier for its parameters Since noncopyable types require such a specifier, it's not helpful to emit an error suggesting to add the specifier. rdar://109233314
allow `discard` in generic noncopyable type
improve error when using noncopyable type with subscript
…tests Add a few basic smoke test benchmarks for the default RangeReplaceableCollection append methods
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )