-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rustdoc-Json: Document HRTB's on DynTrait #99787
Conversation
} | ||
|
||
#[derive(Clone, Debug, PartialEq, Eq, Hash, Serialize, Deserialize)] | ||
pub struct PolyTrait { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure what the best name for this is. The compiler seems to use PolyTrait
everywhere for this, but I don't think it's ever used outside that context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know what it means ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A Trait with possible HRTB params
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't hesitate to add doc comments to explain what it stands for. Always appreciated.
Looks good to me. Considering how big this change is, a second opinion would be very appreciated though. cc @camelid @notriddle |
Thanks you so much for fixing this. I have skimmed through the change and it looks good to me. FYI, I have run the cargo-public-api test suite against this change and it found no regressions. The cargo-public-api test suite covers some cases the in-tree test suite does not (See e.g. cargo-public-api/cargo-public-api#67) so it's always nice to make sure nothing breaks for big changes like these, I think. |
☔ The latest upstream changes (presumably #99577) made this pull request unmergeable. Please resolve the merge conflicts. |
Because python doesn't have lexical scope, loop variables persist after the loop is exited, set to the value of the last itteration ``` >>> i = 0 >>> for i in range(10): pass ... >>> i 9 ``` This causes the `ty` variable to be changed, causing unexpected crashes on ``` pub type RefFn<'a> = &'a dyn for<'b> Fn(&'a i32) -> i32; ```
Rebased onto master, updated documentation, renamed @rustbot ready |
@@ -130,11 +140,11 @@ impl FromWithTcx<clean::GenericArgs> for GenericArgs { | |||
use clean::GenericArgs::*; | |||
match args { | |||
AngleBracketed { args, bindings } => GenericArgs::AngleBracketed { | |||
args: args.into_vec().into_iter().map(|a| a.into_tcx(tcx)).collect(), | |||
bindings: bindings.into_iter().map(|a| a.into_tcx(tcx)).collect(), | |||
args: args.into_vec().into_tcx(tcx), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to be doing the same thing but instead of creating one vector, it creates two. Did I miss something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah no nevermind. But then I wonder why the into_vec
is needed at all...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it’s not a Vec. It’s a boxed slice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably it could skip the into_vec
because of the impl for IntoIterator right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like @camelid said. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
args
is a Box<[GenericArg]>
, which doesn't impl IntoIterator
, but Vec
does and the conversion is zero cost. I guess you could impl <T, U: FromWithTcx<T>> FromWithTcx<Box<[T]>> for Vec<U>
, but I don't think thats worth it as it only comes up twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh strange. Well if it doesn't work don't worry about it then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes overall look good to me, though there are a few things I'd like changed. I haven't reviewed the tests.
@@ -130,11 +140,11 @@ impl FromWithTcx<clean::GenericArgs> for GenericArgs { | |||
use clean::GenericArgs::*; | |||
match args { | |||
AngleBracketed { args, bindings } => GenericArgs::AngleBracketed { | |||
args: args.into_vec().into_iter().map(|a| a.into_tcx(tcx)).collect(), | |||
bindings: bindings.into_iter().map(|a| a.into_tcx(tcx)).collect(), | |||
args: args.into_vec().into_tcx(tcx), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably it could skip the into_vec
because of the impl for IntoIterator right?
tcx: TyCtxt<'_>, | ||
) -> Self { | ||
PolyTrait { | ||
trait_: clean::Type::Path { path: trait_ }.into_tcx(tcx), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we keep it in Path form rather than allowing it to be any type. (Type definition needs to be updated too.)
trait_: clean::Type::Path { path: trait_ }.into_tcx(tcx), | |
trait_: trait_.into_tcx(tcx), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't yet have a ResolvedPath
type in the json output, so I think that should be done in a followup change, as theirs a couple of other places we'd also want to use it (
rust/src/librustdoc/json/conversions.rs
Line 423 in e141246
// FIXME: should `trait_` be a clean::Path equivalent in JSON? |
rust/src/librustdoc/json/conversions.rs
Line 500 in e141246
let trait_ = clean::Type::Path { path: trait_ }.into_tcx(tcx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, makes sense to hold off then.
@rustbot ready |
Ok @GuillaumeGomez this should be ready for your final review :) |
Looks good to me, thanks! @bors r=camelid,notriddle,GuillaumeGomez |
Rollup of 7 pull requests Successful merges: - rust-lang#96478 (Implement `#[rustc_default_body_unstable]`) - rust-lang#99787 (Rustdoc-Json: Document HRTB's on DynTrait) - rust-lang#100181 (add method to get the mutability of an AllocId) - rust-lang#100221 (Don't document impossible to call default trait items on impls) - rust-lang#100228 (Don't ICE while suggesting updating item path.) - rust-lang#100301 (Avoid `&str` to `String` conversions) - rust-lang#100305 (Suggest adding an appropriate missing pattern excluding comments) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Closes #99118
Probably best reviewed commit by commit.
@rustbot modify labels: +A-rustdoc-json
cc @Enselic
r? @CraftSpider