- Fix issue with no build id showing up as `000000`... (e.g. no debug
info), now shows as `<no build id>` as intended.
- Try to avoid loading PE file unless it's necessary on Windows
symbolicating backtraces.
- DefaultSymbolLocator: PDB file finding now respects the overridable
path for use in the offline symbolicator (no effect on standard
backtracing).
- Record timestamp/size in Image Info on windows for possible future use
in offline symbolicator
---------
Co-authored-by: Carl Peto <carlpeto@Carls-MacBook-Pro.local>
Mask the non-native bridgeobject bits rather than all spare bits. This prevents us from trying to retain pointers that aren't valid native object pointers.
When a typealias or associated type is declared inside a protocol, the
mangling of an access like S.A (for `typealias A` in `protocol P` and
`struct S : P`) wraps the protocol in a BoundGenericProtocol whose
single generic argument is the conforming Self type:
BoundGenericProtocol
|
--> Protocol: P
|
--> TypeList:
|
--> Structure: S
DemanglingForTypeRef was substituting the richer parent wholesale in
place of the Protocol, losing the BoundGenericProtocol entirely and
producing a mangled tree that looks as if A were declared directly
on S rather than inside P.
Assisted-by: claude
rdar://160408523
Swift gained native Int128 / UInt128 types in SE-0425, but the plumbing
for bridging them across the C/C++ boundary was incomplete. CInt128 and
CUnsignedInt128 were never added to CTypes.swift, even though
BuiltinMappedTypes.def has been mapping __int128 / unsigned __int128 to
those names since 2013. Without the typealiases, every C declaration
mentioning __int128 was silently dropped at import time.
This patch adds the CInt128 and CUInt128 type aliases to CTypes.swift
for forward interop, and also adds the Int128 -> __int128 mapping in
PrintAsClang and IRABIDetailsProvider for reverse interop.
rdar://177111210
Rather than attempt to use standard C++ type names, create a namespace specifically for environment variable types and require vars to use a type from that namespace. This avoids the annoying collision between this `string` and `std::string`, and makes everything a bit more consistent. Rename the types a bit to be more appropriate for this context: boolean, uint8, and uint32, instead of bool, uint8_t, and uint32_t.
As we now have docc doc catalogues and can have articles since
https://github.com/swiftlang/swift/pull/88061, we finally have a place
to put distributed actor system documentation!
Typically, the first node of a nested type is the type that contains it.
For example:
```
Demangling for $s7ModBase5OuterV5InnerC
kind=Global
kind=Class
kind=Structure
kind=Module, text="ModBase"
kind=Identifier, text="Outer"
kind=Identifier, text="Inner"
$s7ModBase5OuterV5InnerC ---> ModBase.Outer.Inner
```
However, when a type is declared inside an extension of "Outer", that
becomes part of the mangled name too. For example:
```
Demangling for $s7ModBase5OuterV6ModExtE5InnerC
kind=Global
kind=Class
kind=Extension
kind=Module, text="ModExt"
kind=Structure
kind=Module, text="ModBase"
kind=Identifier, text="Outer"
kind=Identifier, text="Inner"
$s7ModBase5OuterV6ModExtE5InnerC ---> (extension in ModExt):ModBase.Outer.Inner
````
DemanglingForTypeRef did not treat the extension case correctly, and was
losing the extension information. This patch fixes it.
Assisted-by: claude
rdar://176586425
Fix several early returns which didn't free the string copy made earlier in the function. Fix most of them by doing the string copy only at the very end where it's needed. When we race to insert into the cache and we lose that race, then free the copies before returning the other thread's cached entry.
rdar://170736413
**Explanation**:
Implementation of `Continuation` as proposed in upcoming SE proposal:
https://github.com/swiftlang/swift-evolution/pull/3246
This is a ~Copyable Continuation with much stronger safety guarantees
and no runtime overhead. Refer to proposal for details.
Initial work by @fabianfett.
**Scope**: Adds a new continuation type.
**Risk**: Low, adds new type, allows `~Copyable` into existing builtin
-- I believe this change should be safe (?)
**Testing**: Added lots of tests covering problems this aims to prevent.
**Issues**:
resolves rdar://174826360
Somewhat relevant to rdar://139975911
Co-authored-by: Fabian Fett <fabianfett@apple.com>
We've been hitting some issues where having the .swiftsourceinfo files
in the toolchain can cause hangs on macOS. Provide CMake-level control
for their generation so we can selectively enable them.
Fixes rdar://176894222
Allow _StringProcessing to use `@_silgen_name("swift_getTupleTypeMetadata")`
via `-enable-experimental-feature AllowRuntimeSymbolDeclarations`. Also, add
the missing `-DRESILIENT_LIBRARIES` flag to the Runtimes build for
_StringProcessing.
Even though `trackingLists.remove(_:)` returns a discardable result,
`withCriticalRegion` forwards that return value as its own return value, which
the compiler then flags as unused.
swift_allocBox was correctly computing allocation size/alignment.
swift_deallocBox was compiting it differently (and incorrectly).
Factor out the logic into a separate function that we use from both
places.
Now that `SwiftStdlib 6.3` maps to real versions for Apple's operating systems
(https://github.com/swiftlang/swift/pull/87510), checks like
```
if #available(StdlibDeploymentTarget 6.3, *) { ... }
```
inside the implementation of the stdlib are no longer necessary to satisfy the
availability checker and instead cause warnings to be emitted. Remove the now
superfluous checks.
This is a reattempt of https://github.com/swiftlang/swift/pull/87744. The
previous attempt was reverted because it turned out that there were some
configurations (outside of Swift CI) in which the stdlib was built with an
unnecessarily low deployment target. That has now been corrected, unblocking
this fix.
This header has `#pragma clang assume_nonnull begin` which causes nullability
annotations to be inferred for most declarations. However, Clang does not infer
`_Nonnull` for function pointer declarations where the return type is also a
pointer so explicit annotations are needed for a few declarations.
RemoteInspection was failing to produce type info for metatypes of
constrained existentials (any SomeType<ConstraintHere>.Type)
A constrained existential has the same layout as a regular protocol
composition, so we can use that instead.
rdar://176586637
John Hui
Konrad `ktoso` Malawski
Augusto Noronha
Carl Peto
Guillaume Lessard
Allan Shortlidge
Mike Ash
Doug Gregor
Alastair Houghton
Karoy Lorentey
Alejandro Alonso
David Smith