Skip to content
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

Merged
merged 5 commits into from
Aug 9, 2022
Merged

Conversation

aDotInTheVoid
Copy link
Member

Closes #99118

Probably best reviewed commit by commit.

@rustbot modify labels: +A-rustdoc-json

cc @Enselic

r? @CraftSpider

@rustbot rustbot added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jul 27, 2022
@rustbot rustbot added the A-rustdoc-json Area: Rustdoc JSON backend label Jul 27, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 27, 2022
}

#[derive(Clone, Debug, PartialEq, Eq, Hash, Serialize, Deserialize)]
pub struct PolyTrait {
Copy link
Member Author

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.

Copy link
Member

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 ?

Copy link
Member Author

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

Copy link
Member

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.

@GuillaumeGomez
Copy link
Member

Looks good to me. Considering how big this change is, a second opinion would be very appreciated though. cc @camelid @notriddle

@Enselic
Copy link
Member

Enselic commented Jul 28, 2022

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.

@bors
Copy link
Contributor

bors commented Jul 29, 2022

☔ 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;
```
@aDotInTheVoid
Copy link
Member Author

Rebased onto master, updated documentation, renamed trait_ to trait with #[serde(rename)].

@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),
Copy link
Member

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?

Copy link
Member

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...

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

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

Like @camelid said. :)

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

@camelid camelid left a 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),
Copy link
Member

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),
Copy link
Member

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.)

Suggested change
trait_: clean::Type::Path { path: trait_ }.into_tcx(tcx),
trait_: trait_.into_tcx(tcx),

Copy link
Member Author

@aDotInTheVoid aDotInTheVoid Aug 3, 2022

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 (

// FIXME: should `trait_` be a clean::Path equivalent in JSON?
,
let trait_ = clean::Type::Path { path: trait_ }.into_tcx(tcx);
)

Copy link
Member

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.

src/rustdoc-json-types/lib.rs Outdated Show resolved Hide resolved
src/rustdoc-json-types/lib.rs Outdated Show resolved Hide resolved
src/rustdoc-json-types/lib.rs Show resolved Hide resolved
@camelid camelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 31, 2022
@aDotInTheVoid
Copy link
Member Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 3, 2022
@camelid
Copy link
Member

camelid commented Aug 8, 2022

Ok @GuillaumeGomez this should be ready for your final review :)

@GuillaumeGomez
Copy link
Member

Looks good to me, thanks!

@bors r=camelid,notriddle,GuillaumeGomez

@bors
Copy link
Contributor

bors commented Aug 9, 2022

📌 Commit 6290f92 has been approved by camelid,notriddle,GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 9, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2022
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
@bors bors merged commit e41be25 into rust-lang:master Aug 9, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 9, 2022
aDotInTheVoid added a commit to rust-lang/rustdoc-types that referenced this pull request Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rustdoc JSON: Support for &dyn for<'a> Trait<'a>
10 participants