Merge 5.7 2022-04-30 #4495
Merged
Merge 5.7 2022-04-30 #4495
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
Without these spaces the items break out of the listing. With them they look correct and are aligned with the `*`
Rename 'addItemWithoutDefaultArgs' to 'shouldAddItemWithoutDefaultArg' because this function only returns bool indicating "should or not". (cherry picked from commit 0dad5ff)
For ObjC NS_OPTIONS/NSDictionary parameters with some specific names, ClangImporter implicitly adds default values. However, that behavior is sometimes not really desirable. For example, for: -(void)addAttributes:(NSDictionary *)attrs; 'attrs' is defaulted, but calling 'addAttributes()' doesn't make any sense. In code-completion, consider such paramters non-defaulted. rdar://89051832 (cherry picked from commit 2b9ee76)
In ExprContextAnalyzer, when looking up members, some implicit members weren't populated. Ensure all implicit members available by force synthesizing them. rdar://89773376 (cherry picked from commit 4e62140)
…al method on `AnyObject`
- These tests verify updated behaviour of existing API, and should check for availability first.
The placement new operator is only available when `<new>` has been included. Add the missing include to the header to allow us to get the definition of the placement new allocator. This allows us to remove the workaround that was there for Windows, and should hopefully repair the Android build as well. Thanks to @grynspan for helping identify the underlying issue! (cherry picked from commit 312f258)
The android build seems to find a conflict in the overload set for the placement new operator due to the custom new overload. Provide the indicator that we want the placement new allocator by using the explicitly namespaced spelling. Thanks to @buttaface for reporting the build failure. (cherry picked from commit ce6d97d)
Include the new header for placement new. (cherry picked from commit c5e99e4)
Apply a blanket pass of including `new` for the placement new allocation and namespacing the call to the global placement new allocator. This should repair the Android ARMv7 builds. (cherry picked from commit a8b0ee2)
…on even when the compiler does not support the C++17 over-aligned new feature (and avoid using new anyway since it might be overridden by something else in the process.) (cherry picked from commit 3f24533)
…tries. This was benign with `Sendable`, but is not benign for the `Encodable` and `Decodable` synthesis for distributed actors, which results in a crash in TBD generation. Fixes rdar://92008955.
…mous tag.
In C, one can provide a typedef name for an anonymous tag declaration in
one shot, e.g.,
typedef struct {
double x, y
} Point;
In this case, there are effectively two declarations at the C level:
the typedef and the struct. The Clang importer was only taking
attributes from the anonymous struct (i.e., the tag) and not from the
typedef. However, any attributes put before the `typedef` should apply
as well... so consider those, too.
For now, only do this for `swift_attr` attributes, because we're
seeing this primarily with `Sendable` annotations. In the future, we
can look to generalizing it, but that could have source-breaking
consequences.
Fixes rdar://91632960.
This would help to diagnose the initial point where constraint system has been determine to be "too complex" (cherry picked from commit ef2f24b)
…ex' failures (cherry picked from commit a40e8e8)
(cherry picked from commit 7869b73)
This reverts commit da0a331.
The main function is different from other function resolutions. It isn't being called from a synchronous or asynchronous context, but defines whether the program starts in a synchronous or async context. As a result, we should not prefer one over the other, so the scoring mechanism shouldn't involve the async/sync score when resolving the main function. This patch adds a constraint solver flag to ignore async/sync context mismatches so that we do not favor one over the other, but otherwise use the normal resolution behavior.
Using `resolveValueMember` can result in the wrong, or unrelated main
functions being selected. If an error occurs while resolving, such as an
ambiguous resolution, the solution will contain everything called
'main'. During the resolution, the `BestOverload` will not be set, so
the code skips down to iterating over the member decls and selecting the
first declaration that is a `MainTypeMainMethod`.
The order of candidates in the failure state is related to the order
that the declarations appear in source. The selected and potentially
unrelated main function is called from `$main`. The call in the
expression will then detect the invalid state later.
When only a single main function could exist in a given context, this
was not a problem. Any other possible solutions would result in an
error, either due to a duplicate declaration, or from calling an
unrelated function. When we introduced the asynchronous main function,
the resolution can be ambiguous because we allow asynchronous overloads
of synchronous functions. This enables us to legally write
```
struct MainType {
static func main() { }
static func main() async { }
}
```
From the perspective of duplicate declarations, this is not an issue. It
is, however, ambiguous since we have no calling context with which to
break the tie.
In the original code, this example would select the synchronous main
function because it comes first in the source. If we flip the
declarations, the asynchronous main function is selected because it
comes first in the source.
Instead, using the constraint solver to solve for the correct overload
will ensure that we only get back a valid main function. If the
constraint solver reports no solutions or many solutions, we can emit an
error immediately, as it will not consider unrelated functions.
Changing the overload resolution behavior results in the ordering that `main` and `$main` are typechecked. If there is an error in parsing or sema before we have typechecked these two functions, we get weird errors about `$main` calling the main-actor `main` function being invalid. This is because we have already set the `@main` attribute to invalid, so we don't recognize the `$main` context as being a main entrypoint. The error message compounds to making a confusing situation worse given that `$main` is implicit. So by ignoring the failed `@main` attribute, we still annotate the `$main` and `main` function as being on the main actor, so everyone is happy in that respect. To get the nasty behavior, you can forget to pass `-parse-as-library` with this commit removed.
This patch contains the updates for the tests. The merge removes the `-async-main` flag, so the tests using that flag fail on that. Additionally, the tests reflect the newer behavior of the main resolution. `async_main_resolution` verifies that we're not preferring an async function over a synchronous function, and vice versa. This is also verified in `where_clause_main_resolution`, where we select a main function using various configuration typealiases. Finally, we only select a valid, usable main function. The old machinery could select one sort of at random (technically it selected the first overload declared in the source file) if an error occurred. Errors that resulted in this behavior included a missing valid function, or an ambiguous overload. In the case of the missing valid function, the function returned would be from an invalid location if one existed, which was called from `$main`. `$main` had sufficient context to realize that the main function being called was not valid, and would emit an error saying why. It would be better to realize that we're not getting a valid main function earlier, and later we can emit notes saying why each function called main could not be selected.
This sets up the type constraints as equalities with a type variable. This is apparently more performant in the solver, so that should be good. It doesn't have additional effect on the resulting behavior.
The bit twiddling done by this test falls afoul of ptrauth on ARM64e. We don't support pre-stable Swift ABI code on ARM64e anyway, so just disable the test there. rdar://92469961 (cherry picked from commit a0dec1d)
…to-null [5.7][🍒] Back out "Fix jump-to-null issue for ObjC async calls."
…s-.5.7 [5.7][ConstraintSystem] "too complex" diagnostic improvements
[5.7][ConstraintSystem] Extend availability check to cover unavailable ext…
…ain-resolution [🍒5.7] Use Disjunction Constraint to find main function
… extensions that have been declared explicitly unavailable. The existing logic only checked for an unavailable attr in the direct attributes of the decl. Resolves rdar://85429703
…etadata-fix [5.7][IRGen] Restore the old code path for emitting existential type metadata for plain protocol and protocol composition types.
…t-arm64e-5.7 [5.7][Test] Disable objc_old_swift.swift on ARM64e.
…ilability-unavailable-extension-5.7 [5.7] Sema: Skip members of unavailable extensions for -require-explicit-availability
🍒 Merge pull request swiftlang#58388 from al45tair/eng/PR-91831405
If we encounter any multi-paylaod enum descriptors with bad data, we can end up writing off the end of the bitmask allocation, causing heap corruption. Add range checks to let us fail gracefully instead. rdar://91423283 (cherry picked from commit a6de05b298278f5d3cc6e6f4b98994a458c28f47)
…-function-conversions-5.7 Downgrade missing @sendable to a warning in Swift 5.x mode.
[5.7][RemoteMirror] Add bounds checking to BitMask operations.
|
Is the macOS build failure sporadic or expected here? |
|
@MaxDesiatov Clock API tests are a little bit flaky due to time-based checks, so the failure is sporadic |
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.
No description provided.