We can encounter these when the compiler modifies an inlinable
function to break apart a struct and the struct uses a private
type for one of its fields. It's questionable whether we /should/
handle this, but meanwhile this /is/ a non-intrusive fix that
preserves the performance of non-resilient libraries.
(That is, it appears this worked in Swift 4.0, though perhaps
not all of the same optimizations kicked in.)
https://bugs.swift.org/browse/SR-6874
The asserts call getType() which can be slow in some corner cases (it calls into the generic signature builder).
Speeds up the compilation (with an assert-compiler) of the DoubleWidth benchmark by 4x.
rdar://problem/36887449
This takes more than 15 minutes to compile and makes the benchmark suite
unusable. There are multiple severe compile issues that need to be fixed
properly before we can support the DoubleWidth API.
See [SR-6947] DoubleWidth compile time.
Something useful that I use all the time that I would like to give to others. It
enables emacs compile-mode to be used like a standalone-ish application instead
of one application with many modes, one of which is compile-mode.
Given any heap object, this method dumps:
* The pointer address of the heap object.
* The pointer address of the heap metadata of the object.
* The strong reference count.
* The unowned reference count.
* The weak reference count.
* Whether or not the value is in the deinit state.
* Whether or not the heap object uses swift_retain or objc_retain.
* The address of the object's side table if one exists.
This makes it really easy when debugging quickly to get all of the information
that you could possibly need from a HeapObject.
I also added an option called sil-assert-on-exclusivity-failure that causes the
optimizer to assert if an exclusivity failure is hit. This enables quicker
debugging of exclusivity violations since at the assertion point, you drop
straight down into the debugger. This is only enabled with asserts.
rdar://34222540
4b25945 changed codegen for lvalue OpenExistentialExprs so that the existential was not opened until the OpaqueValue's lvalue was evaluated, but this is incorrect—we need to open the dynamic type of the existential immediately since it can be used arbitrarily within the subexpression. This caused a regression when evaluating default argument generators on protocol extension methods (rdar://problem/37031037), and would become a bigger problem when we generalize the ability to open existentials.
We inadvertantly allowed a function conversion for Swift 4 that we did
not intend to allow.
This commit adds an extremely narrow fix to continue to allow this for
-swift-verson 4 only.
Fixes rdar://problem/36875195 / https://bugs.swift.org/browse/SR-6837
When using SwiftSyntax as a standalone tool, we invoke Swiftc
internally to get serialized syntax trees. This is not ideal for
several reasons: (1) we have to hard-code the relative path of swiftc
to invoke it; (2) we have to rely on standard input/output to pass the
tree across the process boundaries; and (3) we have to maintain two
different ways to get syntax tree (swiftc and sourcekitd).
This patch attempts to teach SwiftSyntax to use SourceKitd to get the
tree just like other clients. We first add a SourceKitd client library
written in Swift; and next teach SwiftSyntax to adopt this SourceKitd
client-side library. For platforms other than MacOS, we still use Swiftc
to get syntax trees. This client library also allows us to add
SourceKitd tests in Swift.
This patch also re-enables several flaky tests.
Increase solution score when performing function conversions where only
one side has `@autoclosure`. That is going to help pick the best overload
when only difference lays in presence of such attribute.
e.g.
```swift
func foo(_: @autoclosure () -> Int) {}
func foo(_: () -> Int) {}
```
If the argument is itself `@autoclosure` it's preferable to use overload
with `@autoclosure` attribute, otherwise `() -> Int` should be used.
Resolves: rdar://problem/37160679
@noescape function types will eventually be trivial. A
convert_escape_to_noescape instruction does not take ownership of its
operand. It is a projection to the trivial value carried by the closure
-- both context and implementation function viewed as a trivial value.
A safe SIL program must ensure that the object that the project value is based
on is live beyond the last use of the trivial value. This will be
achieve by means of making the lifetimes dependent.
For example:
%e = partial_apply [callee_guaranteed] %f(%z) : $@convention(thin) (Builtin.Int64) -> ()
%n = convert_escape_to_noescape %e : $@callee_guaranteed () -> () to $@noescape @callee_guaranteed () -> ()
%n2 = mark_dependence %n : $@noescape @callee_guaranteed () -> () on %e : $@callee_guaranteed () -> ()
%f2 = function_ref @use : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
apply %f2(%n2) : $@convention(thin) (@noescape @callee_guaranteed () -> ()) -> ()
release_value %e : $@callee_guaranteed () -> ()
Note: This is not yet actually used.
Part of:
SR-5441
rdar://36116691
[string] Clean up StringObject; Clarify its tagged BridgeObjects.
Bifurcate StringObjects raw bit-pattern initializers to expose whether
the caller is passing a value rather than a reference. This way,
StringObject can call the approprite BridgeObject helper and
participate in upcoming peephole optimizations like retains of
known-values. This is all meant to be a NOP.
Additionally, do some cleanup while we're at it.
Update IRGen to trigger generation of type metadata for foreign
struct types found in fields. And fix TypeRefBuilder to handle
the case where struct has fields but at the same time has opaque
metadata.
I had builds failing during testing because the tail command inside:
test/IDE/print_clang_bool_bridging.swift,
test/IDE/print_clang_swift_name.swift
did not use the -n option. This should make the invocation of the
default tail command compatible with the one provided by coreutils.
Currently this file just imports lldbDataFormatters.py from llvm without the
user needing to know about it. I want to begin adding more utility (for
instance, graphing an assembly CFG without needing to copy/paste) to this file.
To use this in lldb run:
command script import $SWIFT_DIR/utils/lldbToolBox.py
