Skip to content

[AutoDiff] SR-12526: cross-module @derivative deserialization #30851

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Apr 8, 2020

Conversation

marcrasi
Copy link

@marcrasi marcrasi commented Apr 7, 2020

When deserializing a @derivative attribute that declares a derivative for a function in a different module, we can't immediately resolve the reference to the function. So this PR adds a lazy resolver to the @derivative attribute that resolves the original function only when we actually need it (most of this was done by @dan-zheng, thanks!). To handle the case where the @derivative attribute is parsed and typechecked, we keep the AbstractFunctionDecl* pointer too. The getOriginalFunction request returns the AbstractFunctionDecl* if it's available, and otherwise uses the lazy resolver.

Resolves SR-12526.

dan-zheng and others added 2 commits April 6, 2020 06:37
Start fixing SR-12526: `@derivative` attribute cross-module deserialization
crash. Remove original `AbstractFunctionDecl *` from `DerivativeAttr` and store
`DeclID` instead, mimicking `DynamicReplacementAttr`.
@marcrasi marcrasi requested a review from dan-zheng April 7, 2020 17:22
@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

@swift-ci please test

@marcrasi marcrasi force-pushed the derivative-attr-serialization branch from a4e4fa4 to 2d1436e Compare April 7, 2020 17:27
Copy link
Contributor

@dan-zheng dan-zheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clever PointerUnion design, nice!

@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

@swift-ci please test

1 similar comment
@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Apr 7, 2020

Build failed
Swift Test OS X Platform
Git Sha - 2d1436e

@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

Wow, I have realized that this PR is completely broken: there is no code path that sets the lazy resolver!

The only reason this PR fixes the test is that I add the public init() to fix a typechecker error, and this somehow has the side effect of making deserialization succeed. Maybe the typechecker error triggers extra deserialization that doesn't happen when the code is fully valid. This test is not a very "robust" test of the problem.

So I'm going to add a code path that sets the lazy resolver, and I'm going try to make a more robust test.

@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

Okay, this PR is fixed now. I wasn't able to quickly find any other way of triggering the error other than the missing init(), so I have left the test with the missing init() even though it seems a bit non-robust.

@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

@swift-ci please test

1 similar comment
@marcrasi
Copy link
Author

marcrasi commented Apr 7, 2020

@swift-ci please test

@dan-zheng
Copy link
Contributor

Maybe the typechecker error triggers extra deserialization that doesn't happen when the code is fully valid. This test is not a very "robust" test of the problem.

I believe the extra deserialization occurs when a declaration (the missing Struct.init) cannot be found. A reference to a missing declaration triggers deserialization to find the declaration if at all possible.

@marcrasi marcrasi merged commit eefe9a0 into master Apr 8, 2020
@marcrasi marcrasi deleted the derivative-attr-serialization branch April 8, 2020 00:23
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.

3 participants