jiebi/CodeConvo huggingface dataset:
Code change:
(desktop) Safari the search box here: a letter the letter another letter how the empty space below the search bar changes size cc – I think this is a recent regression; it's in nightly. I presume it has some connection to either your "All crates" change or your sidebar change. This bug is not present in beta.
Hm, I can't reproduce on desktop Safari 15.1. Can you share a video? I can observe a small change in the width of the sidebar between typing a letter and deleting. I'll investigate that.
I'm on Safari 15.2, though I'm not sure if it matters. I'll see if I can get a video sometime soon but I'm a bit busy right now.
https://user-
Thanks!
Thanks for the video that really helped me figure out what I was looking for. I was able to bisect it to (moving the crate dropdown onto the search page). Surprisingly, the minimum diff that causes the issue was not any of the CSS, but removing the dropdown element. So long as the search input has a previous sibling of any kind, the bumpiness does not happen. It's quite mysterious. I haven't been able to find a style that causes this.

Related discussion:
text: </div> {#- -#} <form class="search-form"> {#- -#} <div class="search-container"> {#- -#} <ins> <span></span> {#- This empty span is a hacky fix for Safari - See #93184 -#} </ins> <input {# -#} class="search-input" {# -#} name="search" {# -#}
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. --I tried this code: I expected to see this happen: intradoc links for the block residing in (where is not defined) are valid links. Instead, this happened: Rustdoc thinks that , resolved to , is not in scope here: A workaround is to make sure that , without prefix, is in scope: In other words, it seems that in intradoc links resolve to the name of the item, not the full path? <!-- 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. --:
I'll see if I can look into this. If someone else wants to work on it, feel free to claim it from me!
This appears to have since been fixed, probably by .
Actually, it'd probably be good to add a test for this.
Thanks! That looks to already have trickled down into recent stable rust releases, as I can't reproduce it with . Awesome!

Related discussion:
text: <ins> // Regression test for #93205 #![crate_name = "foo"] mod generated { pub struct MyNewType; impl MyNewType { pub const FOO: Self = Self; } } pub use generated::MyNewType; mod prelude { impl super::MyNewType { /// An alias for [`Self::FOO`]. // @has 'foo/struct.MyNewType.html' '//a[@href="struct.MyNewType.html#associatedconstant.FOO"]' 'Self::FOO' pub const FOO2: Self = Self::FOO; } } </ins>
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: self } <ins> /// Clear any existing suggestions. pub fn clear_suggestions(&mut self) -> &mut Self { if let Ok(suggestions) = &mut self.suggestions { suggestions.clear(); } self } </ins> /// Helper for pushing to `self.suggestions`, if available (not disable). fn push_suggestion(&mut self, suggestion: CodeSuggestion) { if let Ok(suggestions) = &mut self.suggestions {
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: forward!(pub fn set_is_lint(&mut self,) -> &mut Self); forward!(pub fn disable_suggestions(&mut self,) -> &mut Self); <ins> forward!(pub fn clear_suggestions(&mut self,) -> &mut Self); </ins> forward!(pub fn multipart_suggestion( &mut self,
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: //    | //    = note: cannot satisfy `_: Tt` <ins> // Clear any more general suggestions in favor of our specific one err.clear_suggestions(); </ins> err.span_suggestion_verbose( span.shrink_to_hi(), &format!(
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | = help: normalized in stderr note: required by a bound in `DiagnosticBuilder::<'a, G>::set_arg` <del> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:538:19 </del> <ins> --> $COMPILER_DIR/rustc_errors/src/diagnostic_builder.rs:539:19 </ins> | LL |         arg: impl IntoDiagnosticArg, |                   ^^^^^^^^^^^^^^^^^ required by this bound in `DiagnosticBuilder::<'a, G>::set_arg`
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | LL | fn foo<T, K, W: Default, Z: Default>(t: T, k: K) -> Foo<T, K, W, Z> { |                 ^^^^^^^ required by this bound in `foo` <del> help: consider giving `foo` an explicit type, where the type for type parameter `W` is specified | LL |     let foo: Foo<i32, &str, W, Z> = foo(1, ""); |            ++++++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let foo = foo::<T, K, W, Z>(1, "");
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | LL | fn bar<T, K, Z: Default>(t: T, k: K) -> Bar<T, K, Z> { |                 ^^^^^^^ required by this bound in `bar` <del> help: consider giving `bar` an explicit type, where the type for type parameter `Z` is specified | LL |     let bar: Bar<i32, &str, Z> = bar(1, ""); |            +++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let bar = bar::<T, K, Z>(1, "");
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |         .get::<Q>(&"key".into()) |             +++++ </del> help: consider specifying the type argument in the function call | LL |         .get::<Q>(&"key".into())
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | LL |         K: Borrow<Q>, |            ^^^^^^^^^ required by this bound in `HashMap::<K, V, S>::get` <del> help: consider specifying the generic argument | LL |     opts.get::<Q>(opt.as_ref()); |             +++++ </del> help: consider specifying the type argument in the function call | LL |     opts.get::<Q>(opt.as_ref());
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: |    ---- required by a bound in this LL | where T : Convert<U> |           ^^^^^^^^^^ required by this bound in `test` <del> help: consider specifying the generic arguments | LL |     test::<i32, U>(22, std::default::Default::default()); |         ++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     test::<T, U>(22, std::default::Default::default());
Code change:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim

Related discussion:
text: | LL | fn foo<T: Into<String>>(x: i32) {} |           ^^^^^^^^^^^^ required by this bound in `foo` <del> help: consider specifying the generic argument | LL |     foo::<T>(42); |        +++++ </del> help: consider specifying the type argument in the function call | LL |     foo::<T>(42);
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. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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 bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim

Related discussion:
text: if self.has_root() { return false; } <del> let mut iter = self.path[self.prefix_len()..].iter(); </del> <ins> let mut iter = self.path[self.prefix_remaining()..].iter(); </ins> match (iter.next(), iter.next()) { (Some(&b'.'), None) => true, (Some(&b'.'), Some(&b)) => self.is_sep_byte(b),
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. --This code panics on Windows: According to the documentation for , it should either succeed or return . Instead, it panics due to an out-of-range index: <!-- 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 bug is also present in nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I can confirm this. The problem originates in . A minimal example:
It seems that the in causes the issue, I'll try to fix.
claim

Related discussion:
text: assert_eq!(prefix, parse_prefix(r"/?C:windowssystem32notepad.exe")); assert_eq!(prefix, parse_prefix(r"?/C:windowssystem32notepad.exe")); } <ins> // See #93586 for more infomation. #[test] fn test_windows_prefix_components() { use crate::path::Path; let path = Path::new("C:"); let mut components = path.components(); let drive = components.next().expect("drive is expected here"); assert_eq!(drive.as_os_str(), OsStr::new("C:")); assert_eq!(components.as_path(), Path::new("")); } </ins>
Code change:
Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

Related discussion:
text: this.visit_ty(&ty); } } <del> GenericParamKind::Const { ref ty, .. } => { </del> <ins> GenericParamKind::Const { ref ty, default } => { </ins> let was_in_const_generic = this.is_in_const_generic; this.is_in_const_generic = true; walk_list!(this, visit_param_bound, param.bounds); this.visit_ty(&ty); <ins> if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } </ins> this.is_in_const_generic = was_in_const_generic; } }
Code change:
Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

Related discussion:
text: <ins> struct X<const N: usize = { (||1usize)() //~^ ERROR calls in constants are limited to }>; fn main() {} </ins>
Code change:
Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

Related discussion:
text: <ins> error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants --> $DIR/issue-93647.rs:2:5 | LL |     (||1usize)() |     ^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0015`. </ins>
Code change:
Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ? Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta

Related discussion:
text: <ins> struct Foo< 'a, const N: usize = { let x: &'a (); //~^ ERROR use of non-static lifetime `'a` in const generic 3 }, >(&'a ()); fn main() {} </ins>