Update more IRGen tests for opaque pointers - #1
Open
drexin wants to merge 1 commit into
Open
Conversation
aschwaighofer
pushed a commit
that referenced
this pull request
Jan 26, 2024
Co-authored-by: Karoy Lorentey <klorentey@apple.com>
aschwaighofer
pushed a commit
that referenced
this pull request
Feb 6, 2024
[Inclusive-Language] change comment with "sanity" to "soundness"
aschwaighofer
pushed a commit
that referenced
this pull request
May 2, 2024
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`
aschwaighofer
pushed a commit
that referenced
this pull request
May 14, 2024
…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`
aschwaighofer
pushed a commit
that referenced
this pull request
Jul 31, 2024
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 swiftlang#4: swift::fatalError() frame swiftlang#5: swift_dynamicCastFailure_TARGET_TYPE_NULL() frame swiftlang#6: swift::swift_dynamicCastFailure() frame swiftlang#7: ::swift_dynamicCast() ``` Resolves rdar://130630157
aschwaighofer
pushed a commit
that referenced
this pull request
Aug 28, 2024
…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).
aschwaighofer
pushed a commit
that referenced
this pull request
Dec 20, 2024
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.
aschwaighofer
pushed a commit
that referenced
this pull request
Mar 19, 2025
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.
aschwaighofer
pushed a commit
that referenced
this pull request
May 22, 2025
…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.
aschwaighofer
pushed a commit
that referenced
this pull request
Nov 4, 2025
…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.
aschwaighofer
pushed a commit
that referenced
this pull request
Mar 23, 2026
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)
swiftlang#4 0x00007ff94d8b2b61 (C:\WINDOWS\System32\ucrtbase.dll+0xc2b61)
swiftlang#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)
swiftlang#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)
swiftlang#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)
swiftlang#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)
swiftlang#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)
swiftlang#10 0x00007ff94e6be8d7 (C:\WINDOWS\System32\KERNEL32.DLL+0x2e8d7)
swiftlang#11 0x00007ff94fe2c40c (C:\WINDOWS\SYSTEM32\ntdll.dll+0x8c40c)
```
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.