forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
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
Merge main 2022-05-27 #4596
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
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.
…ontrol flow tests.
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.
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.
…troactive-mangle
rdar://93780666
[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
The macOS x86_64 job failure seems unrelated to this change. Let's merge. |
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.