jiebi/CodeConvo huggingface dataset:
Change:
LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression </del> <ins> error: unreachable call </ins> --> $DIR/expr_call.rs:18:5 | LL |     bar(return); <del> |     ^^^^^^^^^^^ </del> <ins> |     ^^^ </ins> error: aborting due to 2 previous errors

Discussion:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.
Change:
<ins> error[E0506]: cannot assign to `*x` because it is borrowed --> $DIR/issue-75785-confusing-named-region.rs:9:5 | LL | pub async fn async_fn(x: &mut i32) -> (&i32, &i32) { |                          - let's call the lifetime of this reference `'1` LL |     let y = &*x; |             --- borrow of `*x` occurs here LL |     *x += 1; |     ^^^^^^^ assignment to borrowed `*x` occurs here LL |     (&32, y) |     -------- returning this value requires that `*x` is borrowed for `'1` error: aborting due to previous error For more information about this error, try `rustc --explain E0506`. </ins>

Discussion:
Output (): The lifetime name should be given to the second reference in the tuple. modify labels: C-bug A-async-await A-diagnostics A-lifetimes T-compiler
On stable the output is different: Per bisect-rustc, the commit that changed the output is - almost definitely . is there something that can be done to improve this case? <details<summaryBisect output</summarysearched nightlies: from nightly-2020-06-01 to nightly-2020-07-15 regressed nightly: nightly-2020-07-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Here's the output with removed: It looks like we're missing the "let's call the lifetime of this reference" note in the case.
The current equivalent of that annotation is the note at the bottom: (see ) I actually ran into this while testing a potential fix for that issue - it would make the output Which still points at the wrong reference.
Are you still planning to work on this?
Change:
variant: Option<usize>, field: mir::Field, base_ty: Ty<'tcx>, <del> ) -> EvalResult<'tcx, Option<(Value, Ty<'tcx>)>> { </del> <ins> ) -> EvalResult<'tcx, ValTy<'tcx>> { </ins> let mut base_layout = self.layout_of(base_ty)?; if let Some(variant_index) = variant { base_layout = base_layout.for_variant(self, variant_index);

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
#![feature(fmt_internals)] #![feature(float_minimum_maximum)] #![feature(future_join)] <del> #![feature(future_poll_fn)] </del> #![feature(generic_assert_internals)] #![feature(array_try_from_fn)] #![feature(hasher_prefixfree_extras)]

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
left_pos.map_or(false, |s| s >= value.span.lo()), right_pos.map_or(false, |s| s <= value.span.hi()), ); <del> self.emit_unused_delims(cx, spans, ctx.into(), keep_space); </del> <ins> self.emit_unused_delims(cx, value.span, spans, ctx.into(), keep_space); </ins> } fn emit_unused_delims( &self, cx: &EarlyContext<'_>, <del> spans: (Span, Span), </del> <ins> value_span: Span, spans: Option<(Span, Span)>, </ins> msg: &str, keep_space: (bool, bool), ) { <del> // FIXME(flip1995): Quick and dirty fix for #70814. This should be fixed in rustdoc // properly. if spans.0 == DUMMY_SP || spans.1 == DUMMY_SP { return; } cx.struct_span_lint(self.lint(), MultiSpan::from(vec![spans.0, spans.1]), |lint| { let replacement = vec![ (spans.0, if keep_space.0 { " ".into() } else { "".into() }), (spans.1, if keep_space.1 { " ".into() } else { "".into() }), ]; lint.build(fluent::lint::unused_delim) .set_arg("delim", Self::DELIM_STR) .set_arg("item", msg) .multipart_suggestion( </del> <ins> let primary_span = if let Some((lo, hi)) = spans { MultiSpan::from(vec![lo, hi]) } else { MultiSpan::from(value_span) }; cx.struct_span_lint(self.lint(), primary_span, |lint| { let mut db = lint.build(fluent::lint::unused_delim); db.set_arg("delim", Self::DELIM_STR); db.set_arg("item", msg); if let Some((lo, hi)) = spans { let replacement = vec![ (lo, if keep_space.0 { " ".into() } else { "".into() }), (hi, if keep_space.1 { " ".into() } else { "".into() }), ]; db.multipart_suggestion( </ins> fluent::lint::suggestion, replacement, Applicability::MachineApplicable, <del> ) .emit(); </del> <ins> ); } db.emit(); </ins> }); }

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 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
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
<ins> // check-pass #![feature(inline_const)] fn main() { let _my_usize = const { let a = 10_usize; let b: &'_ usize = &a; *b }; } </ins>

Discussion:
There should be a test for ensuring that it does not have the same bug as and , that inside of the const refers to instead of inferring a lifetime. The following code is what passes and should be as a test: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you still working on this? If not, I would be happy to claim :slightlysmilingface:
there is no activity from them for almost a month, so you are free to claim it now
claim
Change:
probe::ObjectPick => { let trait_def_id = pick.item.container_id(self.tcx); <ins> // This shouldn't happen for non-region error kinds, but may occur // when we have error regions. Specifically, since we canonicalize // during method steps, we may successfully deref when we assemble // the pick, but fail to deref when we try to extract the object // type from the pick during confirmation. This is fine, we're basically // already doomed by this point. if self_ty.references_error() { return ty::GenericArgs::extend_with_error(self.tcx, trait_def_id, &[]); } </ins> self.extract_existential_trait_ref(self_ty, |this, object_ty, principal| { // The object data has no entry for the Self // Type. For the purposes of this method call, we

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' 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<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc
Change:
// Known prefixes must have been handled earlier. So if // we see a prefix here, it is definitely an unknown prefix. match self.first() { <del> '#' | '"' | ''' => UnknownPrefix, </del> <ins> '#' | '"' | ''' => InvalidPrefix, </ins> _ => InvalidIdent, } }

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
# source tarball for a stable release you'll likely see `1.x.0` for rustc and # `0.x.0` for Cargo where they were released on `date`. <del> date: 2018-12-09 </del> <ins> date: 2019-01-04 </ins> rustc: beta cargo: beta

Discussion:
For just a few weeks now, I am seeing many cases where rustbuild rebuilds stage 0 libstd (and hence rebuilds everything) even though nothing changed there. I have not yet tried to reproduce this in a clean dir (that would take forever due to all the rebuilding), but the steps are roughly as follows: Start with a clean dir The last step will rebuild everything even though nothing changed. The timing coincides a little with libstd depending on crates io, but that could be mere coincidence. Cc
Hm, I tried in a clean dir and cannot reproduce. I could have sworn I saw this multiple times. I'll reopen if I can reproduce later.
I see this too, it doesn't reproduce with clean build. To reproduce you need to Run Make some changes to libcore or liballoc (?) (not necessarily yourself, but for example by rebasing on master). Run again. Run again, which should be no-op, but it will actually start building almost everything starting with liballoc.
I have confirmed that it's indeed can be reproduced by touching libcore.
This has been bugging me, too. I bisected the regression to . cc I don't fully understand why, but for some reason Cargo thinks that one of liballoc's dependencies has changed, but I don't see any of them being different. I'll keep poking to better understand why the fingerprint check is failing. The following is a relatively quick repro: The second build should be fresh, but it isn't.
I have posted a proposed fix for this.
Change:
prior_arm_ty, prior_arm_span, scrut_span: scrut.span, <ins> scrut_hir_id: scrut.hir_id, </ins> source: match_src, prior_arms: other_arms.clone(), opt_suggest_box_span,

Discussion:
I tried this code (): I expected to see this happen: A compiler error about missing between and Instead, this happened: This is very confusing, because I "know" that return type is which is coercible to anything else (or whatever is the technical explanation for "we can really ignore the return type of "), so it should not ever be present in error messages about mistyping stuff. <!-- 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 issue is also present in 1.34.2 (from a year ago), and in two-week-old nightly (rustc 1.45.0-nightly ( 2020-05-11)) p.s.: When deminimizing the issue, i realized that it's even more confusing when match is the last statement in a for loop (as it was in my real code), i.e.: gives the same error message about incompatible match arms.
The s coerces to because the whole needs to evaluate as a statement, not an expression because its return value is ignored. Adding a trailing "fixes" the code.
As far as I can tell, didn't fix this issue (you didn't add a test for it either), and the two UI tests that the PR did touch, the suggestion didn't do anything useful -- it only fires when one of the arms is actually evaluated to be type , rather than being constrained to due to (lack of) semicolon.
Actually, we do suggest using a semicolon, but not via . I'm just gonna revert that, and add this as a test.
Change:
serde_derive = "1.0" rustfix = "0.4.1" lazy_static = "1.0" <ins> walkdir = "2" </ins> [target.'cfg(unix)'.dependencies] libc = "0.2"

Discussion:
If I modify a file in the rustc source code (), is smart enough to rerun all tests. However, if I modify something in , then still ignores the tests that completed successfully in the previous run. Steps to reproduce: tests: . For example, replace the function in  with: tests again: Expected output: some tests fail. Actual output:
I would be interested in fixing this issue myself if someone could give me some guidance on how to do that. The main thing that I do not understand is how understands that was changed. It seems that it does not use files for this because they include only the hash of the configuration options which do not include version. cc
The most likely culprit (that ignores the test files) is in module. It is called from and will set the flag for the test depending on its output.
That being said, I find it hard to see how to adjust compiletest itself to take the dependencies into account. rustbuild should probably have some sort of dependency edge and delete the stamp files if/when stuff like compiletest changes.
Compiletest source code has only 9 files. Would it be acceptable to check that their timestamps are newer than the timestamp of the stamp file? PR:
Change:
<ins> // issue#121613 #![feature(more_qualified_paths)] struct S<T> { a: T } struct Foo; trait A { type Assoc<T>; } impl A for Foo { type Assoc<T> = S<T>; } fn f() {} fn main() { <Foo as A>::Assoc::<i32> { a: 1 }; f(|a, b| a.cmp(b)); //~^ ERROR: type annotations needed //~| ERROR: this function takes 0 arguments but 1 argument was supplied } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
<ins> error: unknown start of token: u{ff09} --> $DIR/suggest-arg-comma-delete-ice.rs:15:14 | LL |     main(rahh）; |              ^^ | help: Unicode character '）' (Fullwidth Right Parenthesis) looks like ')' (Right Parenthesis), but it is not | LL |     main(rahh); |              ~ error[E0425]: cannot find value `rahh` in this scope --> $DIR/suggest-arg-comma-delete-ice.rs:15:10 | LL |     main(rahh）; |          ^^^^ not found in this scope error[E0061]: this function takes 0 arguments but 1 argument was supplied --> $DIR/suggest-arg-comma-delete-ice.rs:15:5 | LL |     main(rahh）; |     ^^^^ ---- unexpected argument | note: function defined here --> $DIR/suggest-arg-comma-delete-ice.rs:11:4 | LL | fn main() { |    ^^^^ help: remove the extra argument | LL -     main(rahh）; LL +     main(）; | error: aborting due to 3 previous errors Some errors have detailed explanations: E0061, E0425. For more information about an error, try `rustc --explain E0061`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.
Change:
use rustc_middle::ty::ParamEnv; use rustc_middle::ty::Ty; use rustc_middle::ty::TyCtxt; <ins> use rustc_middle::ty::ValTree; </ins> /// The source and destination types of a transmutation. #[derive(TypeVisitable, Debug, Clone, Copy)]

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 --
It's coming from calling at this line: I can take a look at it later, doesn't seem to be related to recent changes. Nice find. We're mistakenly assuming that the const has always already been evaluated by the time is called. claim
This one also seems to be regressing in :thinking: cc
Change:
<ins> #![feature(type_alias_impl_trait)] type Opaque<'a> = impl Sized + 'a; fn test(f: fn(u8)) -> fn(Opaque<'_>) { f //~ ERROR E0792 } fn main() {} </ins>

Discussion:
Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium