Skip to content

Conversation

@NobodyNada
Copy link
Contributor

@NobodyNada NobodyNada commented Feb 21, 2020

Re-applies #28799, with a fix for the bug requiring it to be reverted (#29946).

rdar://problem/59615127

We have an optimization in SILCombiner that "inlines" the use of compile-time constant key paths by performing the property access directly instead of calling a runtime function (leading to huge performance gains e.g. for heavy use of @dynamicMemberLookup). However, this optimization previously only supported key paths which solely access stored properties, so computed properties, optional chaining, etc. still had to call a runtime function. This commit generalizes the optimization to support all types of key paths.
When a computed property returns a generic, the accessor's function
type may involve a type parameter that needs to be resolved using
the key path instruction's substitution map.
emitKeyPathComponentForDecl was only checking if the setter was
accessible from the current module, not the current function.
This failed when accessing an internal setter from a module
imported for testing.
I was inconsistently providing initialized or uninitialized memory
to the callback when projecting a settable address, depending on
component type. We should always provide an uninitialized address.
Because parentValue is the result of a setter projection, it is uninitalized and should not be destroyed again (see 1feead8)
@jckarter
Copy link
Contributor

@swift-ci Please test

@jckarter
Copy link
Contributor

Thanks!

@jckarter jckarter merged commit 0fb4ea1 into swiftlang:master Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants