jiebi/CodeConvo huggingface dataset:
Change:
<ins> - // MIR for `caller` before Inline + // MIR for `caller` after Inline fn caller(_1: Box<[i32]>) -> () { debug x => _1;                       // in scope 0 at $DIR/unsized_argument.rs:+0:11: +0:12 let mut _0: ();                      // return place in scope 0 at $DIR/unsized_argument.rs:+0:26: +0:26 let _2: ();                          // in scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 let mut _3: std::boxed::Box<[i32]>;  // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 let mut _4: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _5: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _6: ();                      // in scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 let mut _7: *const [i32];            // in scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 bb0: { StorageLive(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 StorageLive(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _3 = move _1;                    // scope 0 at $DIR/unsized_argument.rs:+1:13: +1:14 _7 = (((_3.0: std::ptr::Unique<[i32]>).0: std::ptr::NonNull<[i32]>).0: *const [i32]); // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 _2 = callee(move (*_7)) -> [return: bb3, unwind: bb4]; // scope 0 at $DIR/unsized_argument.rs:+1:5: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:5: 9:11 // + literal: Const { ty: fn([i32]) {callee}, val: Value(<ZST>) } } bb1: { StorageDead(_3);                 // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 StorageDead(_2);                 // scope 0 at $DIR/unsized_argument.rs:+1:15: +1:16 _0 = const ();                   // scope 0 at $DIR/unsized_argument.rs:+0:26: +2:2 return;                          // scope 0 at $DIR/unsized_argument.rs:+2:2: +2:2 } bb2 (cleanup): { resume;                          // scope 0 at $DIR/unsized_argument.rs:+0:1: +2:2 } bb3: { _4 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> bb1; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } bb4 (cleanup): { _6 = alloc::alloc::box_free::<[i32], std::alloc::Global>(move (_3.0: std::ptr::Unique<[i32]>), move (_3.1: std::alloc::Global)) -> [return: bb2, unwind terminate]; // scope 0 at $DIR/unsized_argument.rs:+1:14: +1:15 // mir::Constant // + span: $DIR/unsized_argument.rs:9:14: 9:15 // + literal: Const { ty: unsafe fn(Unique<[i32]>, std::alloc::Global) {alloc::alloc::box_free::<[i32], std::alloc::Global>}, val: Value(<ZST>) } } } </ins>

Discussion:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .
Change:
<ins> // Don't panic when iterating through the `hir::Map::parent_iter` of an RPITIT. pub trait Foo { fn demo() -> impl Foo //~^ ERROR the trait bound `String: Copy` is not satisfied where String: Copy; //~^ ERROR the trait bound `String: Copy` is not satisfied } fn main() {} </ins>

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. --(reduced) (original) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongCode</strong</summary<p</p</details<!-- 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- The in closed issue is same as the .
Regression in The PR introducing the regression in this rollup is : Provide structured suggestion for searched nightlies: from nightly-2024-03-16 to nightly-2024-03-23 regressed nightly: nightly-2024-03-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This was caused by the introduction of which has no parent. This seems like a gun aimed squarely at the foot of any user of or . I believe we need to audit all existing uses of these (if you haven't done that already).
Change:
<ins> // check-pass #![feature(const_trait_impl, effects)] #[const_trait] trait Foo { fn foo(&self) {} } struct Bar<T>(T); impl<T> Bar<T> { const fn foo(&self) where T: ~const Foo { self.0.foo() } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no host param id for call in const yet no errors reported', 'error: internal compiler error: no host param id for call in const yet no errors reported' 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<!-- query stack: --
Regression in nightly-2023-08-09
Change:
{ let def_kind_descr = tcx.def_kind_descr(item.kind.as_def_kind(), item.def_id); let item_name = item.ident(tcx); <del> let rcvr_ref = tcx.fn_sig(item.def_id).skip_binder().skip_binder().inputs()[0] .ref_mutability() </del> <ins> let rcvr_ref = tcx.fn_sig(item.def_id) .skip_binder() .skip_binder() .inputs() .get(0) .and_then(|ty| ty.ref_mutability()) </ins> .map_or("", |mutbl| mutbl.ref_prefix_str()); let args = format!( "({}{})",

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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
/ ping
Change:
<ins> // check-pass fn main() { let _a = ..; let _b = ..=10; let _c = &..; let _d = &..=10; } </ins>

Discussion:
<!-- 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: <!-- Please provide a link to --The current output is: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim
Change:
var div = document.createElement("div"); div.className = "block " + shortty; var h3 = document.createElement("h3"); <del> h3.textContent = longty; </del> <ins> h3.innerHTML = `<a href="index.html#${id}">${longty}</a>`; </ins> div.appendChild(h3); var ul = document.createElement("ul");

Discussion:
In rustdoc sidebars, most headings are clickable links. For instance, "Required Methods" and "Implementors" in the sidebar of However, the headings under "Other items in..." are not clickable. We should link those to the appropriate subheading on the module page. That allows the user to see a more verbose listing of items in the module, since each one has a description alongside it. <img width=150 src="https://user-"<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So, for instance, sidebar heading should lead ?
claim
Yes, that's correct.
By the way be aware this will conflict with Resolving the conflict should be pretty easy though.
Thanks
any progress on this? I'd like to get it landed before the beta cut, so we have a consistent UI where headings in the sidebar are clickable.
sorry, i couldn't make time last ,i will unassign me, thanks.
Change:
let url = format!("rustc-builds/{commit}"); let tarball = rustc_cache.join(&filename); if !tarball.exists() { <del> builder.download_component(base, &format!("{url}/{filename}"), &tarball); </del> <ins> builder.download_component(base, &format!("{url}/{filename}"), &tarball, ""); </ins> } let bin_root = builder.out.join(builder.config.build.triple).join("ci-rustc"); builder.unpack(&tarball, &bin_root, prefix)

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
pub fn f3(arg: <Priv as PrivTr>::Assoc) {} //~^ WARNING type `aliases_pub::Priv` is more private than the item `aliases_pub::f3` //~| WARNING associated type `aliases_pub::PrivTr::Assoc` is more private than the item `aliases_pub::f3` <ins> //~^^^ WARNING trait `aliases_pub::PrivTr` is more private than the item `aliases_pub::f3` </ins> impl PrivUseAlias { pub fn f(arg: Priv) {}

Discussion:
This is a pretty common use case, so this bug has probably already been registered, but I couldn't find anything while searching around, so I'm reporting this here just in case. I ran this code: When running this code, I expect to simply get a not yet implemented error on the function. Instead, I get this: : returns an , and is not a trait method–it's just a regular method. Therefore, AFAIK, this should compile. Notably, making either or as makes it compile fine.
Regression in . cc
oli's on leave so cc-ing PR 's reviewer
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
sess.time("load_extern_crates", || { for extern_name in &extern_names { debug!("loading extern crate {}", extern_name); <del> resolver </del> <ins> if let Err(()) = resolver </ins> .resolve_str_path_error( DUMMY_SP, extern_name, TypeNS, LocalDefId { local_def_index: CRATE_DEF_INDEX }.to_def_id(), <del> ) .unwrap_or_else(|()| { panic!("Unable to resolve external crate {}", extern_name) }); </del> <ins> ) { warn!("unable to resolve external crate {} (do you have an unused `--extern` crate?)", extern_name) } </ins> } }); });

Discussion:
I'm running via on a small project with multiple crates via the workspaces feature, and I get the following error (I've sanitized the paths, project name and dependencies): ~ It always fails with random external dependencies or crates that are part of the workspace. It does succeed however for a crate without any dependencies. I've tried with Rust 1.43.0 and 1.43.1, on openSUSE Tumbleweed Linux, both from the distributions repository () and (). I've also tried with latest nightly with the same outcome. : ~ <details<summaryBacktrace</summary<p~ </p</details
I've tried to create a minimal example that would trigger the issue but failed to do so... Perhaps one of my dependencies generates the issue? (However in my workspace I also have one crate that depends only on another internal one (which itself has no further dependencies) and it still fails.) I'm willing to experiment if someone gives me some pointers!
OK, I've found the issue: create two libraries and , with nothing more than an edition 2018 and an empty as their code; make them part of the same workspace; make depend on ; add a in (the library that depends on ); At the following link there is a simple project that rebuilds all of the above: succeeds, meanwhile fails with the aforementioned error. It appears that by just adding (after the no implicit import prelude) is enough to make the documentation build. A second solution would be to add after the no import prelude annotation.
Possibly related to
Regression in nightly-2019-11-15 Most likely caused by <details<summaryFull bisection </summary</detailsThis also means you can't document librustdoc. <details<summaryBacktrace </summary</details
the cause is already known: But I don't know why you say librustdoc can't be documented, it's right here on the site: Make sure you're passing , it's stage 0 by default.
oh look, I knew I'd seen this bug before, apparently I just forgot. The fix for this is to turn the into a .
Change:
<ins> // run-rustfix struct S { field_name: (), } fn main() { match (S {field_name: ()}) { S {field_name: ref _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {field_name: mut _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {field_name: ref mut _foo} => {} //~ ERROR expected `,` } // Verify that we recover enough to run typeck. let _: usize = 3usize; //~ ERROR mismatched types } </ins>

Discussion:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:
Change:
<ins> error[E0658]: const generics are unstable --> $DIR/issue-60263.rs:1:16 | LL | struct B<const I: u8>; |                ^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44580 = help: add #![feature(const_generics)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </ins>

Discussion:
The following ICE's on nightly only: Notice I didn't specify the feature <details<summaryBacktrace:</summary</details
In general, presence or absence of shouldn't affect compiler's behavior in any way beside reporting the "feature is unstable" error, so ICEs like this need to fixed unconditionally.
Strongly related (not sure why two issues though) with and therefore with and I already pinged you in because of this ;)
2 issue's because the ICE messages are different, sorry for the confusion! To clearify, on both issue's there are 2 things wrong: Being able to get the ICE's, without specifying the feature The ICE's themselves (Which was likely to happen, given the incompleteness. Consider these as test-cases, or something :) )
This should be fixed on the next nightly, but will add a regression test for it.
Change:
} } hir::InlineAsmOperand::InOut { expr, .. } => { <del> succ = self.write_place(expr, succ, ACC_READ | ACC_WRITE); </del> <ins> succ = self.write_place(expr, succ, ACC_READ | ACC_WRITE | ACC_USE); </ins> } hir::InlineAsmOperand::SplitInOut { out_expr, .. } => { if let Some(expr) = out_expr {

Discussion:
<!-- 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: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim
Change:
sp_lo: sp.lo }); } <del> MatchNonterminal(_,_,_) => { bb_eis.push(ei) } </del> <ins> MatchNonterminal(_,_,_) => { // Built-in nonterminals never start with these tokens, // so we can eliminate them from consideration. match tok { token::RPAREN | token::RBRACE | token::RBRACKET => {}, _ => bb_eis.push(ei) } } </ins> MatchTok(ref t) => { let mut ei_t = ei.clone(); if token_name_eq(t,&tok) {

Discussion:
The following macro won't work without the extra set of parens: Here's an example use: I'd like to remove those extra parens. It seems like [ field:ident),* ] should be unambiguous, but rustc doesn't like it. The actual error is . Also, it seems like it should tell me the other options so I have some clue what is going wrong.
Nominating for milestone 1, well-defined (part of figuring out what macros actually parse)
Related to which has to do with the implementation of parsing being able to stop / reset / restart. But I want to have some bug on file for well-definedness that says which grammar-class of macros we support. The current macro tutorial at has a little discussion of it, but is not entirely clear. I believe the class is "1-token predictive grammars" which is the non-backtracking subset of LL(1), quite limited. It's fine if that's our limitation -- it's still much more than in other languages -- but we ought to say so. (We discussed this in the nomination meeting today when we hit and decided to accept "some bug" for the well-definedness of the macro parser, and leave on the problem of its implementation)
Triage: still an issue. Specifically, the following fails FWIW, the example in the issue is one of many working versions, e.g. also works (called like: ).
Change:
.collect(); test_args.append(&mut builder.config.cmd.test_args()); <ins> test_args.extend(builder.config.free_args.iter().map(|s| s.as_str())); </ins> // On Windows, replace forward slashes in test-args by backslashes // so the correct filters are passed to libtest

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
} } <ins> unsafe impl Send for Event {} unsafe impl Sync for Event {} </ins> struct Inner { handle: libc::HANDLE, lock: Mutex<()>,

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
let trait_bounds: Vec<_> = self.verify_bound.projection_declared_bounds_from_trait(projection_ty).collect(); <ins> debug!(?trait_bounds); </ins> // Compute the bounds we can derive from the environment. This // is an "approximate" match -- in some cases, these bounds // may not apply.

Discussion:
<!-- 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. --Within an , a GAT bound of does not compile, asking me to add an explicit bound. This code results in two errors: I believe that the error is a bug, as since is known in this to be , must outlive and the suggested bound should thus already be implied by . Applying the suggested fix removes this error, but obviously cannot compile (as the GAT impl now has a stricter than in the declaration). The first error seems incorrect too, as there is no visible difference between the highlighted lines other than : Adding the type bound on the declaration avoids these errors, but is less generic. <!-- 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 have also encountered this bug on . </details
label +F-genericassociatedtypes +T-compiler
It's both rude and unconstructive to suggest that issues are not tracked. First and foremost, this is an unstable feature. Second, this issue was filed 15 days ago, right in the middle of holidays. Third, its labeled appropriately, and I'll either triage or fix it when I can. I'm going to delete the above comment since it's not constructive at all.
I forgot what I said before, but if I said something bad, I'm really sorry for that