-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
[WIP] rustdoc (base+json): add support for variances #123219
base: master
Are you sure you want to change the base?
Conversation
In anticipation of adding variance to them.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
[WIP] rustdoc (base+json): add support for variances I had this patch lying around for more than a month without much progress. Submitting this now to move things forward hopefully. Addresses part of rust-lang#22108. --- For transparency, I've stalled work on this because I haven't had the time to find ways to obtain or represent the “reason” / “provenance” of variances — a feature kindly requested by `@obi1kenobi,` maintainer of cargo-semver-checks. With “reason” we're referring to the set of constituent types that have had an influence on the variance of a given generic parameter. This information could then be used in the diagnostics of cargo-semver-checks à la “variance of param `T` of ty `S` changed from covariant to contravariant because you changed the type of field `f` from `T` to `fn(T)”. On second thought, this seems like a major add-on and I fear that it's infeasible to implement this (smh. exposing the necessary info from rustc). On the other hand, this feature probably has a large impact on the design of the final API (i.e., how we represent variances in rustdoc JSON). I definitely don't want to hand-roll variance computation inside rustdoc. --- TODOs: * clean up the implementation (see individual FIXMEs) * write docs for `rustdoc-json-types` * add rustdoc JSON tests r? ghost
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (77b18b0): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 668.236s -> 667.965s (-0.04%) |
3781173
to
e381cb4
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #123340) made this pull request unmergeable. Please resolve the merge conflicts. |
@fmease any updates on this? thanks |
I had this patch lying around for more than a month without much progress. Submitting this now to move things forward hopefully.
Addresses part of #22108.
For the sake transparency let me mention that I've stalled work on this because I haven't had the time to find ways to obtain or represent the “reason” / “provenance” of variances — a feature kindly requested by @obi1kenobi, maintainer of cargo-semver-checks. With “reason” we're referring to the set of constituent types that have had an influence on the variance of a given generic parameter.
This information could then be used in diagnostics emitted by cargo-semver-checks à la “variance of param
T
of tyS
changed from covariant to contravariant because you changed the type of fieldf
fromT
tofn(T)
. On second thought though, this seems like a major add-on and I fear that it's infeasible to implement (smh. exposing the necessary info from rustc). On the other hand, this feature probably has a large impact on the design of the final API (i.e., how we represent variances in rustdoc JSON). I definitely don't want to hand-roll variance computation inside rustdoc.TODOs:
rustdoc-json-types
r? ghost