jiebi/CodeConvo huggingface dataset:
Change:
let is_fn_like = tcx.def_kind(def).is_fn_like(); if is_fn_like { // Do not compute the mir call graph without said call graph actually being used. <del> if inline::Inline.is_enabled(&tcx.sess) { </del> <ins> if pm::should_run_pass(tcx, &inline::Inline) { </ins> tcx.ensure_with_value().mir_inliner_callees(ty::InstanceDef::Item(def.to_def_id())); } }

Discussion:
While trying to build a test for , I renamed my test file and it stopped ICEing. I have no idea what's happening here. Create a file with this contents called Then This compiles fine: But this ICEs:
We skip calling by comparing def-path hashes. The def-path hash provides a total order on MIR bodies that respects incremental compilation, and avoids a potentially costly query. OTOH, it depends on the crate name, which is the file name in your example. If you add a somewhere, that should be reproducible.
Setting the crate name would stabilize this for now, but any change to the hash algorithm could cause this test to suddenly pass, even if the compiler regresses in its behavior. Is there a way around that problem?
As someone who has changed the hash algorithm before, a comment in the file that says you might have to fiddle with the crate name to find something where that check works (including a link to this issue) might be enough if there's no other option.
I'm not concerned about the test suddenly failing, I'm concerned about it suddenly passing when it shouldn't.
I can't reproduce the MCVE in your opening comment. However, if I rename the file to then it emits an ICE (which I suspect is the same you reported here, is it? <details</detailsTo summarize: :heavycheckmark: :heavycheckmark: :skull: I'm really puzzled. Any idea? :thinking: EDIT: worth mentioning I'm on the latest nightly:
For testing purposes? Repeat the test a number of times to ensure that it is unlikely that it will pass by an accident.
Yes, that is the ICE in question, and your difficulty in reproducing this underscores the problem here. Any ICE that relies on MIR inlining within a crate (as opposed to inlining a function from another crate) may stop reproducing basically at any time. I believe this is the same reason that bisects to unrelated commits.
Change:
<ins> // Copyright 2016 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. // Regression test for #41697. Using dump-mir was triggering // artificial cycles: during type-checking, we had to get the MIR for // the constant expressions in `[u8; 2]`, which in turn would trigger // an attempt to get the item-path, which in turn would request the // types of the impl, which would trigger a cycle. We supressed this // cycle now by forcing mir-dump to avoid asking for types of an impl. #![feature(rustc_attrs)] use std::sync::Arc; trait Foo { fn get(&self) -> [u8; 2]; } impl Foo for [u8; 2] { fn get(&self) -> [u8; 2] { *self } } struct Bar<T: ?Sized>(T); fn unsize_fat_ptr<'a>(x: &'a Bar<Foo + Send + 'a>) -> &'a Bar<Foo + 'a> { x } fn unsize_nested_fat_ptr(x: Arc<Foo + Send>) -> Arc<Foo> { x } fn main() { let x: Box<Bar<Foo + Send>> = Box::new(Bar([1,2])); assert_eq!(unsize_fat_ptr(&*x).0.get(), [1, 2]); let x: Arc<Foo + Send> = Arc::new([3, 4]); assert_eq!(unsize_nested_fat_ptr(x).get(), [3, 4]); } </ins>

Discussion:
running yields Happening on . Did not happen on the latest nightly available through rustup on 27.04.2017.
Last working nightly: First broken nightly: .
maybe it was ? cc
could be. let me try it on my big MIR refactoring branch =)
I confirm that the error occurs at but not at So it looks to me like is indeed the culprit.
Yes. I can reproduce. Will investigate.
I see the problem. PR coming soon.
Fix at
I'm still seeing this issue, on the latest nightly and on master.
can you give more details of how you are reproducing the problem? (I a test for the precise scenario reported, so I'm reasonably sure it's not that case anymore.)
Hmm, perhaps my regression test wasn't sufficient. I see I used ; I remember that the test did fail, but I guess that it passing doesn't prove all issues are resolved. =)
The earliest commit where I can reproduce this problem is
Change:
// CHECK-LABEL: @swap_rgb48 #[no_mangle] pub fn swap_rgb48(x: &mut RGB48, y: &mut RGB48) { <ins> // FIXME: See #115212 for why this has an alloca again // CHECK: alloca [3 x i16], align 2 // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.+}}, i64 6, i1 false) swap(x, y) } type RGBA64 = [u16; 4]; // CHECK-LABEL: @swap_rgba64 #[no_mangle] pub fn swap_rgba64(x: &mut RGBA64, y: &mut RGBA64) { </ins> // CHECK-NOT: alloca <del> // CHECK: load <3 x i16> // CHECK: load <3 x i16> // CHECK: store <3 x i16> // CHECK: store <3 x i16> </del> <ins> // CHECK-DAG: %[[XVAL:.+]] = load <4 x i16>, ptr %x, align 2 // CHECK-DAG: %[[YVAL:.+]] = load <4 x i16>, ptr %y, align 2 // CHECK-DAG: store <4 x i16> %[[YVAL]], ptr %x, align 2 // CHECK-DAG: store <4 x i16> %[[XVAL]], ptr %y, align 2 </ins> swap(x, y) }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Nearly 50% performance regression between versions 1.71 and 1.72 when copying small byte arrays with platform (Macbook Pro M1). Used to track down the regression to I tried this code: I expected to see this happen: to run about 6,200,000 ns/iter like version 1.71 Instead, this happened: 9,159,412 ns/iter <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.71 More specifically nightly-2023-06-06-aarch64-apple-darwin 72 nightly-2023-06-07-aarch64-apple-darwin <!-- Provide the version you are using that has the regression. --: Searched nightlies: from nightly-2023-06-06 to nightly-2023-06-07 regressed nightly: nightly-2023-06-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-stable -regression-untriaged
Here's a demo for :
Oof, that's massively worse. But even with a nice size (), it's still a small regression: We should probably revert , or limit it to very small arrays (<= 8 bytes / 1 usize? )
The original motivation of that PR is for arrays larger than that, so I'm not so sure. If I strip this down to just the pointer write it's not as bad, but it's quite clear that the problem is just x86-isel: Is that even good instruction selection?

Hmm, curiously looking at just the part of the push logic that copies the value, the assembly is entirely reasonable: then in the context of a "real" push, it somehow still blows up:
Here's a small tweak to try to fix this for 1.73:
I've opened to track the suboptimal codegen mentioned in Once a new nightly is out, please give it a shot and reopen if you're still seeing the regression.
On Ubuntu VM running on Ryzen 5950X this is far worse: 4x regression.
Things look much better with . Thanks for the quick fix!
Thanks for confirming! I'll see if it can make 1.73.
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 stdout = &io::stdout() as &io::WriterUtil; stdout.write_line("Hello!"); } </ins>

Discussion:
The following code compiles, but causes a segmentation fault when run: This is using master on Ubuntu.
I'll look at this, since I was working on something similar.
I cannot duplicate this on Mac OS X.
Note that in , I was testing against an "updated" version of the code that may not be faithful to the original bug scenario. But if that is the case, it may also be the case that this bug has gone away with type-checker changes since it was filed...
Seems to be fixed; pending for the test case. (I chose to add the original test case, except with stdin changed to stdout so we don't have a test case reading input, for fidelity to the original bug.)
Test case merged in - closing
Change:
cmd_finder.must_have(s); } <del> // this warning is useless in CI, // and CI probably won't have the right branches anyway. if !build_helper::ci::CiEnv::is_ci() { if let Err(e) = warn_old_master_branch(&build.config.git_config(), &build.config.src) .map_err(|e| e.to_string()) { eprintln!("unable to check if upstream branch is old: {e}"); } } </del> <ins> warn_old_master_branch(&build.config.git_config(), &build.config.src); </ins> }

Discussion:
When running any bootstrap command, it complains that it can't figure out whether my master branch is outdated. Of course it does, as it just YOLOs into , which is just a file and not a directory for worktrees: it should probably not do that (i don't have a suggestion on what to do instead) regressed by
i would say adding a bit of error handling that checks if it's in a worktree doesn't sound too hard. there's two options from there: emit the warning in a worktree. this is basically trivial, but if someone does 100% of their work in a worktree, they may end up with an outdated upstream and not know it back to a more reliable method when in a worktree
Change:
<ins> // run-pass #![feature(ptr_metadata)] // Address issue #112737 -- ICE with dyn Pointee extern crate core; use core::ptr::Pointee; fn raw_pointer_in(_: &dyn Pointee<Metadata = ()>) {} fn main() { raw_pointer_in(&42) } </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. -- Needs to reproduce, is not enough. <!-- 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
related: This shouldn't compile, but it does:
This is definitely fixed by , I'll add some tests and link this one.
whoops, forgot to add tests. marking as E-needs-test
I wouldn't mind giving this one a try if I'm understanding it correctly. Just add tests for the changes made in , should the original code at the top of this issue compile now and the code in the next comment, shouldn't compile?
correct. Please put some care into which subdirectory in these tests are placed, and make sure they're given at least somewhat descriptive names (i.e. not or anything like that).
Change:
// (a) idents can be in lots of places, so it'd be a pain // (b) we actually can, since it's a token. MatchedNonterminal(NtIdent(ref sn)) => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> r.cur_span = sn.span; r.cur_tok = token::Ident(sn.node); return ret_val; } <ins> MatchedNonterminal(NtTT(ref tt)) => { r.stack.push(TtFrame { forest: TokenTree::Token(sp, Interpolated(NtTT(tt.clone()))), idx: 0, dotdotdoted: false, sep: None, }); } </ins> MatchedNonterminal(ref other_whole_nt) => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> // FIXME(pcwalton): Bad copy. r.cur_span = sp; <del> r.cur_tok = token::Interpolated((*other_whole_nt).clone()); </del> <ins> r.cur_tok = Interpolated((*other_whole_nt).clone()); </ins> return ret_val; } MatchedSeq(..) => {

Discussion:
See discussion on .
The ability to convert token-trees AST is also needed to
Do we need that ability here? It's only about interpolated matches.
Fixed in .
Change:
// (a) idents can be in lots of places, so it'd be a pain // (b) we actually can, since it's a token. MatchedNonterminal(NtIdent(ref sn)) => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> r.cur_span = sn.span; r.cur_tok = token::Ident(sn.node); return ret_val; } <ins> MatchedNonterminal(NtTT(ref tt)) => { r.stack.push(TtFrame { forest: TokenTree::Token(sp, Interpolated(NtTT(tt.clone()))), idx: 0, dotdotdoted: false, sep: None, }); } </ins> MatchedNonterminal(ref other_whole_nt) => { <ins> r.stack.last_mut().unwrap().idx += 1; </ins> // FIXME(pcwalton): Bad copy. r.cur_span = sp; <del> r.cur_tok = token::Interpolated((*other_whole_nt).clone()); </del> <ins> r.cur_tok = Interpolated((*other_whole_nt).clone()); </ins> return ret_val; } MatchedSeq(..) => {

Discussion:
I haven't finished investigating this, so I'm making an issue just so I don't forget it:
Actually, I'm really not sure this should work. I'm nominating this for well-defined.
Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices. use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh) explicitly have three different versions of the macro, one for each sigil (bleah) clean up the second option by nesting one macro definition inside another one make sigils expand into macro invocations. Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.
Visiting for triage: still doesn't work, nothing more to add.
accepted for well-defined milestone
You can work around this by using a dummy macro so that you can pass the directly to it, e.g. for the example in the issue:
reading this workaround makes me feel like our macro system is really broken :(.
/cc
The modernized example gives me which looks like .
notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately :disappointed: ).
Updated example: error:
Triage: This is an ancient P-low bug but per it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?
Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix.

It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat). cc
Fixed in .
Change:
_ => false, } } <ins> /// This can happen for `async fn`, e.g. `async fn f<'_>(&'_ self)`. /// /// See [`lifetime_to_generic_param`] in [`rustc_ast_lowering`] for more information. /// /// [`lifetime_to_generic_param`]: rustc_ast_lowering::LoweringContext::lifetime_to_generic_param fn is_elided_lifetime(param: &hir::GenericParam<'_>) -> bool { match param.kind { hir::GenericParamKind::Lifetime { kind: hir::LifetimeParamKind::Elided } => true, _ => false, } } </ins> let impl_trait_params = self .params .iter()

Discussion:
When run on an with elided lifetimes, generates documentation containing the anonymous elided lifetimes in the function's signature. Running on the blocking variant of the same function produces a correct signature. You can reproduce this issue by generating docs for the following code: The asynchronous function's docs show the elided lifetimes, the blocking function's docs don't: :
I agree that this makes some function signatures unnecessarily verbose. For example: ... becomes ... However, given the nuances of async functions (specifically: the referenced values must survive every state of the FSM), one could argue that showing these lifetimes in the docs might be useful(?). It's obviously not the worst problem on earth, but could someone at least shed some light on whether this behaviour is intended or not? Is this a feature or a bug? Maybe
I think it's the expected behaviour. However we can discuss about removing the elided lifetimes. In this case it's not really useful...
It's especially visually disruptive with a parameter, making simple methods look significantly more complex than they actually are. It also feels surprising to special-case async functions like this, if it makes sense to show these lifetimes symmetry with traditional functions would be nice.
We have several instances of in the Tokio codebase because the version with explicit lifetimes is simpler than the one with all the elided ones displayed. There are many cases where it would be more useful to just not show lifetimes on the method.
So I don't forget, I got halfway through debugging this and it has something to do with 'in band lifetimes': Naively changing this to use the same mechanism as .
Funnily enough, this does work with 1.34 if you add enough s: ! So in some sense this is a regression, although you needed nightly to use at the time.
Change:
// Get the `hir::Param` to verify whether it already has any bounds. // We do this to avoid suggesting code that ends up as `T: FooBar`, // instead we suggest `T: Foo + Bar` in that case. <del> let mut has_bounds = false; </del> <ins> let mut has_bounds = None; </ins> let mut impl_trait = false; if let Node::GenericParam(ref param) = hir.get(id) { <del> match param.kind { hir::GenericParamKind::Type { synthetic: Some(_), .. } => { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (#63706) impl_trait = true; has_bounds = param.bounds.len() > 1; } _ => { has_bounds = !param.bounds.is_empty(); } </del> <ins> let kind = &param.kind; if let hir::GenericParamKind::Type { synthetic: Some(_), .. } = kind { // We've found `fn foo(x: impl Trait)` instead of // `fn foo<T>(x: T)`. We want to suggest the correct // `fn foo(x: impl Trait + TraitBound)` instead of // `fn foo<T: TraitBound>(x: T)`. (See #63706.) impl_trait = true; has_bounds = param.bounds.get(1); } else { has_bounds = param.bounds.get(0); </ins> } } let sp = hir.span(id); <del> // `sp` only covers `T`, change it so that it covers // `T:` when appropriate let sp = if has_bounds { sp.to(self.tcx .sess .source_map() .next_point(self.tcx.sess.source_map().next_point(sp))) </del> <ins> // `sp` only covers `T`, change it so that it covers `T:` when appropriate. let sp = if let Some(first_bound) = has_bounds { sp.until(first_bound.span()) </ins> } else { sp };

Discussion:
Missing a trait bound for the trait that defines below: Results in the following suggestion with an extra colon after the plus.
you can look at and for inspiration on how to deal with this.
I came up with a different solution, but there may be a subtlety I'm missing:
Change:
<ins> error: future cannot be sent between threads safely --> $DIR/issue-70935-complex-spans.rs:10:45 | LL | fn foo(tx: std::sync::mpsc::Sender<i32>) -> impl Future + Send { |                                             ^^^^^^^^^^^^^^^^^^ future created by async block is not `Send` | = help: the trait `Sync` is not implemented for `Sender<i32>` note: future is not `Send` as this value is used across an await --> $DIR/issue-70935-complex-spans.rs:13:9 | LL | /         baz(|| async{ LL | |             foo(tx.clone()); LL | |         }).await; | |________________^ first, await occurs here, with the value maybe used later... note: the value is later dropped here --> $DIR/issue-70935-complex-spans.rs:15:17 | LL |         }).await; |                 ^ note: this has type `[closure@$DIR/issue-70935-complex-spans.rs:13:13: 15:10]` which is not `Send` --> $DIR/issue-70935-complex-spans.rs:13:13 | LL |           baz(|| async{ |  _____________^ LL | |             foo(tx.clone()); LL | |         }).await; | |_________^ error: aborting due to previous error </ins>

Discussion:
Especially the fact that the lines are broken up seems like a bug. () Errors: modify labels: A-diagnostics, C-bug, D-papercut, T-compiler
There are two things here have a label that has embedded newlines which causes the broken down ASCII art should find a way to reverse the order in which multiline spans are sorted, but this will require handling multiple labels. The current order is optimized for not having to tweak the label positions, but when no labels are involved, we could do much better.
So, using raw text from the program as part of our label feels like a hack. We should try to come up with another way of getting a name (and falling back to a description like "async block" or something if that doesn't work). Failing a good way of doing that, I guess we can scan the program text for newlines and only use it if there aren't any..
Agree, we should never be using snippets in labels. The change needs to happen in You have the which lets you get the and from there use an appropriate description. I think there is an open PR that adds description to all variants.
Change:
<ins> // Crate tree without a `doc(primitive)` module for primitive type linked to by a doc link. #![deny(rustdoc::broken_intra_doc_links)] #![feature(no_core, lang_items, rustc_attrs)] #![no_core] #![rustc_coherence_is_core] #![crate_type = "rlib"] // @has no_doc_primitive/index.html //! A [`char`] and its [`char::len_utf8`]. impl char { pub fn len_utf8(self) -> usize { 42 } } </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
cc
Rustdoc assumes that there is always a module for every primitive type referred to by a doc link, which is not the case in the code example above or any "minimal core" example not containing the primitive documentation modules.
Fixed in
Change:
} } <del> /// Returns an iterator visiting all key-value pairs in ascending order by the keys, </del> <ins> /// Returns an iterator visiting all key-value pairs in ascending order of the keys, </ins> /// with mutable references to the values. /// The iterator's element type is `(uint, &'r mut V)`. ///

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!