Katei/swifterror by kateinoigakukun · Pull Request #1 · kateinoigakukun/swift

kateinoigakukun · 2019-09-07T01:29:04Z

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

We have no working linker.

WebAssembly doesn't have __builtin_return_address.

This matches what Clang does. This doesn't check that the target is Wasm; will need to do that. Patcheng's port seems to have working? atomics, so it's probably possible to get atomics working, but this is fine for now. This still doesn't get the stdlib to compile, but at least the error now matches what I get when I run clang on the -emit-ir LLVM IR output.

This doesn't take care of all the PC relative relocations in constant builder yet. This still breaks on `((.Lgot.$sSTMp.656-($ss18EnumeratedSequenceVMn))-56)+1` Which sits in rodata. Not sure where that's generated yet

This removes the PCRel reloc in \01l_type_metadata_table but nowhere else

This at least seems to get rid of all the PCRel relocations emitted. Now it crashes in: (($sSTMp)+48)-8 The expr type is 0 expression kind not supported yay?!

This is completely untested.

WebAssembly doesn't have support for the DWARF5 features yet. It's probably not too hard to add (just add the sections), but I decided to just disable it out of caution since I have no idea if other changes are needed. This doesn't test for the WebAssembly platform yet; will do that later

Swift's importer won't import error constants from WASI, because the constants are wrapped in UINT16_C(), which Swift doesn't support.

WebAssembly only supports static linking (currently; dynamic is coming later) so we need static stdlib; I need to add that to the CMake scripts later

LLVM doesn't support generating DWARF5 debugging data for WebAssembly, and support for atomics is currently very limited. Set LLVM target options to avoid generating DWARF5 debug data and lower atomics to regular load/stores when building for WebAssembly. This shouldn't affect existing platforms.

This reverts commit 8d801d1.

This reverts commit bca7921.

@inline

The implementation was done quite a while ago. Now, that we have support in lldb (swiftlang/llvm-project#773), we can enable it by default in the compiler. LLDB now shows the runtime failure reason, for example: * thread #1, queue = 'com.apple.main-thread', stop reason = Swift runtime failure: arithmetic overflow frame #1: 0x0000000100000f0d a.out`testit(a=127) at trap_message.swift:4 1 2 @inline(never) 3 func testit(_ a: Int8) -> Int8 { -> 4 return a + 1 5 } 6 For details, see swiftlang#25978 rdar://problem/51278690

- Properly clone and use debug scopes for all instructions in pullback functions. - Emit `debug_value` instructions for adjoint values. - Add debug locations and variable info to adjoint buffer allocations. - Add `TangentBuilder` (a `SILBuilder` subclass) to unify and simplify special emitter utilities for tangent vector code generation. More simplifications to come. Pullback variable inspection example: ```console (lldb) n Process 50984 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x0000000100003497 main`pullback of foo(x=0) at main.swift:12:11 9 import _Differentiation 10 11 func foo(_ x: Float) -> Float { -> 12 let y = sin(x) 13 let z = cos(y) 14 let k = tanh(z) + cos(y) 15 return k Target 0: (main) stopped. (lldb) fr v (Float) x = 0 (Float) k = 1 (Float) z = 0.495846391 (Float) y = -0.689988375 ``` Resolves rdar://68616528 / SR-13535.

* Synchronize both versions of actor_counters.swift test * Synchronize on Job address Make sure to synchronize on Job address (AsyncTasks are Jobs, but not all Jobs are AsyncTasks). * Add fprintf debug output for TSan acquire/release * Add tsan_release edge on task creation without this, we are getting false data races between when a task is created and immediately scheduled on a different thread. False positive for `Sanitizers/tsan/actor_counters.swift` test: ``` WARNING: ThreadSanitizer: data race (pid=81452) Read of size 8 at 0x7b2000000560 by thread T5: #0 Counter.next() <null>:2 (a.out:x86_64+0x1000047f8) #1 (1) suspend resume partial function for worker(identity:counters:numIterations:) <null>:2 (a.out:x86_64+0x100005961) #2 swift::runJobInEstablishedExecutorContext(swift::Job*) <null>:2 (libswift_Concurrency.dylib:x86_64+0x280ef) Previous write of size 8 at 0x7b2000000560 by main thread: #0 Counter.init(maxCount:) <null>:2 (a.out:x86_64+0x1000046af) #1 Counter.__allocating_init(maxCount:) <null>:2 (a.out:x86_64+0x100004619) #2 runTest(numCounters:numWorkers:numIterations:) <null>:2 (a.out:x86_64+0x100006d2e) #3 swift::runJobInEstablishedExecutorContext(swift::Job*) <null>:2 (libswift_Concurrency.dylib:x86_64+0x280ef) #4 main <null>:2 (a.out:x86_64+0x10000a175) ``` New edge with this change: ``` [4357150208] allocate task 0x7b3800000000, parent = 0x0 [4357150208] creating task 0x7b3800000000 with parent 0x0 [4357150208] tsan_release on 0x7b3800000000 <<< new release edge [139088221442048] tsan_acquire on 0x7b3800000000 [139088221442048] trying to switch from executor 0x0 to 0x7ff85e2d9a00 [139088221442048] switch failed, task 0x7b3800000000 enqueued on executor 0x7ff85e2d9a00 [139088221442048] enqueue job 0x7b3800000000 on executor 0x7ff85e2d9a00 [139088221442048] tsan_release on 0x7b3800000000 [139088221442048] tsan_release on 0x7b3800000000 [4357150208] tsan_acquire on 0x7b3800000000 counters: 1, workers: 1, iterations: 1 [4357150208] allocate task 0x7b3c00000000, parent = 0x0 [4357150208] creating task 0x7b3c00000000 with parent 0x0 [4357150208] tsan_release on 0x7b3c00000000 <<< new release edge [139088221442048] tsan_acquire on 0x7b3c00000000 [4357150208] task 0x7b3800000000 waiting on task 0x7b3c00000000, going to sleep [4357150208] tsan_release on 0x7b3800000000 [4357150208] tsan_release on 0x7b3800000000 [139088221442048] getting current executor 0x0 [139088221442048] tsan_release on 0x7b3c00000000 ... ``` rdar://78932849 * Add static_cast<Job *>() * Move TSan release edge to swift_task_enqueueGlobal() Move the TSan release edge from `swift_task_create_commonImpl()` to `swift_task_enqueueGlobalImpl()`. Task creation itself is not an event that needs synchronization, but rather that task creation "happens before" execution of that task on another thread. This edge is usually added when the task is scheduled via `swift_task_enqueue()` (which then usually calls `swift_task_enqueueGlobal()`). However, not all task scheduling goes through the `swift_task_enqueue()` funnel as some places call the more specific `swift_task_enqueueGlobal()` directly. So let's annotate this function (duplicate edges aren't harmful) to ensure we cover all schedule events, including newly-created tasks (our original problem here). rdar://78932849 Co-authored-by: Julian Lettner <julian.lettner@apple.com>

Update bridging

Co-authored-by: Karoy Lorentey <klorentey@apple.com>

[Inclusive-Language] change comment with "sanity" to "soundness"

Local symbols

Add a new demangler option which excludes a closure's type signature. This will be used in lldb. Closures are not subject to overloading, and so the signature will never be used to disambiguate. A demangled closure is uniquely identifiable by its index(s) and parent. Where opaque types are involved, the concrete type signature can be quite complex. This demangling option allows callers to avoid printing the underlying complex nested concrete types. Example: before: `closure #1 (Swift.Int) -> () in closure #1 (Swift.Int) -> () in main` after: `closure #1 in closure #1 in main`

…wiftlang#73353) Add a new demangler option which excludes a closure's type signature. This will be used in lldb. Closures are not subject to overloading, and so the signature will never be used to disambiguate. A demangled closure is uniquely identifiable by its index(s) and parent. Where opaque types are involved, the concrete type signature can be quite complex. This demangling option allows callers to avoid printing the underlying complex nested concrete types. Example: before: `closure #1 (Swift.Int) -> () in closure #1 (Swift.Int) -> () in main` after: `closure #1 in closure #1 in main`

This inserts a suitably named function into the stack trace whenever a dynamic cast failure involves a NULL source or target type. Very often, crash logs include backtraces with function names but no log output; with this change, such a backtrace might look like the following -- note `TARGET_TYPE_NULL` in the function name here to mark the missing type information: ``` frame #0: __pthread_kill + 8 frame #1: pthread_kill + 288 frame #2: abort + 128 frame #3: swift::fatalErrorv() frame #4: swift::fatalError() frame #5: swift_dynamicCastFailure_TARGET_TYPE_NULL() frame #6: swift::swift_dynamicCastFailure() frame #7: ::swift_dynamicCast() ``` Resolves rdar://130630157

…n's demangled name when processing it in RegionAnalysis. Just trying to improve logging to speed up triaging further. This is useful so that I can quickly find specific closures we process by using the closure numbering (e.x.: closure #1 in XXXX).

Two are fixes needed in most of the `RawSpan` and `Span` initializers. For example: ``` let baseAddress = buffer.baseAddress let span = RawSpan(_unchecked: baseAddress, byteCount: buffer.count) // As a trivial value, 'baseAddress' does not formally depend on the // lifetime of 'buffer'. Make the dependence explicit. self = _overrideLifetime(span, borrowing: buffer) ``` Fix #1. baseAddress needs to be a variable `span` has a lifetime dependence on `baseAddress` via its initializer. Therefore, the lifetime of `baseAddress` needs to include the call to `_overrideLifetime`. The override sets the lifetime dependency of its result, not its argument. It's argument still needs to be non-escaping when it is passed in. Alternatives: - Make the RawSpan initializer `@_unsafeNonescapableResult`. Any occurrence of `@_unsafeNonescapableResult` actually signals a bug. We never want to expose this annotation. In addition to being gross, it would totally disable enforcement of the initialized span. But we really don't want to side-step `_overrideLifetime` where it makes sense. We want the library author to explicitly indicate that they understand exactly which dependence is unsafe. And we do want to eventually expose the `_overrideLifetime` API, which needs to be well understood, supported, and tested. - Add lifetime annotations to a bunch of `UnsafePointer`-family APIs so the compiler can see that the resulting pointer is derived from self, where self is an incoming `Unsafe[Buffer]Pointer`. This would create a massive lifetime annotation burden on the `UnsafePointer`-family APIs, which don't really have anything to do with lifetime dependence. It makes more sense for the author of `Span`-like APIs to reason about pointer lifetimes. Fix #2. `_overrideLifetime` changes the lifetime dependency of span to be on an incoming argument rather than a local variable. This makes it legal to escape the function (by assigning it to self). Remember that self is implicitly returned, so the `@lifetime(borrow buffer)` tells the compiler that `self` is valid within `buffer`'s borrow scope.

This is the missing check for "rule #1" in the isolated conformances proposal, which states that an isolated conformance can only be referenced within the same isolation domain as the conformance. For example, a main-actor-isolated conformance can only be used within main-actor code.

…g#81643) which generates IR without a llvm.trap function All the normal CI generated this: ``` ret i32 %1 } ; Function Attrs: cold noreturn nounwind memory(inaccessiblemem: write) declare void @llvm.trap() #1 attributes #0 = { "frame-pointer"= ``` But the test-simulator CI doesn't for some reason, so just check for the closing brace instead.

When the host compiler is built with assertions, 'swiftc -parse -' hits an assertion failure, which fails the capability checks. ``` Assertion failed: [&]() -> bool { if (FrontendOptions::shouldActionOnlyParse(Action)) { return llvm::all_of( opts.InputsAndOutputs.getAllInputs(), [](const InputFile &IF) { const auto kind = IF.getType(); return kind == file_types::TY_Swift || kind == file_types::TY_SwiftModuleInterfaceFile; }); } return true; }() && "Only supports parsing .swift files", file C:\Users\swift-ci\jenkins\workspace\swift-main-windows-toolchain\swift\lib\FrontendTool\FrontendTool.cpp, line 1737 Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace. Stack dump: 0. Program arguments: S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\swift-frontend.exe -frontend -parse -primary-file - -target x86_64-unknown-windows-msvc -disable-objc-interop -no-color-diagnostics -Xcc -fno-color-diagnostics -disable-implicit-string-processing-module-import -empty-abi-descriptor -no-auto-bridging-header-chaining -module-name main -in-process-plugin-server-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\SwiftInProcPluginServer.dll -plugin-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path S:\\b\\toolchains\\DEVELOPMENT-SNAPSHOT-2025-12-01-a\\LocalApp\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL 1. Swift version 6.3-dev (LLVM 35f48306184cd25, Swift a69dbb3) 2. Compiling with effective version 5.10 Exception Code: 0x80000003 #0 0x00007ff7a6efdda5 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x722dda5) #1 0x00007ff94d8b1989 (C:\WINDOWS\System32\ucrtbase.dll+0xc1989) #2 0x00007ff94d894ab1 (C:\WINDOWS\System32\ucrtbase.dll+0xa4ab1) #3 0x00007ff94d8b2986 (C:\WINDOWS\System32\ucrtbase.dll+0xc2986) #4 0x00007ff94d8b2b61 (C:\WINDOWS\System32\ucrtbase.dll+0xc2b61) #5 0x00007ff7a02d944d (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x60944d) #6 0x00007ff7a02db914 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x60b914) #7 0x00007ff7a011b19e (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x44b19e) #8 0x00007ff7a011ad57 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x44ad57) #9 0x00007ff7a6f667d0 (S:\b\toolchains\DEVELOPMENT-SNAPSHOT-2025-12-01-a\LocalApp\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x72967d0) #10 0x00007ff94e6be8d7 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e8d7) #11 0x00007ff94fe2c40c (C:\WINDOWS\SYSTEM32\ntdll.dll+0x8c40c) ```

zhuowei added 30 commits June 8, 2019 14:08

Start adding wasm

acbaac3

Add wasm object emit support

a39bc59

build-script: parse skip wasm command line args

cc85a9a

Handle WASM sdk in cmake

cc98380

Integrate Emscripten sdk path

8118f81

start adding Emscripten defines in stdlib

86b4238

actually pass the icu paths into CMake

f519ab8

do not link WebAssembly shared libraries for now

7f10472

We have no working linker.

add script to launch build

1b1b4f4

start adding wasm32 to 32-bit checks in stdlib

f31a795

WebAssembly: more conditional compile defines

a84cc90

Hack: Remove returnaddress calls emitted by exclusivity checks

60f91ba

WebAssembly doesn't have __builtin_return_address.

change non-Emscripten specific ifdefs to check for __wasm__ instead

9ece2c6

Switch to WASI

a4b0344

fix WASI header includes

407ddcb

WebAssembly: Disable Comdat for reflection metadata

3d771f5

Disable generating PC-relative relocations in constant builder

15a1742

This doesn't take care of all the PC relative relocations in constant builder yet. This still breaks on `((.Lgot.$sSTMp.656-($ss18EnumeratedSequenceVMn))-56)+1` Which sits in rodata. Not sure where that's generated yet

WebAssembly: remove even more PCRel relocations

64ac940

This removes the PCRel reloc in \01l_type_metadata_table but nowhere else

WebAssembly: remove more PCRel relocations

d0f54a4

This at least seems to get rid of all the PCRel relocations emitted. Now it crashes in: (($sSTMp)+48)-8 The expr type is 0 expression kind not supported yay?!

WebAssembly: disable relative pointers in the runtime

853e209

This is completely untested.

Start exporting WASI musl in Glibc modulemap

6fdcc47

WebAssembly: disable subprocesses

e9cb3e5

WebAssembly: add EINVAL constant manually

79ff1fc

Swift's importer won't import error constants from WASI, because the constants are wrapped in UINT16_C(), which Swift doesn't support.

WebAssembly: add more wasm Glibc target dependencies to cmakefiles

75fd3cd

WebAssembly: hack: Disable tests for now

3b316b1

WebAssembly: add more ifdefs for WebAssembly

1808f9b

build static stdlibs in build script

3bdd62b

WebAssembly only supports static linking (currently; dynamic is coming later) so we need static stdlib; I need to add that to the CMake scripts later

kateinoigakukun added 6 commits September 5, 2019 00:20

Revert "Add when wasm"

032a056

This reverts commit 8d801d1.

@add swifterror for callee

3f5dcab

Add caller support

842ec04

pass pure_f.wasm

e45dcf8

support selfValue

bca7921

Revert "support selfValue"

3bb81d3

This reverts commit bca7921.

kateinoigakukun force-pushed the swiftwasm branch 3 times, most recently from 33e67de to 6218d5b Compare September 30, 2019 23:00

kateinoigakukun force-pushed the swiftwasm branch from 00f98a4 to fb939ab Compare November 3, 2019 01:21

kateinoigakukun force-pushed the swiftwasm branch from fb939ab to b6040e8 Compare November 16, 2019 16:22

kateinoigakukun closed this Dec 15, 2019

kateinoigakukun deleted the katei/swifterror branch January 28, 2020 12:42

kateinoigakukun restored the katei/swifterror branch January 28, 2020 12:42

kateinoigakukun pushed a commit that referenced this pull request Dec 16, 2023

Merge pull request #1 from Genaro-Chris/Genaro-Chris-patch-1

49ea89d

Update bridging

kateinoigakukun pushed a commit that referenced this pull request Jan 27, 2024

Take doc suggestion from Karoy #1

f28ebc9

Co-authored-by: Karoy Lorentey <klorentey@apple.com>

kateinoigakukun pushed a commit that referenced this pull request Feb 12, 2024

Merge pull request #1 from Serena748/Serena748/inclusive-language

141b4d0

[Inclusive-Language] change comment with "sanity" to "soundness"

kateinoigakukun pushed a commit that referenced this pull request Feb 21, 2024

Merge pull request #1 from skrtks/local-symbols

b97c636

Local symbols

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Katei/swifterror#1

Katei/swifterror#1
kateinoigakukun wants to merge 64 commits into
swiftwasmfrom
katei/swifterror

kateinoigakukun commented Sep 7, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

kateinoigakukun commented Sep 7, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants