Skip to content

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 16 commits into from
Jun 20, 2023
Merged

Merge main 2023-06-20 #5537

merged 16 commits into from
Jun 20, 2023

Conversation

kateinoigakukun
Copy link
Member

No description provided.

kateinoigakukun and others added 16 commits June 8, 2023 11:46
…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
@kateinoigakukun kateinoigakukun marked this pull request as ready for review June 20, 2023 05:32
@kateinoigakukun kateinoigakukun merged commit da67a99 into swiftwasm Jun 20, 2023
@kateinoigakukun kateinoigakukun deleted the katei/merge-main-2023-06-20 branch June 29, 2023 02:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants