jiebi/CodeConvo huggingface dataset:
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: // NOTE: generics must be cleaned before args let generics = clean_generics(generics, cx); let args = clean_args_from_types_and_body_id(cx, sig.decl.inputs, body_id); <del> let decl = clean_fn_decl_with_args(cx, sig.decl, args); </del> <ins> let mut decl = clean_fn_decl_with_args(cx, sig.decl, args); if sig.header.is_async() { decl.output = decl.sugared_async_return_type(); } </ins> (generics, decl) }); Box::new(Function { decl, generics })
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: ///   <br>Used to determine line-wrapping. /// * `indent`: The number of spaces to indent each successive line with, if line-wrapping is ///   necessary. <del> /// * `asyncness`: Whether the function is async or not. </del> pub(crate) fn full_print<'a, 'tcx: 'a>( &'a self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> cx: &'a Context<'tcx>, ) -> impl fmt::Display + 'a + Captures<'tcx> { <del> display_fn(move |f| self.inner_full_print(header_len, indent, asyncness, f, cx)) </del> <ins> display_fn(move |f| self.inner_full_print(header_len, indent, f, cx)) </ins> } fn inner_full_print( &self, header_len: usize, indent: usize, <del> asyncness: hir::IsAsync, </del> f: &mut fmt::Formatter<'_>, cx: &Context<'_>, ) -> fmt::Result {
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: args_plain.push_str(", ..."); } <del> let arrow_plain; let arrow = if let hir::IsAsync::Async = asyncness { let output = self.sugared_async_return_type(); arrow_plain = format!("{:#}", output.print(cx)); if f.alternate() { arrow_plain.clone() } else { format!("{}", output.print(cx)) } } else { arrow_plain = format!("{:#}", self.output.print(cx)); if f.alternate() { arrow_plain.clone() } else { format!("{}", self.output.print(cx)) } }; </del> <ins> let arrow_plain = format!("{:#}", self.output.print(cx)); let arrow = if f.alternate() { arrow_plain.clone() } else { format!("{}", self.output.print(cx)) }; </ins> let declaration_len = header_len + args_plain.len() + arrow_plain.len(); let output = if declaration_len > 80 {
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: href = href, name = name, generics = g.print(cx), <del> decl = d.full_print(header_len, indent, header.asyncness, cx), </del> <ins> decl = d.full_print(header_len, indent, cx), </ins> notable_traits = notable_traits_decl(d, cx), where_clause = print_where_clause(g, cx, indent, end_newline), )
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: name = name, generics = f.generics.print(cx), where_clause = print_where_clause(&f.generics, cx, 0, Ending::Newline), <del> decl = f.decl.full_print(header_len, 0, header.asyncness, cx), </del> <ins> decl = f.decl.full_print(header_len, 0, cx), </ins> notable_traits = notable_traits_decl(&f.decl, cx), ); });
Code change:
produces: But I think it should be. For the HTML backend, rustdoc "resugars" the return type to get the from I think we should move this to a pass. cc does this change seem like a good idea. modify labels: +T-rustdoc +A-rustdoc-json
I'm not sure if it's worth adding a pass for this... Maybe handling this into a specific function shared between both formats could be a better idea?
We could call in . Or we could move this to when constructing . I'm not sure which makes most sense.
In directly seems like a good approach.

Related discussion:
text: <ins> // edition:2021 // ignore-tidy-linelength // Regression test for <https://github.com/rust-lang/rust/issues/101199> use std::future::Future; // @is "$.index[*][?(@.name=='get_int')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int')].inner.header.async" false pub fn get_int() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_async')].inner.decl.output" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_async')].inner.header.async" true pub async fn get_int_async() -> i32 { 42 } // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future')].inner.header.async" false pub fn get_int_future() -> impl Future<Output = i32> { async { 42 } } // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.kind" '"impl_trait"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.name" '"Future"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].name" '"Output"' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.decl.output.inner[0].trait_bound.trait.args.angle_bracketed.bindings[0].binding.equality.type" '{"inner": "i32", "kind": "primitive"}' // @is "$.index[*][?(@.name=='get_int_future_async')].inner.header.async" true pub async fn get_int_future_async() -> impl Future<Output = i32> { async { 42 } } </ins>
Code change:
I tried -ing this proc macro crate: rust /// pub extern crate procmacrocrate; /// /// #[macroexport] /// macrorules! foo { /// (path:ident)::) =( /// $crate::procmacrocrate::identity!{ /// path):: /// } /// ) /// } /// /// #[macroexport] /// macrorules! baz { /// () =( /// crate::BAR) /// ) /// } /// /// pub const BAR: u32 = 19; /// /// fn main(){ /// println!("{}", crate::baz!()); /// } /// /// I expected to see this happen: The test completes successfully Instead, this happened: The test fails compilation with this error: It most recently worked on: : This also fails in 1.62 and 1.63. This appears to be fixed in the beta channel, but I could not find a mention of this bug or a related one. It's entirely possible that the bug will trigger again in future versions if this code isn't used in tests. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisection shows it regressed in and got fixed in . Looks like this issue wasn’t deliberately fixed, since doesn’t call out any issue being fixed. Also did involve minor breakage, as discussed in its thread, but I haven’t looked into it enough to tell whether those cases of breakage were similar to this issue or different.
label A-macros, A-proc-macros
cc (author of ) and (author of ) (read above to see how these PRs are relevant)
Looking at the code changes from it makes sense that this regressed, as the call to () would have done a check and rejected creating . The code (which was originally introduced in : ), should've probably avoided the constructor from the get-go, but it wasn't an issue because wasn't a possible identifier in that case previously. In , I changed the logic there to avoid going through that constructor when re-building the tokens internally, so we don't do the broken validation on that side anymore, and the problem wouldn't happen anymore. I don't think there's much more to be done here, as it's fixed already on beta, and isn't likely to regress with the new design.
Thanks a lot for your insights!
label E-easy. (We only need a test to close this issue.)
For someone wanting to add a test for this, you should be able to add the use code in . You can see for an idea of what the test might look like.
claim

Related discussion:
text: <ins> // check-pass // edition:2021 // aux-build:test-macros.rs #![no_std] // Don't load unnecessary hygiene information from std extern crate std; #[macro_use] extern crate test_macros; macro_rules! foo { ($($path:ident)::*) => ( test_macros::recollect!( $($path)::* ) ) } macro_rules! baz { () => ( foo!($crate::BAR) ) } pub const BAR: u32 = 19; fn main(){ std::println!("{}", baz!()); } </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

Related discussion:
text: kw::Extern, kw::Impl, kw::Unsafe, <ins> kw::Const, </ins> kw::Static, kw::Union, kw::Macro,
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

Related discussion:
text: <ins> // run-rustfix mod test { pub const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

Related discussion:
text: <ins> // run-rustfix mod test { public const X: i32 = 123; //~^ ERROR expected one of `!` or `::`, found keyword `const` } fn main() { println!("{}", test::X); } </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.
Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection

Related discussion:
text: <ins> error: expected one of `!` or `::`, found keyword `const` --> $DIR/public-instead-of-pub-3.rs:3:12 | LL |     public const X: i32 = 123; |            ^^^^^ expected one of `!` or `::` | help: write `pub` instead of `public` to make the item public | LL |     pub const X: i32 = 123; |     ~~~ error: aborting due to previous error </ins>