jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // This is a non-regression test for const-qualification of unstable items in libcore // as explained in issue #67053. // const-qualification could miss some `const fn`s if they were unstable and the feature // gate was not enabled in libcore. #![stable(feature = "core", since = "1.6.0")] #![feature(const_if_match)] #![feature(rustc_const_unstable)] #![feature(staged_api)] enum Opt<T> { Some(T), None, } impl<T> Opt<T> { #[rustc_const_unstable(feature = "foo")] #[stable(feature = "rust1", since = "1.0.0")] const fn unwrap_or_else<F: FnOnce() -> T>(self, f: F) -> T { //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR destructors cannot be evaluated at compile-time match self { Opt::Some(t) => t, Opt::None => f(), //~ ERROR E0015 } } } fn main() {} </ins>

Related discussion:
text: As shown in const-qualification can ignore some s, in the context of libcore / rustc crates: This should not compile without "miri unleashed"; const-qualification does not see this function as const since the unstable feature is not enabled, and thus does not check it. It outside of libcore, nor . cc More discussion is also available . I have a fix and will post a PR shortly. There are a couple of existing cases in where this matters (for and ), and I'll fix those at the same time.
Code change:
<ins> error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:1 | LL | / async fn wrapper<F>(f: F) LL | | LL | | LL | | LL | | where LL | |     F:, LL | |     for<'a> <i32 as FnOnce<(&'a mut i32,)>>::Output: Future<Output = ()> + 'a, | |______________________________________________________________________________^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:10 | LL | async fn wrapper<F>(f: F) |          ^^^^^^^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:13:1 | LL | / { LL | | LL | |     let mut i = 41; LL | |     &mut i; LL | | } | |_^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:1 | LL | / async fn wrapper<F>(f: F) LL | | LL | | LL | | LL | | where LL | |     F:, LL | |     for<'a> <i32 as FnOnce<(&'a mut i32,)>>::Output: Future<Output = ()> + 'a, | |______________________________________________________________________________^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: File: auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...
Code change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/111415>. // This test ensures that only impl blocks are documented in bodies. #![crate_name = "foo"] // @has 'foo/index.html' // Checking there are only three sections. // @count - '//*[@id="main-content"]/*[@class="small-section-header"]' 3 // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Structs' // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Functions' // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Traits' // Checking that there are only three items. // @count - '//*[@id="main-content"]//*[@class="item-name"]' 3 // @has - '//*[@id="main-content"]//a[@href="struct.Bar.html"]' 'Bar' // @has - '//*[@id="main-content"]//a[@href="fn.foo.html"]' 'foo' // @has - '//*[@id="main-content"]//a[@href="trait.Foo.html"]' 'Foo' // Now checking that the `foo` method is visible in `Bar` page. // @has 'foo/struct.Bar.html' // @has - '//*[@id="method.foo"]/*[@class="code-header"]' 'pub fn foo()' // @has - '//*[@id="method.bar"]/*[@class="code-header"]' 'fn bar()' pub struct Bar; pub trait Foo { fn bar() {} } pub fn foo() { pub mod inaccessible {} pub fn inner() {} pub const BAR: u32 = 0; impl Bar { pub fn foo() {} } impl Foo for Bar {} } </ins>

Related discussion:
text: <!-- 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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.
Code change:
let cache = cache(); write!(w, " <del> <h2 id='implementors'>Implementors</h2> </del> <ins> <h2 id='implementors' class='section-header'> <a href='#implementors'>Implementors</a> </h2> </ins> <ul class='item-list' id='implementors-list'> ")?; if let Some(implementors) = cache.implementors.get(&it.def_id) {

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
<ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </ins>

Related discussion:
text: <!-- 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 compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.
Code change:
<ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </ins>

Related discussion:
text: I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:
Code change:
<ins> //! Email me at <hello@example.com>. //! Email me at <hello-world@example.com>. //! Email me at <hello@localhost> (this warns but will still become a link). // @has email_address/index.html '//a[@href="mailto:hello@example.com"]' 'hello@example.com' // @has email_address/index.html '//a[@href="mailto:hello-world@example.com"]' 'hello-world@example.com' // @has email_address/index.html '//a[@href="mailto:hello@localhost"]' 'hello@localhost' </ins>

Related discussion:
text: <!-- 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: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- 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. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.
Code change:
<ins> //! Email me at <hello@example.com>. //! Email me at <hello-world@example.com>. //! Email me at <hello@localhost> (this warns but will still become a link). // @has email_address/index.html '//a[@href="mailto:hello@example.com"]' 'hello@example.com' // @has email_address/index.html '//a[@href="mailto:hello-world@example.com"]' 'hello-world@example.com' // @has email_address/index.html '//a[@href="mailto:hello@localhost"]' 'hello@localhost' </ins>

Related discussion:
text: Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in
Code change:
<ins> //@ check-pass // issue: rust-lang/rust#123824 // This test is a sanity check and does not enforce any stable API, so may be // removed at a future point. fn main() { let x = f32::from(3.14); let y = f64::from(3.14); } </ins>

Related discussion:
text: After we started seeing the following compile failure: I repro'd this locally on but we have so we're fairly sure that it started with . Of the changes in that rollup is the only one that seemed to touch float stuff, but I'm not sure how adding some extra impls for and would break inference in this case.
cc is it possible that adding the the impls for / may have caused type inference regression here?
It must be, but I don't know why since wasn't touched. Also reproduced locally
When there is only one applicable impl it can guide inference, as soon as there are multiple it can't use those and instead goes to default-numeric-fallback which appears to be for floating point.
Correct.
Just coming to the same conclusion - the literal is getting guided to f32 on stable since that's the only type that fits the , but when there are more options it gets the default float literal type of f64
I'll put up a PR to remove these impls for now but what is the correct longer term fix? cc
label -needs-triage +A-inference +F-f16andf128
Race condition <img width="497" alt="image" src=""
I did not remove the feature label lol (it wasn't even in the list), welldone GitHub
Theoretically, type inference regressions are permitted as part of Rust's 1.0 stability guarantees. In practice, if the regressions are too bad, the changes usually get reverted and are subsequently blocked indefinitely iirc. However, we could make use of editions if the worst comes to the worst. See arrays & . I think we have something similar queued up for Rust 2024. On mobile, can't link.
I put a fix up at and opened to further discuss what we want to do here. Thanks for identifying this so quick!
if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.
that we caught it on. It's a pretty simple case (that type is just an type alias) and seems reasonable to break on an edition boundary (or even just on a release as long as there's a machine applicable suggestion to fix it).
Hi! I'm from the Bevy project.
Code change:
<ins> //@ check-pass // issue: rust-lang/rust#123824 // This test is a sanity check and does not enforce any stable API, so may be // removed at a future point. fn main() { let x = f32::from(3.14); let y = f64::from(3.14); } </ins>

Related discussion:
text: We caught this bug with too, though the error originates from the crate (0.3.18).
Awesome, thanks for the report! I started a list of known regressions at , and there is a crater run going to figure out how best to deal with this behavior. The fix for this was merged so should be available on the next nightly (couple of hours?).
Code change:
<ins> error[E0277]: the size for values of type `dyn ToString` cannot be known at compilation time --> $DIR/issue-61525.rs:14:33 | LL |         1.query::<dyn ToString>("") |           -----                 ^^ doesn't have a size known at compile-time |           | |           required by a bound introduced by this call | = help: the trait `Sized` is not implemented for `dyn ToString` note: required by a bound in `Example::query` --> $DIR/issue-61525.rs:2:14 | LL |     fn query<Q>(self, q: Q); |              ^ required by this bound in `Example::query` help: consider relaxing the implicit `Sized` restriction | LL |     fn query<Q: ?Sized>(self, q: Q); |               ++++++++ error[E0308]: mismatched types --> $DIR/issue-61525.rs:14:33 | LL |         1.query::<dyn ToString>("") |           --------------------- ^^ expected trait object `dyn ToString`, found `&str` |           | |           arguments to this function are incorrect | = note: expected trait object `dyn ToString` found reference `&'static str` note: associated function defined here --> $DIR/issue-61525.rs:2:8 | LL |     fn query<Q>(self, q: Q); |        ^^^^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

Related discussion:
text: Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.
Code change:
use serde::{Deserialize, Serialize}; /// rustdoc format-version. <del> pub const FORMAT_VERSION: u32 = 19; </del> <ins> pub const FORMAT_VERSION: u32 = 20; </ins> /// A `Crate` is the root of the emitted JSON blob. It contains all type/documentation information /// about the language items in the local crate, as well as info about external items to allow

Related discussion:
text: At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
Code change:
opaque_type_key, self.fcx.infcx.tcx, true, <del> decl.origin, </del> ); self.typeck_results.concrete_opaque_types.insert(opaque_type_key.def_id, hidden_type);

Related discussion:
text: Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that