jiebi/CodeConvo huggingface dataset:
Change:
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 {

Discussion:
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.
Change:
<ins> warning: function cannot return without recursing --> $DIR/recursive.rs:3:1 | LL | const fn f<T>(x: T) { | ^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL |     f(x); |     ---- recursive call site | = note: `#[warn(unconditional_recursion)]` on by default = help: a `loop` may express intention better if this is on purpose error: any use of this value will cause an error --> $DIR/recursive.rs:4:5 | LL |     f(x); |     ^^^^ |     | |     reached the configured maximum number of stack frames |     inside `f::<i32>` at $DIR/recursive.rs:4:5 |     [... 126 additional calls inside `f::<i32>` at $DIR/recursive.rs:4:5 ...] |     inside `X` at $DIR/recursive.rs:9:15 ... LL | const X: () = f(1); | ------------------- | = note: `#[deny(const_err)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to previous error; 1 warning emitted </ins>

Discussion:
Given the following code (): The current output is: <details<summaryMassive diagnostic</summary</detailsIdeally, the duplicate lines should be hidden: modify labels: +A-const-fn +D-verbose <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
(accepted, type_alias_enum_variants, "1.37.0", Some(49683)), /// Allows macros to appear in the type position. (accepted, type_macros, "1.13.0", Some(27245)), <ins> /// Allows using type privacy lints (`private_interfaces`, `private_bounds`, `unnameable_types`). (accepted, type_privacy_lints, "CURRENT_RUSTC_VERSION", Some(48054)), </ins> /// Allows `const _: TYPE = VALUE`. (accepted, underscore_const_names, "1.37.0", Some(54912)), /// Allows `use path as _;` and `extern crate c as _;`.

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use super::*; pub struct S; </ins>

Discussion:
This code compiles: However, splitting the code into files causes compilation to fail: I am not sure whether or use is correct; regardless, replacing the latter with the former in produces a similar error:
cc
This appears to work now.
Change:
<ins> // check-pass </ins> // Regression test for issue #57611 // Ensures that we don't ICE <del> // FIXME: This should compile, but it currently doesn't // known-bug: unknown </del> #![feature(trait_alias)] #![feature(type_alias_impl_trait)]

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
<ins> use std::borrow::Borrow; pub trait Equivalent<K: ?Sized> { fn equivalent(&self, key: &K) -> bool; } impl<Q: ?Sized, K: ?Sized> Equivalent<K> for Q where Q: Eq, K: Borrow<Q>, { fn equivalent(&self, key: &K) -> bool { PartialEq::eq(self, key.borrow()) } } </ins>

Discussion:
I was checking if exposed  and found these seemingly non existent methods
It looks like the search results are present on (and after), but not on (or before)
Seems that's when std's hashbrown was upgraded to that the trait -
Change:
<ins> // This test created a generator whose size was not rounded to a multiple of its // alignment. This caused an assertion error in codegen. // build-pass // edition:2018 #![feature(async_await)] async fn noop() {} async fn foo() { // This suspend should be the largest variant. { let x = [0u8; 17]; noop().await; println!("{:?}", x); } // Add one variant that's aligned to 8 bytes. { let x = 0u64; noop().await; println!("{:?}", x); } } fn main() { let _ = foo(); } </ins>

Discussion:
I just ran into this ICE: I can't share the code but here are some observations: The ICE occurs in debug mode as well. It does not occur when running . It does not* occur on my MacBook (same nightly, different architecture). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Can you try to isolate the code, e.g. produce some code (not longer than 50 lines) that reproduces this issue?
I have no idea where to even start. Maybe a  run will help.
How big is the code? You could start by removing 'mod xxx' in your Remove types that are not needed. Then if you only have a few files left, merge them into one and remove more things (e.g. not needed functions, structs, enums), try to replace macros with their actual content.
Using I have determined that the ICE started to appear with (). I'll try to isolate the code now.
i'm hitting this too, will see if i can make a small repro. building for target from a linux x86_64 host.
My project doesn't build for ARM even with , which casts doubt on the above rollup merge containing the cause, I think. (Also possible that there are two similar bugs introduced at different times.) I'll try to bisect.
My bisect indicates the regression was introduced in . Armed with this clue I'm trying to figure out which part of my (giant) project is triggering it in order to make a repro.
I've narrowed down the block of code that triggers the regression, and simplified it to the extent possible, but when extracted from the project it no longer causes rustc to panic. In case it's useful: If the line with the arrow is commented out, the code compiles. Uncommented, it fails with: Will update if I have any success producing a standalone reproduction.
OK, I managed to extract a standalone reproduction:
cc
I a comment in the repo; you can make it build or fail to build by just reversing the order of two lines of code.
I updated the repo by folding a minimised implementation of into it rather than depending on the crate, since seemed to be necessary to trigger the bug.

In doing so I updated to std::future and the ICE disappeared. Adding to round-trip the future through a 0.1 Future brings the ICE back. (see comments in )
claim
Thanks for reporting this! Fix should be landing soon.
Change:
<ins> // compile-flags:-C panic=abort #![no_std] pub struct Foo; fn main() { Foo.bar() //~^ ERROR E0599 } #[panic_handler] fn panic(_info: &core::panic::PanicInfo) -> ! { loop{} } </ins>

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-60818-struct-constructors.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ </ins>

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
impl<'mir, 'tcx, Tag, Extra> Frame<'mir, 'tcx, Tag, Extra> { /// Return the `SourceInfo` of the current instruction. <del> pub fn current_source_info(&self) -> Option<mir::SourceInfo> { self.loc.map(|loc| { let block = &self.body.basic_blocks()[loc.block]; if loc.statement_index < block.statements.len() { block.statements[loc.statement_index].source_info } else { block.terminator().source_info } }) </del> <ins> pub fn current_source_info(&self) -> Option<&mir::SourceInfo> { self.loc.map(|loc| self.body.source_info(loc)) </ins> } }

Discussion:
Some Miri tests, e.g. , now ICE with This is a regression introduced by The likely cause is Cc
I removed "regression from stable" as Miri does not exist on stable.
Sorry, got it.
Change:
<ins> // check-pass </ins> fn f() -> impl Sized { <del> enum E { //~ ERROR </del> <ins> enum E { </ins> V(E), } unimplemented!() }

Discussion:
If we run with the option on this code: Both and are documented, but not being accessible outside of , it shouldn't be documented.
probably knows this, but for others seeing this issue, I think it's probably due to (which was reverted in , and later re-applied in ). It has to do with the fact that we're using a HIR visitor now, so we're visiting nested items unconditionally.
Yes I know where it's coming from. :smile: I was just thinking today that since we were going through the whole HIR without checking whether or not we were in a block, all elements inside the block could be visible. Tested and... :fearful: Should be pretty easy to fix.
For reference, I put up because this was causing documentation to become really verbose with serde + . If you fix this such that we no longer document those items, we could probably revert that PR.
Indeed. Don't hesitate to come to me if you have such issues with rustdoc. Such problems should definitely not go unnoticed.
The thing is, it was not particularly clear from the PRs whether this was intentional or not.
Unfortunately it wasn't. The goal was to retrieve the missing impl blocks. But if anything isn't clear, don't hesitate to ask too. :wink:
Change:
<ins> #[derive(Clone)] pub struct PublicStruct; mod inner { use super::PublicStruct; impl PublicStruct { /// [PublicStruct::clone] pub fn method() {} } } </ins>

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.
Change:
&method.fty.sig, self.covariant); } <del> ty::TypeTraitItem(_) => {} </del> <ins> ty::TypeTraitItem(ref data) => { // Any trait with an associated type is // invariant with respect to all of its // inputs. See length discussion in the comment // on this module. let projection_ty = ty::mk_projection(tcx, trait_def.trait_ref.clone(), data.name); self.add_constraints_from_ty(&trait_def.generics, projection_ty, self.invariant); } </ins> } } }

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
} partial_eq_impl! { <del> bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 </del> <ins> bool char usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f16 f32 f64 f128 </ins> } macro_rules! eq_impl {

Discussion:
<!-- 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. --Playground nightly version: 1.79.0-nightly (2024-03-25 ) This isn't expected since it doesn't seem to hit a label +T-compiler +f-f16andf128 +I-ICE +requires-incomplete-features +S-has-mcve claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label -needs-triage
Minimized:
Looks like it just expects primitives to be . I'm not sure where exactly this assumption comes from, but might as well fix it before the rest of libs support can get merged.
Change:
<ins> running 4 tests test short_bench_name ... ok test short_test_name ... ok test this_is_a_really_long_bench_name ... ok test this_is_a_really_long_test_name ... ok test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in ??s </ins>

Discussion:
libtest output recently started indenting some but not all test results: Seems like benchmarks are indented but regular tests are not.
Cc any idea which change might have caused this? I think this must be fairly recent but haven't tried bisecting yet.
Is this still reproducable?
With this can no longer be tested using x.py, since bootstrap now does test output formatting itself. So this now needs a little cargo project with a test and a benchmark, to check what libtest actually does.
It is because benches are dynamic, and they always use padding (and tests are static): I'm not sure why padding is different for static vs dynamic. Here is a repro:
Seems like that could use context if the bench is only being run as a test, then don't pad. The padding is desirable for benchmark output so the numeric values line up, for easier visual comparison. You could argue either way about tests -- maybe ok/FAILED would stand out even more with padded alignment.
PR with regression tests and a fix (in that order):
Change:
<ins> error[E0038]: the trait `FromResidual` cannot be made into an object --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:10:17 | LL |     let b: &dyn FromResidual = &(); |                 ^^^^^^^^^^^^ | = note: it cannot use `Self` as a type parameter in a supertrait or `where`-clause error[E0038]: the trait `FromResidual` cannot be made into an object --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:10:12 | LL |     let b: &dyn FromResidual = &(); |            ^^^^^^^^^^^^^^^^^ `FromResidual` cannot be made into an object | note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/canonicalize-fresh-infer-vars-issue-103626.rs:2:8 | LL | trait FromResidual<R = <Self as Try>::Residual> { |       ------------ this trait cannot be made into an object... LL |     fn from_residual(residual: R) -> Self; |        ^^^^^^^^^^^^^ ...because associated function `from_residual` has no `self` parameter help: consider turning `from_residual` into a method by giving it a `&self` argument | LL |     fn from_residual(&self, residual: R) -> Self; |                      ++++++ help: alternatively, consider constraining `from_residual` so it does not apply to trait objects | LL |     fn from_residual(residual: R) -> Self where Self: Sized; |                                           +++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0038`. </ins>

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2022-02-10 to nightly-2022-10-26 regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regressed in , specifically in . cc
Minimized:
This no longer ICEs, afaict.
According to , this got fixed in one of these commits: found 7 bors merge commits in the specified range commit[0] 2023-01-08: Auto merge of - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum commit[1] 2023-01-08: Auto merge of - geeklint:loosenweakdebug_bound, r=dtolnay commit[2] 2023-01-09: Auto merge of - compiler-errors:rollup-emcj0o3, r=compiler-errors commit[3] 2023-01-09: Auto merge of - compiler-errors:better-spans-on-bad-tys, r=lcnr commit[4] 2023-01-09: Auto merge of - saethlin:propagate-operands, r=oli-obk commit[5] 2023-01-09: Auto merge of - aliemjay:astconv-normalize, r=lcnr commit[6] 2023-01-09: Auto merge of - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead ERROR: no CI builds available between and within last 167 days