generator: Work around invariance for assigning mutable pointer of lifetimed slice #841
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…fetimed slice In essence this builder function needs to adhere to two rules: 1. No ref-after-free: the slice must outlive (uses of) the builder object; 2. No aliasing: the slice cannot be (im)mutably used while it is mutably borrowed within a live builder object. These two rules have been tested and are satisfied by the given builder implementation. Without this change `timings` seems to be borrowing itself, hence is not allowed to be used after it has been temporarily mutably borrowed inside the builder, even after that builder was dropped. Thus defeating the purpose of this "getter" API via a struct. Without the `.cast()`, because mutable raw pointers are invariant (i.e. there is no subtyping relationship) the compiler complains about requiring `self` to outlive `timings` instead, which does not satisfy the two rules above.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #837
@Ralith I'm in quite a hurry but managed to piece together a rather minimal generator change to solve the issue, but probably did a horrible job of understanding, summarizing and re-explaining the issues with variance. Feel free to suggest something better, otherwise I'll revisit it when I return.
In essence this builder function needs to adhere to two rules:
These two rules have been tested and are satisfied by the given builder implementation. Without this change
timingsseems to be borrowing itself, hence is not allowed to be used after it has been temporarily mutably borrowed inside the builder, even after that builder was dropped. Thus defeating the purpose of this "getter" API via a struct.Without the
.cast(), because mutable raw pointers are invariant (i.e. there is no subtyping relationship) the compiler complains about requiringselfto outlivetimingsinstead, which does not satisfy the two rules above.