jiebi/CodeConvo huggingface dataset:
Change:
// FIXME (#9639): This needs to handle non-utf8 paths let mut args = vec![input_file.to_str().unwrap().to_owned(), "-L".to_owned(), <del> self.config.build_base.to_str().unwrap().to_owned(), format!("--target={}", target)]; </del> <ins> self.config.build_base.to_str().unwrap().to_owned()]; // Optionally prevent default --target if specified in test compile-flags. let custom_target = self.props.compile_flags .iter() .fold(false, |acc, ref x| acc || x.starts_with("--target")); if !custom_target { args.extend(vec![ format!("--target={}", target), ]); } </ins> if let Some(revision) = self.revision { args.extend(vec![

Discussion:
Today when you compile for a target that does not exist rustc gives the standard message for failing to find a crate, for . We can and should be more explicit about what this means. Actually what is almost certainly happening is that you don't have that target installed: It could instead say: A reasonable heuristic for printing this might be if the crate is named or and the sysroot is not overridden.
When I run on I get the error:
I would like to try my hand at this if no one else has picked it up already. I am fairly new to rust, so I might need some assistance getting the pull request into a something resembling a reasonable state.
Change:
/// documentation for more. #[stable(feature = "rust1", since = "1.0.0")] pub struct IterMut<'a, T: 'a> { <del> // We do *not* exclusively own the entire list here, references to node's `element` // have been handed out by the iterator! So be careful when using this; the methods // called must be aware that there can be aliasing pointers to `element`. list: &'a mut LinkedList<T>, </del> head: Option<NonNull<Node<T>>>, tail: Option<NonNull<Node<T>>>, len: usize, <ins> marker: PhantomData<&'a mut Node<T>>, </ins> } #[stable(feature = "collection_debug", since = "1.17.0")] impl<T: fmt::Debug> fmt::Debug for IterMut<'_, T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { <del> f.debug_tuple("IterMut").field(&self.list).field(&self.len).finish() </del> <ins> f.debug_tuple("IterMut") .field(&*mem::ManuallyDrop::new(LinkedList { head: self.head, tail: self.tail, len: self.len, marker: PhantomData, })) .field(&self.len) .finish() </ins> } }

Discussion:
(playground) label T-libs-impl, A-collections <hrCaused by violation of safety invariant as documented in yet implementation does I’m not sure where the field is really used at all, so maybe it can be replaced by a marker , similar to ’s implementation.
Assigning according to the and removing I-prioritize. modify labels -I-prioritize +P-critical
Good catch! Iterator debug implementations seem to be woefully under-audited in terms of soundness problems (this is such issue).
maybe you can help me out with how to run miri while hacking (a question that came up for the PR fixing this: ). I have no trouble compiling or testing a modified with , or linking a toolchain for usage (so that or are working) so that I can play around with it in a crate, but I don’t know how to run on such a local crate depending-on/using a modified .
Miri uses xargo for sysroot compilation, so setting will tell Miri which standard library to use. (It must be set to the folder in a rustc checkout.) You can then use a standard Miri, no rustup toolchain linking is required.
Oh, also, if you want to run the alloc/core test suites in Miri, see
Change:
<ins> // Copyright 2014 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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Discussion:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

(Doesn't happen with .)
Paging
Here's a truly minimal test case:
cc me
Variation: This gives a different error message:
Fixed in Can be closed.
Change:
<ins> trait Foo { fn bar(); } impl Foo for () { fn bar(s: _) {} //~^ ERROR the placeholder `_` is not allowed within types on item signatures for functions } 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. --<!-- 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
Minimal:
label +S-bug-has-mcve
Change:
fn visit_expr_post(&mut self, e: &'a ast::Expr) { run_early_pass!(self, check_expr_post, e); <ins> // Explicitly check for lints associated with 'closure_id', since // it does not have a corresponding AST node if let ast::ExprKind::Closure(_, asyncness, ..) = e.kind { if let ast::Async::Yes { closure_id, .. } = asyncness { self.check_id(closure_id); } } </ins> } fn visit_generic_arg(&mut self, arg: &'a ast::GenericArg) {

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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.
Change:
// Attempt to search similar mutable associated items for suggestion. // In the future, attempt in all path but initially for RHS of for_loop fn suggest_similar_mut_method_for_for_loop(&self, err: &mut DiagnosticBuilder<'_>) { <del> let hir = self.infcx.tcx.hir(); let node = hir.item(self.mir_hir_id()); </del> use hir::{ <del> Expr, </del> <ins> BodyId, Expr, </ins> ExprKind::{Block, Call, DropTemps, Match, MethodCall}, <ins> HirId, ImplItem, ImplItemKind, Item, ItemKind, </ins> }; <del> if let hir::ItemKind::Fn(_, _, body_id) = node.kind { </del> <ins> fn maybe_body_id_of_fn(hir_map: &Map<'tcx>, id: HirId) -> Option<BodyId> { match hir_map.find(id) { Some(Node::Item(Item { kind: ItemKind::Fn(_, _, body_id), .. })) | Some(Node::ImplItem(ImplItem { kind: ImplItemKind::Fn(_, body_id), .. })) => { Some(*body_id) } _ => None, } } let hir_map = self.infcx.tcx.hir(); let mir_body_hir_id = self.mir_hir_id(); if let Some(fn_body_id) = maybe_body_id_of_fn(&hir_map, mir_body_hir_id) { </ins> if let Block( hir::Block { expr:

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. --: The internal compiler error does not occur in stable (): The fix for compilation is to use instead of and this also prevents the panic in the nightly version of rustc. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
It would be nice to reproduce this without the async-std dependency.
Slightly smaller:
I bisected far enough to find it regressed between the 9th and 10th, then ran out of disk space :facepalm:
Smaller example without
Here you go. The async part doesn't seem important and the issue still occurs with the versions of and and removed from dependencies: It could probably be reduced in size further but I'm not much of a Rust expert. I suspect anything which triggers that particular compiler error would do the trick.
searched nightlies: from nightly-2021-02-10 to nightly-2021-02-11 regressed nightly: nightly-2021-02-11 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Probably cc In particular looks suspect.
Are functions registered as items in the hir? edit: nvm just saw that someone posted a non-async example
Change:
// can't continue an expression after an ident token::Ident(name, is_raw) => token::ident_can_begin_expr(name, t.span, is_raw), token::Literal(..) | token::Pound => true, <del> token::Interpolated(ref nt) => match **nt { token::NtIdent(..) | token::NtExpr(..) | token::NtBlock(..) | token::NtPath(..) => true, _ => false, }, _ => false </del> <ins> _ => t.is_whole_expr(), </ins> }; let cannot_continue_expr = self.look_ahead(1, token_cannot_continue_expr); if cannot_continue_expr {

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
RegionsNoOverlap(..) => { write!(f, "lifetimes do not intersect") } <del> RegionsInsufficientlyPolymorphic(br, _) => { </del> <ins> RegionsInsufficientlyPolymorphic(br, _, _) => { </ins> write!(f, "expected bound lifetime parameter {},  found concrete lifetime", br) } <del> RegionsOverlyPolymorphic(br, _) => { </del> <ins> RegionsOverlyPolymorphic(br, _, _) => { </ins> write!(f, "expected concrete lifetime,  found bound lifetime parameter {}", br) }

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
Symbol::intern("try_trait") ].into()), ); <ins> let try_span = self.sess.source_map().end_point(e.span); let try_span = self.mark_span_with_reason( CompilerDesugaringKind::QuestionMark, try_span, Some(vec![ Symbol::intern("try_trait") ].into()), ); </ins> // `Try::into_result(<expr>)` let discr = {

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
version = "0.1.0" dependencies = [ "byteorder", <del> "cargo_metadata 0.8.0", </del> <ins> "cargo_metadata 0.9.0", </ins> "colored", "compiletest_rs", "directories", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.1", </ins> "getrandom", <del> "hex 0.3.2", </del> <ins> "hex 0.4.0", </ins> "log", "num-traits", "rand 0.7.0",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
| ty::Param(_) | ty::Placeholder(..) | ty::Infer(ty::IntVar(_) | ty::FloatVar(_)) <ins> | ty::Alias(ty::Inherent, _) </ins> | ty::Error(_) => return, ty::Infer(ty::TyVar(_) | ty::FreshTy(_) | ty::FreshIntTy(_) | ty::FreshFloatTy(_)) | ty::Bound(..) => bug!("unexpected self type for `{goal:?}`"), <del> ty::Alias(_, alias_ty) => alias_ty, </del> <ins> // Excluding IATs here as they don't have meaningful item bounds. ty::Alias(ty::Projection | ty::Opaque, alias_ty) => alias_ty, </ins> }; for assumption in self.tcx().item_bounds(alias_ty.def_id).subst(self.tcx(), alias_ty.substs)

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 --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
<ins> // Copyright 2013 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. fn main() { let (x, y) = (); //~ ERROR expected `()` but found tuple (types differ) return x; } </ins>  No newline at end of file

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
/// randomization to avoid degenerate cases, but with a fixed seed to always provide /// deterministic behavior. /// <del> /// It is typically faster than stable sorting, except in a few special cases, e.g. when the /// slice consists of several concatenated sorted sequences. </del> <ins> /// Due to its key calling strategy, [`sort_unstable_by_key`](#method.sort_unstable_by_key) /// is likely to be slower than [`sort_by_cached_key`](#method.sort_by_cached_key) in /// cases where the key function is expensive. </ins> /// /// # Examples ///

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
<ins> error: invalid format string: expected `'}'` but string was terminated --> $DIR/issue-91556.rs:2:19 | LL |   let _ = format!(concat!("{0}𝖳𝖾𝗌𝗍{"), i); |                   ^^^^^^^^^^^^^^^^^^^ expected `'}'` in format string | = note: if you intended to print `{`, you can escape it using `{{` = note: this error originates in the macro `concat` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>

Discussion:
Reproducer: Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd love to take a look at this. Seems to be ICEing in code that displays the diagnostic to fixup the actual compiler error here. claim
Change:
| ^^^^^^^^^^^^^^^^^^^^^^ error: arguments to `macro_use` are not allowed here <del> --> $DIR/issue-43106-gating-of-macro_use.rs:12:17 </del> <ins> --> $DIR/issue-43106-gating-of-macro_use.rs:6:1 </ins> | <del> LL |     mod inner { #![macro_use(my_macro)] } |                 ^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL | #![macro_use(my_macro)] | ^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: malformed `macro_use` attribute input --> $DIR/issue-43106-gating-of-macro_use.rs:15:5

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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
I can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
//[noopt]compile-flags: -C opt-level=0 //[opt]compile-flags: -O //[opt_with_overflow_checks]compile-flags: -C overflow-checks=on -O <del> // build-fail </del> <ins> // build-pass </ins> #![crate_type="lib"] <del> #![deny(arithmetic_overflow, const_err)] </del> <ins> #![warn(arithmetic_overflow, const_err)] </ins> #![allow(unused_variables)] #![allow(dead_code)]

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
| LL | fn take_foo(_: impl Foo) {} |                     ^^^ <ins> help: consider specifying the type of the closure parameters | LL |     take_foo(|a: &_| a); |              ~~~~~~~ </ins> error[E0308]: mismatched types --> $DIR/issue-79187-2.rs:11:5

Discussion:
a new project with (in my case, it used pathfinding version 4.0.0 or 4.0.1) with: produces the following output: For the two closures ( and ), if I add a type for the parameter by changing to , it builds without any errors. If it had told me that it needed type annotations, I would have understood the problem and been able to fix it right away. (I assumed that there was enough type information for it to infer the correct types.) The first confusing bit is that both errors highlight the entire call to , including all parameters. This makes it harder to figure out which one it is complaining about (though the second note contains the line number). Does the first argument have something to do with the lifetimes it is complaining about? I found this part of the message hard to understand: The type parameters look almost identical, and the didn't make sense to me. Could it somehow indicate the bounds of that lifetime (2), or better explain why that lifetime doesn't last long enough? FYI: found as part of solving Advent of Code 2022, Day 12. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
A smaller MCVE:
I'm thinking whether we should fix this as a compiler bug (i.e., make it compile) or suggesting people write explicit type here
maybe related:
Also if we move the closure to the parameter: This will also compile. Combined with , I guess something is wrong with propagating lifetime of closures when we store it in a variable...
claim