forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
Merge main 2023-06-20 #5537
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
Merged
Merged
Merge main 2023-06-20 #5537
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
…esources/linux This is a preparatory change for adding a static executable support for WASI
wasi-wasm32 support in build system was added in b1236e9 but we forgot to add it to the host for the case when we are building the standalone stdlib for the target.
The function is defined in Task.cpp with a void return type, but referenced in Task.swift with an pointer return type.
Adds a new swift-frontend flag to allow users to choose which calling convention is used to make c function calls. This hidden flag is called `-experimental-platform-c-calling-convention`. This behavior is needed to workaround rdar://109431863 (Swift-frontend produces trapping llvm ir for non-trapping sil). The root cause of this issue is that IRGen always emits c function calls with llvm's default C calling convention. However clang may select a different (incompatible) calling convention for the function, eventually resulting--via InstCombine and SimplifyCFG--in a trap instead of the function call. This failure mode is most readily seen with the triple `armv7em-apple-none-macho` when attempting to call functions taking struct arguments. Example unoptimized ir below: ```llvm-ir call void @bar([4 x i32] %17, i32 2), !dbg !109 ... define internal arm_aapcs_vfpcc void @bar( [4 x i32] %bar.coerce, i32 noundef %x) ``` In the future it would be better to use the clang importer or some other tool to determine the calling convention for each function instead of setting the calling convention frontend invocation wide. Note: I don't know for sure whether or not clang should be explicitly annotating these functions with a calling convention instead of aliasing C to mean ARM_AAPCS_VFP for this particular combination of `-target`, `-mfloat-abi`, and `-mcpu`.
- Renames ExperimentalPlatformCCallingConvention to PlatformCCallingConvention. - Removes non-arm calling convention support as this feature is working around a clang bug for some arm triples which we hope to see resolved. - Removes misleading MetaVarName from platform-c-calling-convention argument. - Replaces other uses of LLVM::CallingConv::C with IGM.getOptions().PlatformCCallingConvention().
This constraint is useful in more places than closures because it gives a way to provide a "fallback type" without it having effect on inference.
…sion Binding of pack expansion types is delayed until solving but use of `Defaultable` was preventing it from being considered early because that constraint impacts binding set ranking, switching to `FallbackType` constraint give us better semantics where pack expansion type variables are going to be bound as soon as they have a contextual type. Resolves: rdar://110819621
If we have an identifier followed by either `[` or a generic argument list, avoid turning it into a binding pattern, as that would be invalid. This is similar to the existing rule we have where a following `(` prevents a binding pattern from being formed. This allows patterns such as `let E<Int>.foo(x)` and `let (y[0], x)` to compile, where `x` is treated as a binding, but no other identifier is. rdar://108738034
Add frontend flag for explicitly setting ccc
…3fc716c8f3b55bfd113d3972dc3bb6 [wasm][build] Recognize wasi-wasm32 as valid host
…ure-type-constraint [ConstraintSystem] Use fallback type constraint to default pack expansion
…5a694965ab652f57cbfead006a33d7 [static-stdlib] Move static-executable-args.lnk under stdlib/public/Resources/linux
…a1794d0cb5b29f35af64e90456b406
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.