jiebi/CodeConvo huggingface dataset:
Change:
fn install(src: &Path, dstdir: &Path, perms: u32) { let dst = dstdir.join(src.file_name().unwrap()); t!(fs::create_dir_all(dstdir)); <ins> drop(fs::remove_file(&dst)); </ins> { let mut s = t!(fs::File::open(&src)); let mut d = t!(fs::File::create(&dst));

Discussion:
Cargo doc runs on nightly-2017-09-11 without displaying any errors or warnings, yet, it doesn't produce any outputs. I am on nightly-unknown-linux-gnu on Linux Mint. I tried with different nightly toolchains to see if it was a problem of my code, or if it was a problem of the toolchain. [OK] nightly-2017-09-08-x8664-unknown-linux-gnu [OK] nightly-2017-09-09-x8664-unknown-linux-gnu [OK] nightly-2017-09-10-x8664-unknown-linux-gnu [Broken] nightly-2017-09-11-x8664-unknown-linux-gnu I also tried on different machines and the result is the same. I tried: but I cannot find any pointer to the problem. Example output when running cargo doc --open The browser window doesn't open, the target/doc folder is empty and the usual xdg-open command is missing. Does anybody else have the same problem?
Looks like this is because as distributed is an empty file... investigating
Likely caused by
On Appveyor I was getting a much more frustrating error: Upon updating to the latest nightly locally I got a more helpful error: And as it turns out, is empty here as well: 
Oh that's why my builds were failing attempting to commit an empty folder full of 'docs'...
Thank you guys! That fixed it :)
Change:
let src = self.evaluated[value].as_ref()?; let src = self.ecx.read_immediate(src).ok()?; let to = self.ecx.layout_of(to).ok()?; <del> let ret = self.ecx.ptr_to_ptr(&src, to).ok()?; ret.into() </del> <ins> ImmTy::from_immediate(*src, to).into() </ins> } _ => return None, },

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=5 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: ()'', 'thread 'rustc' panicked at 'assertion failed: ()'' 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: [optimizedmir] optimizing MIR for [collectandpartitionmonoitems] collectandpartitionmono_items --
cc
Change:
return ControlFlow::Continue(()); } <del> let kind = match kind { ty::Inherent | ty::Projection => "associated type", ty::Weak => "type alias", ty::Opaque => unreachable!(), }; </del> self.def_id_visitor.visit_def_id( data.def_id, <del> kind, </del> <ins> match kind { ty::Inherent | ty::Projection => "associated type", ty::Weak => "type alias", ty::Opaque => unreachable!(), }, </ins> &LazyDefPathStr { def_id: data.def_id, tcx }, )?; // This will also visit args if necessary, so we don't need to recurse. return if V::SHALLOW { ControlFlow::Continue(()) <ins> } else if kind == ty::Projection { self.visit_projection_ty(data) </ins> } else { data.args.iter().try_for_each(|subst| subst.visit_with(self)) };

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:
<ins> struct Bug { A: [(); { *"" }.len()], //~^ ERROR: cannot move a value of type str //~| ERROR: cannot move out of a shared reference } fn main() {} </ins>

Discussion:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsPossibly related to , except with a different ICE message.
The bug here should be delayed:
triage: P-medium, removing I-nominated label.
Change:
## Macros ```antlr <del> expr_macro_rules : "macro_rules" '!' ident '(' macro_rule * ')' ; </del> <ins> expr_macro_rules : "macro_rules" '!' ident '(' macro_rule * ')' ';' | "macro_rules" '!' ident '{' macro_rule * '}' ; </ins> macro_rule : '(' matcher * ')' "=>" '(' transcriber * ')' ';' ; matcher : '(' matcher * ')' | '[' matcher * ']' | '{' matcher * '}' | '$' ident ':' ident

Discussion:
The grammar of given in the is outdated: the mandatory semicolon at the end of the first rule is missing, and an alternative notation using the curly brackets is missing as well. Regards, Ivan
Change:
Hello in Japanese: こんにちは Goodbye in Japanese: さようなら ``` <ins> ## Complex imports Rust offers several advanced options that can add compactness and convenience to your `extern crate` and `use` statements. Here is an example: ```rust,ignore extern crate phrases as sayings; use sayings::japanese::greetings as ja_greetings; use sayings::japanese::farewells::*; use sayings::english::{self, greetings as en_greetings, farewells as en_farewells}; fn main() { println!("Hello in English; {}", en_greetings::hello()); println!("And in Japanese: {}", ja_greetings::hello()); println!("Goodbye in English: {}", english::farewells::goodbye()); println!("Again: {}", en_farewells::goodbye()); println!("And in Japanese: {}", goodbye()); } ``` What's going on here? First, both `extern crate` and `use` allow renaming the thing that is being imported. So the crate is still called "phrases", but here we will refer to it as "sayings". Similarly, the first `use` statement pulls in the `japanese::farewells` module from the crate, but makes it available as `jp_farewells` as opposed to simply `farewells`. This can help to avoid ambiguity when importing similarly-named items from different places. The second `use` statement uses a star glob to bring in _all_ symbols from the `sayings::japanese::farewells` module. As you can see we can later refer to the Japanese `goodbye` function with no module qualifiers. This kind of glob should be used sparingly. The third `use` statement bears more explanation. It's using "brace expansion" globbing to compress three `use` statements into one (this sort of syntax may be familiar if you've written Linux shell scripts before). The uncompressed form of this statement would be: ```rust,ignore use sayings::english; use sayings::english::greetings as en_greetings; use sayings::english::farewells as en_farewells; ``` As you can see, the curly brackets compress `use` statements for several items under the same path, and in this context `self` just refers back to that path. Note: The curly brackets cannot be nested or mixed with star globbing. </ins>

Discussion:
/u/DroidLogician on reddit that the syntax is undocumeted, at least in the crates and module chapter of TRPL. this seems like your territory :)
Also the syntax.
As mentioned later in that reddit thread, is now without quotes. hasn't worked since the addition of turning into in crate names.
I think this can be closed.
Change:
if object_safety_violations { return; } <ins> // related to issue #91997, turbofishes added only when in an expr or pat let mut in_expr_or_pat = false; </ins> if let ([], [bound]) = (&potential_assoc_types[..], &trait_bounds) { <ins> let grandparent = tcx.parent_hir_node(tcx.parent_hir_id(bound.trait_ref.hir_ref_id)); in_expr_or_pat = match grandparent { Node::Expr(_) | Node::Pat(_) => true, _ => false, }; </ins> match bound.trait_ref.path.segments { // FIXME: `trait_ref.path.span` can point to a full path with multiple // segments, even though `trait_ref.path.segments` is of length `1`. Work

Discussion:
Given the following code: %20%7B%0A%20%20%20%20let%20%20%3D%20MyIterator%3A%3Anext%3B%0A%20%20%20%20%2F%2Flet%20%20%3D%20MyIterator%3CItem%3D()%3E%3A%3Anext%3B%0A%7D) The current output is: But when when I write , it gets interpreted as comparison expressions like and it fails to compile with a lot of "cannot find value in this scope" and "cannot find crate in the list of imported crates". The suggestion is confusing because it is unclear how to apply it. The error goes away if you use directly: produces the error one would expect: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it gets evaluated as an expression because you are missing a . If you add them, then you get a new error message ():
I see, let me rephrase the issue: The suggestion is "help: specify the associated type: " where "help: specify the associated type: " with a double colon would be correct.
Triage: Suggestion is correct for code using (which all code written in Rust =2021 uses). For code written without in Rust <2021: No change. As mentioned, the suggestion should use an expression-style path (i.e., one with turbofishes).
claim
Working on tests before creating a PR. Multiple tests exist already that have an odd hardcoded expectation for error output, so I'll be double checking those make sense with these changes, and adding a few tests of my own. Otherwise, this really does seem like it was a simple two character fix, unless I missed something somewhere.
Yeah, it's a pretty easy one. Adding before is always correct — not only in expression contexts but also in type contexts since turbofish is also possible in type positions (e.g., ) — albeit redundant. Omitting before in type contexts would be a possible "optimization". However, it really isn't worth doing here.

Consider the following code which is ill-formed even after specifying the assoc ty. () would only be well-formed if we defined an inherent associated type () on which doesn't work yet anyway () and is pretty niche) or once we support arbitrary shorthand projections ().
Change:
} pub fn test_opts(config: &Config) -> test::TestOpts { <ins> if env::var("RUST_TEST_NOCAPTURE").is_ok() { eprintln!( "WARNING: RUST_TEST_NOCAPTURE is no longer used.  Use the `--nocapture` flag instead." ); } </ins> test::TestOpts { exclude_should_panic: false, filters: config.filters.clone(),

Discussion:
passes fails On recent master (commit ), with to avoid building LLVM: Extra spin/Side note: Contrary to the above, with , both and pass well: and . All the same when invoking with instead of . Also discussed at https://rust- <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think is not actually passing through to libtest, it's just acting as a filter on the tests (like would). looks like today the only way to configure this is through an env variable: changing that to accept seems useful
claim
Wow. Thank you.
Change:
// cdb-check:    [+0x000] pointer          : 0x[...] [Type: unsized::Foo<dyn$<core::fmt::Debug> > *] // cdb-check:    [...] vtable           : 0x[...] [Type: unsigned [...]int[...] (*)[3]] <ins> // cdb-command:dx tuple_slice // cdb-check:tuple_slice      [Type: ref$<tuple$<i32,i32,slice$<i32> > >] // cdb-check:    [+0x000] data_ptr         : 0x[...] [Type: tuple$<i32,i32,slice$<i32> > *] // cdb-check:    [...] length           : 0x2 [Type: unsigned [...]int[...] // cdb-command:dx tuple_dyn // cdb-check:tuple_dyn        [Type: ref$<tuple$<i32,i32,dyn$<core::fmt::Debug> > >] // cdb-check:    [+0x000] pointer          : 0x[...] [Type: tuple$<i32,i32,dyn$<core::fmt::Debug> > *] // cdb-check:    [...] vtable           : 0x[...] [Type: unsigned [...]int[...] (*)[3]] #![feature(unsized_tuple_coercion)] </ins> #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section]

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. --code from <!-- 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
cc It looks like this might be related to
reports that this is regression in (which is indeed in PR ).
reports in zulip that this test case fails at that same injection point when combined with (aka ): ./src/test/run-pass-valgrind/dst-dtor-4.rs : <details<summaryContent of above file</summary</details
Files that reproduce the ice one way or another with : `
Thanks for the bug report, I'll look into it.
Looks like this should be an easy fix. The code just doesn't expect tuples to be unsized (which of course it should).
Change:
) -> Vec<OutlivesBound<'tcx>> { let ty = self.resolve_vars_if_possible(ty); let ty = OpportunisticRegionResolver::new(self).fold_ty(ty); <del> assert!(!ty.needs_infer()); </del> <ins> // We do not expect existential variables in implied bounds. // We may however encounter unconstrained lifetime variables in invalid // code. See #110161 for context. assert!(!ty.has_non_region_infer()); if ty.needs_infer() { self.tcx.sess.delay_span_bug( self.tcx.def_span(body_id), "skipped implied_outlives_bounds due to unconstrained lifetimes", ); return vec![]; } </ins> let span = self.tcx.def_span(body_id); let result = param_env

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. --<!-- 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 --
See also , but while only reproduces with rustdoc, this one only repros with rustc and not rustdoc :thinking:
searched nightlies: from nightly-2023-01-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim I'll have a go at this, no idea if I'll be able to do it.
This is an ICE on invalid code. label regression-from-stable-to-nightly Minimized: this can be fixed by replacing the assertion with and returning early to avoid processing unconstrained lifetime variables in implied bounds. It would be nice if we have a comment referring to this issue or to the ui test for why delaying a bug was necessary.
btw, you should update your cargo-bisect-rustc to make it bisect the contents of rollups as well.
It is, unfortunately the regression is old enough that perf artifacts are gone :(
It's not old, but I remember now, this was my cursed rollup that didn't get unrolled perf builds. It also was a perf regression which made it pretty annoying :D
Change:
tcx: TyCtxt<'tcx>, substs: SubstsRef<'tcx>, ) -> SubstsRef<'tcx> { <del> tcx.mk_substs(substs.iter().enumerate().map(|(idx, arg)| { match arg.unpack() { GenericArgKind::Type(_) if arg.has_non_region_param() || arg.has_non_region_infer() => { tcx.mk_ty(ty::Placeholder(ty::PlaceholderType { </del> <ins> struct ReplaceParamAndInferWithPlaceholder<'tcx> { tcx: TyCtxt<'tcx>, idx: usize, } impl<'tcx> TypeFolder<'tcx> for ReplaceParamAndInferWithPlaceholder<'tcx> { fn tcx(&self) -> TyCtxt<'tcx> { self.tcx } fn fold_ty(&mut self, t: Ty<'tcx>) -> Ty<'tcx> { if let ty::Infer(_) = t.kind() { self.tcx.mk_ty(ty::Placeholder(ty::PlaceholderType { </ins> universe: ty::UniverseIndex::ROOT, <del> name: ty::BoundVar::from_usize(idx), </del> <ins> name: ty::BoundVar::from_usize({ let idx = self.idx; self.idx += 1; idx }), </ins> })) <del> .into() </del> <ins> } else { t.super_fold_with(self) </ins> } <del> GenericArgKind::Const(ct) if ct.has_non_region_infer() || ct.has_non_region_param() => { let ty = ct.ty(); // If the type references param or infer, replace that too... </del> <ins> } fn fold_const(&mut self, c: ty::Const<'tcx>) -> ty::Const<'tcx> { if let ty::ConstKind::Infer(_) = c.kind() { let ty = c.ty(); // If the type references param or infer then ICE ICE ICE </ins> if ty.has_non_region_param() || ty.has_non_region_infer() { <del> bug!("const `{ct}`'s type should not reference params or types"); </del> <ins> bug!("const `{c}`'s type should not reference params or types"); </ins> } <del> tcx.mk_const( </del> <ins> self.tcx.mk_const( </ins> ty::PlaceholderConst { universe: ty::UniverseIndex::ROOT, <del> name: ty::BoundVar::from_usize(idx), </del> <ins> name: ty::BoundVar::from_usize({ let idx = self.idx; self.idx += 1; idx }), </ins> }, ty, ) <del> .into() </del> <ins> } else { c.super_fold_with(self) </ins> } <del> _ => arg, </del> } <del> })) </del> <ins> } substs.fold_with(&mut ReplaceParamAndInferWithPlaceholder { tcx, idx: 0 }) </ins> }

Discussion:
Continuation of . I minimized this together with thank you for your help and originally finding the issue! <!-- 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 first and most relevant delayed bug: All the delayed bugs and the usual backtrace: <details<summary<strongBacktrace</strong</summary<p</p</details
Regressed the the PR: searched nightlies: from nightly-2021-01-01 to nightly-2022-12-12 regressed nightly: nightly-2022-11-27 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
Change:
// run-pass #![feature(let_else)] <ins> use std::fmt::Display; use std::rc::Rc; </ins> use std::sync::atomic::{AtomicU8, Ordering}; static TRACKER: AtomicU8 = AtomicU8::new(0);

Discussion:
results in I am not sure if this issue exists only in combination with impl Trait of if it can be triggered in some other ways as well, haven't managed to get this bug some other way. cc do you know whether this behavior is known already?
The bug is not known to me. cc who has improved the borrow checking behavior. The suggestion is also weird.
The let-else actually desugars to this if-let: And you . However the suggestion actually makes sense for if-let, because putting a semicolon afterwards does indeed fix it. The suggestion is wrong for the let-else because let-else's desugaring is always in tail position in its enclosing block, any statements thereafter get moved into the if-branch and so no amount of semicolons can take the desugaring out of tail position.
Also note that the old desugaring, which was , does not suffer this particular problem because the temporary has a name and lives outside the tail position expression. That way there is no ordering problem with the ends of x's and the unnamed temporary's lifetimes. So a few things: a named temporary like that is a good suggestion to make instead for let-else, and potentially for if-let as well. presence or absence of a semicolon on a tail position expression of type () having that much significance is pretty bad. Arguably it should not be significant whatsoever. is being a bit obtuse. It isn't explained very well even for the if-let version why the unnamed temporary is still alive when x is being dropped. Conceptually I think borrowck is trying to say that the real implicit return expression is actually that empty space inside the braces of type (). I don't know. if it did explain better, is there a technical reason why borrowck can't figure out that it could simply drop the unnamed temporary first? Because that would be ideal.
Could we just wrap the in the let-else desugaring with a ?
Well isn't that convenient! Yeah, I suppose we could.
I've just tried this, and it also suffers the same thing did, with the unreachable code warnings when the desugaring ends up with a return in both branches. It is probably complaining about the DropTemps expression itself being unreachable.

We can't slap an on it lest it ignore all unreachable code inside, but I think we can disable the emission of such warnings on any DropTemps in typeck's . Right? (Edit, maybe instead in , because this DropTemps will rarely if ever be such that typeck could warn about it.) Example warning:
Ah cool, turned out to be pretty easy.
This compiles successfully as of , which includes . So I'd say it's fixed, but it needs a test before the issue can be closed. includes a test for this, but it's not merged and probably not going to be. The other test in that PR also looks interesting.
Change:
} }; <del> // If the loop context is not a `loop { }`, then break with // a value is illegal, and `opt_coerce_to` will be `None`. // Just set expectation to error in that case. let coerce_to = opt_coerce_to.unwrap_or_else(|| Ty::new_misc_error(tcx)); </del> <ins> let coerce_to = match opt_coerce_to { Some(c) => c, None => { // If the loop context is not a `loop { }`, then break with // a value is illegal, and `opt_coerce_to` will be `None`. // Return error in that case (#114529). return Ty::new_misc_error(tcx); } }; </ins> // Recurse without `enclosing_breakables` borrowed. e_ty = self.check_expr_with_hint(e, coerce_to);

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. --<!-- 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 --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can't reproduce this on the latest nightly. Can you confirm that this doesn't reproduce anymore?
This may only be triggerable with a rustc that was built with debug assertions on
Yes, hence the label :sweat_smile:
No longer needs debug assertions to crash :tada:
`
Edit: Ignore it. Wrong bisection. For some reason it was bisecting to 2023-10-04 on my machine despite the fact that the issue was reported much earlier than this date.
The issue occurs because the interpreter tries to assign the value from to a temporary MIR local of type which produces a type mismatch and results in the ICE. Such faulty MIR should not have been generated. However, the while loop, although detected as malformed during AST lowering, successfully typecks. Had it not and had been set to , the MIR would not have been generated. Therefore as far as I understand the solution is to fail typeck and set to for code like this. claim
Change:
<ins> fn main() { let a: u16; let b: u16 = 42; let c: usize = 5; a = c + b * 5; //~ ERROR: mismatched types [E0308] //~| ERROR: mismatched types [E0308] //~| ERROR: cannot add `u16` to `usize` [E0277] } </ins>

Discussion:
I try this code: () I expect to see this happen: No invalid suggestion for . Instead, I got this errors: label D-invalid-suggestion T-compiler