Get the libdispatch tests working again #2
Closed
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
When the function is a method, we want a DW_AT_declaration there. Because there's no good way to cross the CU boundary to insert a nested DISubprogram definition in one CU into a type defined in another CU when doing LTO builds.
…onsumer phase This will allow us to run two different completion kinds and deliver results from both of them. Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
…er-based rdar://113472967
Systematically declare CacheInvariant options in TableGen file instead of putting a list in the cache key computation function.
as long as the Swift parser integration is enabled. Also, remove redundant RPATH additions.
…usted Previously, default bindings (from Defaultable and FallbackType constraints) where added to the set right after the first attempt, but that is incorrect because binding producer should exhaust the chain of superclasses and other "inferred" bindings first or risk producing subpar solutions.
…ditional calculations in TypeRefBuilder.
|
@finagolfin I'll pull this into my branch |
gottesmm
force-pushed
the
rdar89046735
branch
from
a87e50d to
84a32c0
Compare
[SourceKit] RPATH 'lib/swift/host' should be added without BOOTSTRAPPING
…ociated context In a per file compilation mode we want to use the file context -- which is stored in the AssociatedContext -- rather than defaulting to the current Swift Module context. rdar://114344533
Augment the TypeVarRefCollector such that it picks up any type variables present in the result type for a closure DeclContext when visiting a ReturnStmt. This ensures we correctly handle if/switch expressions that contain `return` statements. rdar://114402042
…xes one small potential issue while there. (swiftlang#65605) Fixes swiftlang#65489 swiftlang#67992
…08-cache-additional-TypeRefBuilder-operations [RemoteMirror] Speed up Remote Mirror significantly by caching two additional calculations in TypeRefBuilder.
Either directly, or via a type alias.
Before move-checking values, complete the lifetimes of all the values derived from them via copy, borrow, and move. Collect all such values and their derived transitive values and then complete the lifetimes of each, visiting the instructions which produce them in post-order. Once OSSALifetimeCommpletion runs as part of SILGenCleanup, this code can be deleted.
Update LibcShims.cpp
[Runtime] Add a function to check type creation
build: adjust the build to support non-Apple environments
…ormances
Provide member macros with similar information about conformances to
what extension macros receive, allowing member macros to document
which conformances they care about (e.g., Decodable) and then
receiving the list of conformances that aren't already available for
the type in question. For example, a macro such as
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
Expanded on a type that is not already Decodable/Encodable would be
provided with Decodable and Encodable (via the new
`missingConformancesTo:` argument to the macro implementation) when
the type itself does not conform to those types.
Member macros still cannot produce conformances, so this is likely to
be used in conjunction with extension macros most of the time. The
extension macro declares the conformance, and can also declare any
members that shouldn't be part of the primary type definition---such
as initializers that shouldn't suppress the memberwise initializer. On
the other hand, the member macro will need to define any members that
must be in the primary definition, such as required initializers,
members that must be overridable by subclasses, and stored properties.
Codable synthesis is an example that benefits from member macros with
conformances, because for classes it wants to introduce a required
initializer for decoding and an overridable encode operation, and
these must be members of the nominal type itself. Specifically, the
`Codable` macro above is likely to have two attached member roles:
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
@attached(extension, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
where the "extension" role is responsible for defining the conformance
(always), and the "member" creates the appropriate members for classes
(`init` vs. `required init`).
Tracked by rdar://112532829.
…mances (More) Declaration checker support for tuple conformances
…syntax-lit [swift-syntax] Don’t pass `--filecheck-exec` to swift-syntax’s build script
[CSBindings] Delay default binding production until inference is exhausted
Add new apis to ForwardingOperation
Redefine the types rather than use the standard headers due to the circular dependency between Darwin and Swift.
…ze-expr [CodeCompletion] Delete `SanitizeExpr`
[MoveChecker] Complete lifetimes before checking.
build: fix the build of the toolchain
…ftlang#68374) `--clone` and `--clone-with-ssh` help strings were using capitalization inconsistent with other options.
…ostdlib swift-plugin-server: remove standard headers
… always have a fresh swift-dispatch when running swift tests. In the fullness of time, we want to split the full build-script-impl pipeline so that we can begin moving library like products (libdispatch, foundation) from build-script-impl into build-script. We are not there yet since some of swift's concurrency tests have a dependency on swift dispatch being built. This breaks the build and we need to extract those tests into a separate product. But for now, this makes sense to repair the build. rdar://89046735
finagolfin
force-pushed
the
rdar89046735
branch
from
6d2d325 to
3a15d1a
Compare
…g/swift-corelibs-libdispatch#785 This allows the tests that use libdispatch to find its modulemap, plus add the libdispatch compilation flags to one test that was missing them and fix one async test on linux.
finagolfin
force-pushed
the
rdar89046735
branch
from
3a15d1a to
6897516
Compare
gottesmm
force-pushed
the
rdar89046735
branch
from
84a32c0 to
de41f83
Compare
|
Closing since it has been merged upstream. |
gottesmm
pushed a commit
that referenced
this pull request
Sep 22, 2023
# This is the 1st commit message: utils: update the build-windows-toolchain.bat to extract the toolchain Fetch a prebuilt toolchain to build the toolchain. This is required to enable the macro support on Windows. # The commit message #2 will be skipped: # build: build SwiftSyntax before the toolchain build # # Perform a build of Swift Syntax prior to the build of the toolchain so # that we can enable the early swift syntax parser builds. This is a # prerequisite for enabling macros on Windows. # The commit message swiftlang#3 will be skipped: # # This is a combination of 5 commits. # # This is the 1st commit message: # # build: wire up the early swift-syntax build to the build # # This enables the early swift syntax build to get us macro support on # Windows. # # # The commit message #2 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#3 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#4 will be skipped: # # # Update build-windows-toolchain.bat # # # The commit message swiftlang#5 will be skipped: # # # Update build-windows-toolchain.bat
gottesmm
pushed a commit
that referenced
this pull request
Jan 17, 2024
Co-authored-by: Karoy Lorentey <[email protected]>
gottesmm
pushed a commit
that referenced
this pull request
Jul 12, 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 swiftlang#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
gottesmm
pushed a commit
that referenced
this pull request
Dec 15, 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.
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.
@gottesmm, I think the test fixes in my commit should get your upstream pull working on the linux CI, plus I rebased your branch against latest trunk.