Otherwise in call frames like the one in the test in this commit get unneeded
ARC traffic. We should never pessimize read only code that doesnt need
side-effects with side-effects if we can avoid it.
I am seeing this a bunch when I look at SIL from projects that use a lot of
protocols. Specifically, one has a sort of trampoline code that wraps a ref
counted object in an existential ref container (which from an ARC perspective
doesn't imply ownership) and then calls a method on it or passes it off to some
other code.
Because of this requirement, there is a copy/destroy that can not be eliminated
unless we can devirt/inline/eliminate the init_existential_ref box, inline
enough that the low level ARC optimizer can hit it. We shouldn't rely on such
properties if we do not need to.
unchecked_take_enum_data_addr only writes to memory in certain cases. Optional
is not one of those cases luckily.
Given that I am adding support here just for optionals so that we can get rid of
temporaries that are used with a switch_enum_addr. This is an example of a case
where we need to eliminate temporary allocations to allow for Semantic ARC Opts
to eliminate further traffic.
This slightly regresses the standard library build (intentionally) while
generally improving the build of dispatch, foundation, xctest.
Rather than continuing to rely on the short-term hack of special casing
the standard library, identify the module where the decl originates
from. If the module is the current module, then assume that the symbol
need not be imported (static linking does not currently work on Windows
anyways). This allows for properly identifying the module where the
symbol will be homed.
Because we no longer special case the standard library here, a few known
metadata types will be incorrectly marked as being imported rather than
local.
Since linked entities which have `Shared` SILLinkage should be module
local, special case them to always be local. Without this the metadata
access function is still marked incorrectly.
With this computation we now get nearly all the cases correct. Dispatch
no longer has to rely on the linker relaxing the import to a local
binding. XCTest is also clean. Foundation misses the following case:
- `$sSS10FoundationE19_bridgeToObjectiveCAA8NSStringCyF`
The regressed cases in swiftCore are:
- `$sBi64_WV`
- `$sBi8_WV`
- `$sBi16_WV`
- `$sBi32_WV`
- `$sBpWV`
- `$syycWV`
- `$sBoWV`
- `$sBOWV`
- `$sBbWV`
- `$sytWV`
Using fallthroughs in general can lead to easy mistakes. This PR changes the
relevant code to use a helper instead. The reason why is that I am about to add
another instance of needing this exact helper and having to fall through
multiple switch cases will just make this even worse.
Because violations of this might have made an AbstractionPattern incorrectly show up as abstract, it's possible that this will cause an ABI change. However, I haven't been able to find any examples where it does, and certainly there's no way we can promise to maintain the old behavior, especially since it's not done consistently.
Reverts apple/swift#30006. It caused a regression that we'd like to address before re-landing:
```swift
struct X {
var cgf: CGFloat
}
func test(x: X?) {
let _ = (x?.cgf ?? 0) <= 0.5
}
```
This reverts commit 0a6b444b49.
This reverts commit ed255596a6.
This reverts commit 3e01160a2f.
This reverts commit 96297b7e39.
Resolves: rdar://problem/60185506
In order to allow this, I've had to rework the syntax of substituted function types; what was previously spelled `<T> in () -> T for <X>` is now spelled `@substituted <T> () -> T for <X>`. I think this is a nice improvement for readability, but it did require me to churn a lot of test cases.
Distinguishing the substitutions has two chief advantages over the existing representation. First, the semantics seem quite a bit clearer at use points; the `implicit` bit was very subtle and not always obvious how to use. More importantly, it allows the expression of generic function types that must satisfy a particular generic abstraction pattern, which was otherwise impossible to express.
As an example of the latter, consider the following protocol conformance:
```
protocol P { func foo() }
struct A<T> : P { func foo() {} }
```
The lowered signature of `P.foo` is `<Self: P> (@in_guaranteed Self) -> ()`. Without this change, the lowered signature of `A.foo`'s witness would be `<T> (@in_guaranteed A<T>) -> ()`, which does not preserve information about the conformance substitution in any useful way. With this change, the lowered signature of this witness could be `<T> @substituted <Self: P> (@in_guaranteed Self) -> () for <A<T>>`, which nicely preserves the exact substitutions which relate the witness to the requirement.
When we adopt this, it will both obviate the need for the special witness-table conformance field in SILFunctionType and make it far simpler for the SILOptimizer to devirtualize witness methods. This patch does not actually take that step, however; it merely makes it possible to do so.
As another piece of unfinished business, while `SILFunctionType::substGenericArgs()` conceptually ought to simply set the given substitutions as the invocation substitutions, that would disturb a number of places that expect that method to produce an unsubstituted type. This patch only set invocation arguments when the generic type is a substituted type, which we currently never produce in type-lowering.
My plan is to start by producing substituted function types for accessors. Accessors are an important case because the coroutine continuation function is essentially an implicit component of the function type which the current substitution rules simply erase the intended abstraction of. They're also used in narrower ways that should exercise less of the optimizer.
Clang 1200 appears to be returning us results from protocol
declarations when we run lookup for an Objective-C selector. This code
path can therefore see protocol requirements, and would erroneously
diagnose witnesses from Swift subclasses of Objective-C classes
as an attempt to conflict with the requirement in the
protocol itself.
This fix is super narrow to try to unblock our builds. Tests will follow
once I can reduce the issue.
Resolves rdar://60005962
These enable robust walking up the def-use ossa graph to find the value that
introduces an independent underlying owned value, looking through forwarding
insts.
[ownership] Implement InteriorPointer abstraction/validate current recognized ones addresses are not used outside of parent object's borrowed lifetime.
Wherever we have constraints that involve pattern matching, use the
PatternMatch locator element. Additionally, don't use the TupleElement
locator element for tuple patterns, because it violates assumptions used
for diagnostics.
The new test was crashing; now it has a terrible diagnostic for which I
need to think harder about a fix.
Currently, we only classify ref_element_addr and ref_tail_addr. But we should
expand this to project_box, project_existential_box and open_existential_box as
well.
Operands are generally better to return than values since the operand also
enables you to get to the terminator instruction as well. Since so much code in
the compiler already uses the getIncomingPhiValue methods, I reimplemented them
on top of the operand methods.
When we found Objective-C methods via selector lookup, we would skip the
“should we even try to import this?” check. If the Swift-name-as-derived-
from-Objective-C is different from the actual Swift name, we might try to
(redundantly) import something from the generated Objective-C header,
which can lead to crashes. The specific method causing problems was defined
like this in Swift:
@objc public class func using(index: AnyObject) -> AnyObject? { return nil }
which produced an Objective-C method like this:
+ (id _Nullable)usingIndex:(id _Nonnull)index;
The Swift name derived from the Objective-C method is `usingIndex(_:)`, which
of course does not match `using(index:)`, meaning that we think these two
methods are different (they aren’t).
The safe fix is to check whether we should import a given Objective-C method
declaration along the found-via-Objective-C-selector path, like we do with
normal name lookup. A longer term fix is to emit swift_name attributes for
such methods.
Fixes the fiendish Clang importer crash in rdar://problem/60046206.
Currently the printer only supports the subset of markdown used by
educational notes. It bolds headers, improves the appearance of lists
and horizontal rules, and does basic indenting of blockquotes and
code blocks.
In order for the runtime demangler to be able to find ObjC classes and protocols, it needs to
have the runtime name of the declaration be in the mangled name. Only do this for runtime manglings,
to minimize the potential ABI impact for symbol names that already have the source-level names of
ObjC entities baked in. Fixes SR-12169 | rdar://59306590.
