Merge pull request #4235 from swiftwasm/main

Author: MaxDesiatov

CMakeLists.txt

@@ -363,6 +363,10 @@ option(SWIFT_SIL_VERIFY_ALL
     "Run SIL verification after each transform when building Swift files in the build process"
     FALSE)
 
+option(SWIFT_SIL_VERIFY_ALL_MACOS_ONLY
+    "Run SIL verification after each transform when building the macOS stdlib"
+    FALSE)
+
 option(SWIFT_EMIT_SORTED_SIL_OUTPUT
     "Sort SIL output by name to enable diffing of output"
     FALSE)

cmake/modules/SwiftComponents.cmake

@@ -64,11 +64,13 @@
 #   Swift code.
 # * toolchain-tools -- a subset of tools that we will install to the OSS toolchain.
 # * testsuite-tools -- extra tools required to run the Swift testsuite.
+# * parser-lib -- Build the syntax parser library used by SwiftSyntax.
+# * static-mirror-lib -- Build the static mirror library used by SwiftStaticMirror.
 # * toolchain-dev-tools -- install development tools useful in a shared toolchain
 # * llvm-toolchain-dev-tools -- install LLVM development tools useful in a shared toolchain
 # * dev -- headers and libraries required to use Swift compiler as a library.
 set(_SWIFT_DEFINED_COMPONENTS
-  "autolink-driver;back-deployment;compiler;clang-builtin-headers;clang-resource-dir-symlink;clang-builtin-headers-in-clang-resource-dir;stdlib;stdlib-experimental;sdk-overlay;parser-lib;editor-integration;tools;testsuite-tools;toolchain-tools;toolchain-dev-tools;llvm-toolchain-dev-tools;dev;license;sourcekit-xpc-service;sourcekit-inproc;swift-remote-mirror;swift-remote-mirror-headers")
+  "autolink-driver;back-deployment;compiler;clang-builtin-headers;clang-resource-dir-symlink;clang-builtin-headers-in-clang-resource-dir;stdlib;stdlib-experimental;sdk-overlay;parser-lib;static-mirror-lib;editor-integration;tools;testsuite-tools;toolchain-tools;toolchain-dev-tools;llvm-toolchain-dev-tools;dev;license;sourcekit-xpc-service;sourcekit-inproc;swift-remote-mirror;swift-remote-mirror-headers")
 
 # The default install components include all of the defined components, except
 # for the following exceptions.

docs/DebuggingTheCompiler.md

@@ -714,39 +714,31 @@ which causes the miscompile.
 Currently there is no tool to automatically identify the bad optimization, but
 it's quite easy to do this manually:
 
-1. Find the offending optimization with bisecting:
-
-  a. Add the compiler option `-Xllvm -sil-opt-pass-count=<n>`, where `<n>`
-     is the number of optimizations to run.
-
-  b. Bisect: find n where the executable crashes, but does not crash
-     with n-1. First just try n = 10, 100, 1000, 10000, etc. to find
-     an upper bound). Then can either bisect the invocation by hand or
-     place the invocation into a script and use
-     `./llvm-project/llvm/utils/bisect` to automatically bisect
-     based on the scripts error code. Example invocation:
-
-       bisect --start=0 --end=10000 ./invoke_swift_passing_N.sh "%(count)s"
-
-  c. Once one finds `n`, Add another option `-Xllvm -sil-print-pass-name`. The output can be
-     large, so it's best to redirect stderr to a file (`2> output`).
-     In the output search for the last pass before `stage Address Lowering`.
-     It should be the `Run #<n-1>`. This line tells you the name of the bad
-     optimization pass and on which function it run.
-
-2. Get the SIL before and after the bad optimization.
-
-  a. Add the compiler option
-     `-Xllvm -sil-print-function='<function>'`
-     where `<function>` is the function name (including the preceding `$`).
-     For example:
-     `-Xllvm -sil-print-function='$s4test6testityS2iF'`.
-     Again, the output can be large, so it's best to redirect stderr to a file.
-  b. From the output, copy the SIL of the function *before* the bad
-     run into a separate file and the SIL *after* the bad run into a file.
-  c. Compare both SIL files and try to figure out what the optimization pass
-     did wrong. To simplify the comparison, it's sometimes helpful to replace
-     all SIL values (e.g. `%27`) with a constant string (e.g. `%x`).
+1. Add the compiler option `-Xllvm -sil-opt-pass-count=<n>`, where `<n>`
+   is the number of optimizations to run.
+
+2. Bisect: find n where the executable crashes, but does not crash
+   with n-1. First just try n = 10, 100, 1000, 10000, etc. to find
+   an upper bound). Then can either bisect the invocation by hand or
+   place the invocation into a script and use
+   `./llvm-project/llvm/utils/bisect` to automatically bisect
+   based on the scripts error code. Example invocation:
+
+     bisect --start=0 --end=10000 ./invoke_swift_passing_N.sh "%(count)s"
+
+3. Add another option `-Xllvm -sil-print-last`. The output can be
+   large, so it's best to redirect stderr to a file (`2> output`).
+   The output contains the SIL before and after the bad optimization.
+
+4. Copy the two functions from the output into separate files and
+   compare both files. Try to figure out what the optimization pass
+   did wrong. To simplify the comparison, it's sometimes helpful to replace
+   all SIL values (e.g. `%27`) with a constant string (e.g. `%x`).
+
+5. If the bad optimization is SILCombine or SimplifyCFG (which do a lot of
+   transformations in a single run) it's helpful to continue bisecting on
+   the sub-pass number. The option `-Xllvm -sil-opt-pass-count=<n>.<m>`
+   can be used for that, where `m` is the sub-pass number.
 
 ### Using git-bisect in the presence of branch forwarding/feature branches
 

docs/Lexicon.md

@@ -594,6 +594,16 @@ of `Optional<Int>`.) Sugared types preserve information about the form
 and use of the type even though the behavior usually does not change
 (except for things like access control). Contrast with [canonical type](#canonical-type).
 
+## TBD
+
+Text-based dynamic library files (TBDs) are a textual representation of
+the information in a dynamic library / shared library that is required
+by the static linker.
+
+Apple’s SDKs originally used Mach-O Dynamic Library Stubs. Mach-O Dynamic
+Library Stubs are dynamic library files, but with all the text and data
+stripped out.
+
 ## thunk
 
 In the Swift compiler, a synthesized function whose only purpose is to

docs/SIL.rst

@@ -2364,6 +2364,69 @@ The current list of interior pointer SIL instructions are:
 (*) We still need to finish adding support for project_box, but all other
 interior pointers are guarded already.
 
+Variable Lifetimes
+~~~~~~~~~~~~~~~~~~
+
+In order for programmer intended lifetimes to be maintained under optimization,
+the lifetimes of SIL values which correspond to named source-level values can
+only be modified in limited ways.  Generally, the behavior is that the lifetime
+of a named source-level value cannot _observably_ end before the end of the
+lexical scope in which that value is defined.  Specifically, code motion may
+not move the ends of these lifetimes across a **deinit barrier**.
+
+A few sorts of SIL value have lifetimes that are constrained that way:
+
+1: `begin_borrow [lexical]`
+2: `move_value [lexical]`
+3: @owned function arguments
+4: `alloc_stack [lexical]`
+
+That these three have constrained lifetimes is encoded in ValueBase::isLexical,
+which should be checked before changing the lifetime of a value.
+
+The reason that only @owned function arguments are constrained is that a
+@guaranteed function argument is guaranteed by the function's caller to live for
+the full duration of the function already.  Optimization of the function alone
+can't shorten it.  When such a function is inlined into its caller, though, a
+lexical borrow scope is added for each of its @guaranteed arguments, ensuring
+that the lifetime of the corresponding source-level value is not shortened in a
+way that doesn't respect deinit barriers.
+
+Unlike the other sorts, `alloc_stack [lexical]` isn't a SILValue.  Instead, it
+constrains the lifetime of an addressable variable.  Since the constraint is
+applied to the in-memory representation, no additional lexical SILValue is
+required.
+
+Deinit Barriers
+```````````````
+
+Deinit barriers (see swift::isDeinitBarrier) are instructions which would be
+affected by the side effects of deinitializers.  To maintain the order of
+effects that is visible to the programmer, destroys of lexical values cannot be
+reordered with respect to them.  There are three kinds:
+
+1. synchronization points (locks, memory barriers, syscalls, etc.)
+2. loads of weak or unowned values
+3. accesses of pointers
+
+Examples:
+
+1. Given an instance of a class which owns a file handle and closes the file
+   handle on deinit, writing to the file handle and then deallocating the
+   instance would result in changes being written.  If the destroy of the
+   instance were hoisted above the call to write to the file handle, an error
+   would be raised instead.
+2. Given an instance `c` of a class `C` which weakly references an instance `d`
+   of a second class `D`, if `d` is referenced via a local variable `v`, then
+   loading that weak reference from `c` within the variable scope should return
+   a non-nil reference to `d`.  Hoisting the destroy of `v` above the weak load
+   from `c`, however, would result in the destruction of `d` before that load
+   and a nil weak reference to `D`.
+3. Given an instance of a class which owns a buffer and deallocates it on
+   deinitialization, accessing the pointer and then deallocating the instance
+   is defined behavior.  Hoisting the destroy of the instance above the access
+   to the memory would result in accessing a freed pointer.
+
 Memory Lifetime
 ~~~~~~~~~~~~~~~
 

include/swift-c/CommonString/CommonString.h

@@ -0,0 +1,35 @@
+//===--- CommonString.h - C API for Swift Dependency Scanning ---*- C -*-===//
+ //
+ // This source file is part of the Swift.org open source project
+ //
+ // Copyright (c) 2014 - 2020 Apple Inc. and the Swift project authors
+ // Licensed under Apache License v2.0 with Runtime Library Exception
+ //
+ // See https://swift.org/LICENSE.txt for license information
+ // See https://swift.org/CONTRIBUTORS.txt for the list of Swift project authors
+ //
+ //===----------------------------------------------------------------------===//
+
+ #ifndef SWIFT_C_LIB_SWIFT_COMMON_STRING_H
+ #define SWIFT_C_LIB_SWIFT_COMMON_STRING_H
+
+ #include <stdbool.h>
+ #include <stddef.h>
+ #include <stdint.h>
+
+ /**
+  * A character string used to pass around dependency scan result metadata.
+  * Lifetime of the string is strictly tied to the object whose field it
+  * represents. When the owning object is released, string memory is freed.
+  */
+ typedef struct {
+   const void *data;
+   size_t length;
+ } swiftscan_string_ref_t;
+
+ typedef struct {
+   swiftscan_string_ref_t *strings;
+   size_t count;
+ } swiftscan_string_set_t;
+
+ #endif // SWIFT_C_LIB_SWIFT_COMMON_STRING_H

include/swift-c/DependencyScan/BinaryScan.h

@@ -15,15 +15,21 @@
 //
 //===----------------------------------------------------------------------===//
 
-#include "DependencyScanMacros.h"
-#include "CommonString.h"
-
 #ifndef SWIFT_C_DEPENDENCY_SCAN_H
 #define SWIFT_C_DEPENDENCY_SCAN_H
 
+#include "DependencyScanMacros.h"
+#include "swift-c/CommonString/CommonString.h"
+
+/// The version constants for the SwiftDependencyScan C API.
+/// SWIFTSCAN_VERSION_MINOR should increase when there are API additions.
+/// SWIFTSCAN_VERSION_MAJOR is intended for "major" source/ABI breaking changes.
+#define SWIFTSCAN_VERSION_MAJOR 0
+#define SWIFTSCAN_VERSION_MINOR 2
+
 SWIFTSCAN_BEGIN_DECLS
 
-//=== Public Dependency Scanner Data Types -------------------------------===//
+//=== Public Scanner Data Types -------------------------------------------===//
 
 typedef enum {
   // This dependency info encodes two ModuleDependencyKind types:
@@ -345,8 +351,6 @@ swiftscan_scanner_cache_load(swiftscan_scanner_t scanner,
 SWIFTSCAN_PUBLIC void
 swiftscan_scanner_cache_reset(swiftscan_scanner_t scanner);
 
-//=== Experimental compiler invocation operations -------------------------===//
-
 /// An entry point to invoke the compiler via a library call.
 SWIFTSCAN_PUBLIC int invoke_swift_compiler(int argc, const char **argv);