Skip to content

Merge main 2022-05-27 #4596

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 91 commits into from
May 27, 2022
Merged

Merge main 2022-05-27 #4596

merged 91 commits into from
May 27, 2022

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented May 27, 2022

No description provided.

kateinoigakukun and others added 30 commits April 3, 2022 07:00
WebAssembly doesn't reserve low addresses but without "extra inhabitants" of
the pointer representation, runtime performance and memory footprint are
worse. So assume that compiler driver uses wasm-ld and --global-base=1024 to
reserve low 1KB.
The `SWIFT_COMPILER_VERSION` define is used to stamp a vendor’s version number into a Swift compiler binary. It can be queried from Swift code using `#if _compiler_version` and from Clang by using a preprocessor definition called `__SWIFT_COMPILER_VERSION`. These are unsupported compiler-internal features used primarily by Apple Swift.

In Swift 1.0 through 5.5, Apple Swift used a scheme for `SWIFT_COMPILER_VERSION` where the major version matched the embedded clang (e.g. 1300 for Apple Clang 13.0.0) and the minor version was ignored. Starting in Swift 5.6, Apple Swift started using major and minor version numbers that matched the Swift.org version number. This makes them easier to understand, but it means that version 1300.0.x was followed by version 5.6.x. Not only did version numbers go backwards, but also the old logic to ignore minor versions was now a liability, because it meant you would not be able to target a change to 5.7.x compilers but not 5.6.x compilers.

This commit addresses the problem by:

* Modifying the existing `#if _compiler_version(string-literal)` feature so it transforms the major version into a major and minor that will compare correctly to new version numbers. For instance, “1300.*” is transformed into “1.300”, which will compare correctly to a “5.6” or “5.7” version even if it doesn’t really capture the fact that “1300” was a Swift 5.5 compiler. As a bonus, this allows you to use the feature to backwards-compatibly test new compilers using the existing feature: “5007.*” will be seen by compilers before 5.7 as an unknown future version, but will be seen by 5.7 compilers as targeting them.

* Modifying the `__SWIFT_COMPILER_VERSION` clang define similarly so that, to preprocessor conditions written for the old scheme, a 5.7 compiler will appear to have major version 5007.

* Adding a new variant of `#if _compiler_version` with the same syntax as `#if swift` and `#if compiler`—that is, taking a comparison operator and a bare set of dotted version numbers, rather than a string literal. Going forward, this will be how version checks are written once compatibility with compilers before this change is no longer a concern.

These changes are only lightly tested because tests have to work without any compiler version defined (the default in most configurations), but I’ve tested what I can.

Fixes rdar://89841295.
WASI doesn't have "suspending-time" concept, so use `CLOCK_MONOTONIC`
for both "continuous" and "suspending" clocks. WASI's "monotonic"
doesn't guarantee any underlying system call implementation, but most
of major implementations use `CLOCK_MONOTONIC` for all underlying
platforms.

This partially buildfixes this platform.

See also: https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#variant-cases
…on if the first type is already an existential or opaque type.
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.

Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
This patch fixes an issue with C++-Interop that has been making it so
that enums under interop were not getting properly looked up and
therefore not getting imported. The reason for this was that the proper
DeclContext was not getting applied when grabbing the decls use by
VisitDecls later in the ClangImporter.

The lookup code at SwiftLookupTable::lookup is given a clang TU which is
what implcitly gets turned into an EffectiveClangContext. The
EffectiveClangContext is the piece that decides which DeclContext to
use. In the case of an extern "C" (ie LinkageSpecDecl), the
EffectiveClangContext was not traversing inside the lexical scope of the
extern "C" as the context for searching the EnumDecl (the NS_OPTIONS
Enum).

This patch adds new behavior when EffectiveClangContext is given a
LinkageSpecDecl. It sets the DeclContext to the lexical decl context.

With this fix in place in the presence of C++-Interop we not only import
the NS_OPTIONS typedef properly, but we also import the enum (and
therefore the EnumConstants) correctly (which are used for getting to
the flags for populating the NS_OPTIONS bitfields.
… availability of extensions. The primary motivation for this change is to reduce unnecessary availability diagnostics for API library authors. Many API libraries contain existing extension decls that lack declared availability where the extension introduces additional members to the extended type in the same release that the extended type was declared. Others contain extensions where the extension itself does not have declared availability but each of the members do. In both cases, the code is safe as written so the extra diagnostics would be a nuisance.

Resolves rdar://93630782
PrintOptions flag that is only enabled for interface printing.
Previously, we were always cleaning the sourcekit-lsp build directory prior to running tests and installing. That’s a waste of time. Only clean prior to the first build.
Adopt IterativeBackwardReachability.  Enables hoisting end_borrow
instructions over loops.  That in turn enables hoisting destroy_values
over those same loops.

rdar://93186505
Avoids hoisting borrow scopes into unrelated access scopes which could
introduce exclusivity violations.

rdar://93060369
…itlsp

[Build System] Don't clean sourcekit-lsp prior to running tests
…equire-64-bit

[Test] Run test with 64-bit SIL on 64-bit arch.
…18bd193f0bb07dba1f4b5ba

[dbg-info][move-function] Add DWARF filecheck lines for conditional control flow tests.
This builds ICU from source, statically builds and links it into the
toolchain image.  This removes the last piece that we were using that is
not auditable.  We now fully build the toolchain on the host on
swift-ci.
[ShrinkBorrowScope] Adopt iterative dataflow.
Adopt IterativeBackwardReachability.  Enables hoisting destroy_values
over loops.

rdar://93369506
Avoids hoisting destroy_values into unrelated access scopes which could
introduce exclusivity violations.
swiftlang#58857)

* move symbol graph samples to the bottom of the file

* add information about a doc comment's file and module

rdar://81190369

* refactor: group file URI collection/serialization together

* test for docComment.module to identify externally-inherited docs
…stential

[ASTPrinter] Print the desugared constraint type following the `any` keyword.
[LexicalDestroyHoisting] Adopt iterative dataflow.
compnerd and others added 25 commits May 25, 2022 15:40
This adds the ability to selectively skip the tests for various pieces
(e.g. foundation or xctest) to give us better control for CI for some
projects.
This test specifically disables serialization recovery, but that can
cause issues when loading the experimental string processing library. We
don't use it in the test, so just disable it for now.
…tent

[Tests] Make OS features consistent
These don't produce meaningful ParameterLists for this analysis to
consider. Bail instead of crashing.

rdar://93922410
…eton

[interop][swiftToCxx] emit empty skeleton C++ classes for Swift struc…
…eated-any-or-some-in-composition

[lib/Parse] swiftlang#58741 Do not suggest moving `any` or `some` to the beginning of a compositi…
…erator new/delete hackery.

The operator new/delete overrides aren't working out due to inconsistent inlining of std::string creation/deletion. We can end up creating one with the global new but destroying it with our local delete. If they aren't compatible, this crashes.

Instead, avoid problematic new/delete activity coming from lookup of ObjC class names. Names passed to getObjCClassByMangledName must either have a standard mangled name prefix, start with a digit (for unprefixed mangled names) or use the convenience dot syntax. Check for those up front and immediately reject anything else. This has the added bonus of failing more quickly for non-Swift names.

rdar://93863030
CI: add support to skip testing selectively on full builds
Fixes an oversight where `inout` -> C pointer conversion wasn't covered
by implementation of new pointer conversion semantics proposed by SE-0324.

Resolves: rdar://92583588
Fixes a crash in IR generation, where we would try to emit metadata
referencing a marker protocol, rdar://92285294.
[TypeChecker] SE-0324: Extend Swift -> C pointer conversions to `inout`
Ambiguities like:

```
struct S {
  init(v: Int) {}
  init(v: Int, _: () -> Void) {}

  func callAsFunction(_: () -> Void) {}
}

S(v: 42) {
}
```

Should always be resolved in favor of choice that doesn't require
injection of `.callAsFunction`, so let's try to avoid solving if
such an overload has already been found.
…m-clock-cpp

[stdlib] Port SE-0329 Clock APIs to WASI
…names

[Runtime] Don't try to demangle unprefixed untrusted names. Remove operator new/delete hackery.
[CSSimplify] Disfavor choices that have injected `callAsFunction`
Handle ParamDecls and VarDecls in Argument Matching Diagnostics
…-generic-signature

Sema: Simplify logic for building extension generic signature
[Test] Do not load string processing when recovery is disabled
…Common

[Autolink Extract] Filter out common Swift libraries from being linked more than once
@kateinoigakukun
Copy link
Member Author

The macOS x86_64 job failure seems unrelated to this change. Let's merge.

@kateinoigakukun kateinoigakukun merged commit 12f8b3d into swiftwasm May 27, 2022
@kateinoigakukun kateinoigakukun deleted the katei/merge-main-2022-05-27 branch May 27, 2022 13:45
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.