jiebi/CodeConvo huggingface dataset:
Change:
// SAFETY: the caller has to guarantee that `start - n` doesn't overflow. unsafe { start.unchecked_sub(n as Self) } } <ins> }; } // These are still macro-generated because the integer literals resolve to different types. macro_rules! step_identical_methods { () => { </ins> #[inline] #[allow(arithmetic_overflow)] #[rustc_inherit_overflow_checks]

Discussion:
I tried this code: I expected to see this happen: No UB. Instead, this happened: UB, confirmed by Miri. is called, which does , or . The implementation of is correct here, and should be safe to call. The implementation that does a wrapping cast from to before doing the unchecked math is the incorrect code here. Signed integers should switch to just using wrapping or unsigned math, whichever gets better codegen out of LLVM. We do have and methods now, but no . <!-- 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. --:
Note that this is reachable on stable since the default impl of uses and not all adapters forward both.
did you find this with Miri or just use Miri to confirm the bug? (I'm asking because I may want to add this to our "bugs found by Miri" list :)
Only confirmed/diagnosed with Miri, spotted manually when looking at the code.
Change:
<ins> // run-pass // edition:2021 const PATTERN_REF: &str = "Hello World"; const NUMBER: i32 = 30; const NUMBER_POINTER: *const i32 = &NUMBER; pub fn edge_case_ref(event: &str) { let _ = || { match event { PATTERN_REF => (), _ => (), }; }; } pub fn edge_case_str(event: String) { let _ = || { match event.as_str() { "hello" => (), _ => (), }; }; } pub fn edge_case_raw_ptr(event: *const i32) { let _ = || { match event { NUMBER_POINTER => (), _ => (), }; }; } pub fn edge_case_char(event: char) { let _ = || { match event { 'a' => (), _ => (), }; }; } fn main() {} </ins>

Discussion:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
candidates.sort_by(|a, b| a.cmp(b).reverse()); candidates.dedup(); <ins> // FIXME #21673 this help message could be tuned to the case // of a type parameter: suggest adding a trait bound rather // than implementing. </ins> let msg = format!( "methods from traits can only be called if the trait is implemented and in scope;  the following {traits_define} a method `{name}`, 

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
<ins> // run-rustfix fn main() { const _FOO: i32 = 123; //~^ ERROR const` and `let` are mutually exclusive const _BAR: i32 = 123; //~^ ERROR `const` and `let` are mutually exclusive } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should inform the user that and are mutually exclusive and suggest the user remove the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
match get_infer_ret_ty(&sig.decl.output) { Some(ty) => { let fn_sig = tcx.typeck(def_id).liberated_fn_sigs()[hir_id]; <ins> // Typeck doesn't expect erased regions to be returned from `type_of`. let fn_sig = tcx.fold_regions(fn_sig, &mut false, |r, _| match r { ty::ReErased => tcx.lifetimes.re_static, _ => r, }); </ins> let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_ty(ty); let mut diag = bad_placeholder_type(tcx, visitor.0);

Discussion:
Hello, While trying to figure out how to keep a JoinHandle in a thread-local variable, I tried compiling this incorrect code, and rust crashed. It will not panic if I use a regular static var instead of in a block. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE happens since 1.44 label: +regression-from-stable-to-stable
ping icebreakers-cleanup-crew can we add a bit more detail and trace where this starts?
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Regression between ... If I had to guess, I would say
Reduced testcase:
Not sure if of any help, but the thread_local macro is not needed:
const : Option<= map(value); ;)
Change:
|                  ~~~~~~~~ error: called `.get_mut().unwrap()` on a slice <del> --> tests/ui/get_unwrap.rs:100:33 </del> <ins> --> tests/ui/get_unwrap.rs:101:33 </ins> | LL |                         let b = rest.get_mut(linidx(j, k) - linidx(i, k) - 1).unwrap(); |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Instead, this happened: Apparently, taking a shared reference of will suppress the lint. This seems like a false negative. While false negatives can't be avoided entirely, this case seems to be avoidable as taking a shared reference shouldn't change the type of (which is ) or modify any data in this example. Note that will trigger the lint properly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
See also .
claim
Note this is a problem because which is supposed to fail to compile but this bug makes it fail at runtime instead
In case no one has dug into it yet, the error is suppressed in but not in and before:
label +regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-medium
This is caused by . It only ever worked because the lint ran after optimizations. I made a fix . It specializes the length of arrays as constant, even if the array isn't. I'm going to open a PR when I have time, probably tomorrow. In the long term, I'd like to implement some more extensive tracking of "what parts of a value are constant". For example, the compiler currently assumes that anything that had its reference taken can change, but actually, this can only happen inside (as I understand it).
Labels from the closed duplicate , label A-diagnostics, A-lint, A-mir-opt, T-compiler.
Fixed on stable label E-needs-test
I claim the add test part
This lint only appears on full builds (not check), but this will be fixed once lands.
Reopening because I feel this is not yet solved, see on . As per the , should nail down this issue?
MRE: Also, duplicate of
Another variant of this same issue:
Change:
|         ^^^^^^ = note: `#[warn(unreachable_code)]` implied by `#[warn(unused)]` <del> warning: unreachable expression </del> <ins> warning: unreachable call </ins> --> $DIR/never-assign-dead-code.rs:10:5 | LL |     drop(x); <del> |     ^^^^^^^ </del> <ins> |     ^^^^ </ins> warning: unused variable: `x` --> $DIR/never-assign-dead-code.rs:9:9

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:
full_decoded => panic!("expected finite, got {:?} instead", full_decoded) } } <ins> #[bench] fn bench_small_shortest(b: &mut Bencher) { let mut buf = Vec::with_capacity(20); b.iter(|| { buf.clear(); write!(&mut buf, "{}", 3.1415926f64).unwrap() }); } #[bench] fn bench_big_shortest(b: &mut Bencher) { let mut buf = Vec::with_capacity(300); b.iter(|| { buf.clear(); write!(&mut buf, "{}", f64::MAX).unwrap() }); } </ins>

Discussion:
floattodecimalcommon in does this: let mut buf = [0; 1024]; let mut parts = [flt2dec::Part::Zero(0); 16]; and then passes buf and parts to flt2dec::toexactfixedstr or flt2dec::toshorteststr Looking at the docs for those functions at and the "parts" array needs to have length at least 5, right? And the "buf" array needs to be at least 800+ for the toexactfixedstr case but only 17 (MAXSIGDIGITS) for the toshorteststr case, afaict. Changing the toshorteststr case to not use the huge buffer would probably help out too. Also, it's not clear to me that the "buf" scratch buffer needs to be zero-initialized. Does it?
Note that I'm poking at this a bit.
I spun off the zeroing thing into because I have a fix for that... we may still want to make the stackframe here smaller, though.
Change:
LL | fn f() { |[](* } |             ^ expected one of `,` or `:` <del> error: expected one of `&`, `(`, `)`, `-`, `...`, `..=`, `..`, `[`, `_`, `box`, `const`, `mut`, `ref`, `|`, identifier, or path, found `*` </del> <ins> error: expected one of `&`, `(`, `)`, `-`, `...`, `..=`, `..`, `[`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*` </ins> --> $DIR/issue-66357-unexpected-unreachable.rs:14:14 | LL | fn f() { |[](* }

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
let rust_lld = exe("rust-lld", compiler.host); builder.copy(&src_dir.join(&rust_lld), &dst_dir.join(&rust_lld)); // for `-Z gcc-ld=lld` <del> let gcc_lld_dir = dst_dir.join("gcc-ld"); t!(fs::create_dir(&gcc_lld_dir)); builder.copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld", compiler.host))); builder .copy(&src_dir.join(&rust_lld), &gcc_lld_dir.join(exe("ld64", compiler.host))); </del> <ins> let gcc_lld_src_dir = src_dir.join("gcc-ld"); let gcc_lld_dst_dir = dst_dir.join("gcc-ld"); t!(fs::create_dir(&gcc_lld_dst_dir)); for flavor in ["ld", "ld64"] { let exe_name = exe(flavor, compiler.host); builder .copy(&gcc_lld_src_dir.join(&exe_name), &gcc_lld_dst_dir.join(&exe_name)); } </ins> } // Copy over llvm-dwp if it's there

Discussion:
Checked that on target, found duplicates in versions: and <strikeno duplicates</strike2 duplicates (<strikeonly</strike, ) in stable , (bisecting is kinda slow on my connection) there 3 copies of that executable, that gives ~ 187mb label +regression-from-stable-to-beta
Can be found in:
I think they were in and . I believe is also a copy of .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
claim
Sorry, I only came across this issue just now. The copies are there for a reason, see linked issues. Multiple things to consider: The files in the directory are only used with the unstable option. So they could be removed for beta and stable. They can be replaced with small Rust executables which just exec and respectively. I will be working on that for nightly.
Change:
<ins> // Ensure assert macro does not ignore trailing garbage. // // See https://github.com/rust-lang/rust/issues/60024 for details. fn main() { assert!(true some extra junk, "whatever"); //~^ ERROR expected one of assert!(true some extra junk); //~^ ERROR expected one of assert!(true, "whatever" blah); //~^ ERROR no rules expected assert!(true "whatever" blah); //~^ WARN unexpected string literal //~^^ ERROR no rules expected assert!(true;); //~^ WARN macro requires an expression assert!(false || true "error message"); //~^ WARN unexpected string literal } </ins>

Discussion:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.
Change:
<ins> use std::ops::Deref; pub struct A {} impl A { pub fn foo_a(&self) {} } pub struct B {} impl B { pub fn foo_b(&self) {} } pub struct C {} impl C { pub fn foo_c(&self) {} } // @has recursive_deref_sidebar/struct.A.html '//div[@class="sidebar-links"]' 'foo_b' impl Deref for A { type Target = B; fn deref(&self) -> &B { todo!() } } // @!has recursive_deref_sidebar/struct.A.html '//div[@class="sidebar-links"]' 'foo_c' impl Deref for B { type Target = C; fn deref(&self) -> &C { todo!() } } </ins>

Discussion:
I don't have time to make an MCVE right now. Stable and beta: ! Nightly and 1.51: ! 50: ! Either the methods should be documented, or they shouldn't be linked to. cc I suspect this is regression from the backports of
First of all, here's an MVCE: Nevermind, I see this is getting discussed in
Removed , this is not a 1.53 regression.
sure, then it's a stable-to-stable regression then. It first regressed in 1.52.
Change:
<ins> //@ compile-flags: -C strip=debuginfo //@ only-msvc //@ run-pass use std::path::Path; pub fn is_related_pdb<P: AsRef<Path>>(path: &P, exe: &P) -> bool { let (exe, path) = (exe.as_ref(), path.as_ref()); path.extension() .map(|x| x.to_ascii_lowercase()) .is_some_and(|x| x == "pdb") && path.file_stem() == exe.file_stem() } pub fn main() { let curr_exe = std::env::current_exe().unwrap(); let curr_dir = curr_exe.parent().unwrap(); let entries = std::fs::read_dir(curr_dir).unwrap(); assert!(entries .map_while(|x| x.ok()) .find(|x| is_related_pdb(&x.path(), &curr_exe)) .is_some()); } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Setting up a release profile with stripped binaries and split debuginfo is made very complicated due to subtle differences in how , and interact with eachother across platforms. In particular, in the following setup: Then when targetting linux/macos, a / debug information file will be generated, while when targeting windows, no debug information file can be found. In particular, no file is created. This seems to stem from how the flags propagate to linker invocation: On windows, of rustccodegenssa only takes into account when choosing how to generate the debug information. If it's set to any value other than None, it will not generate any debuginfo whatsoever, regardless of the value of . On macos/linux, it's  that's responsible both for splitting debuginfo and stripping. A / file will be created only if is set to a value other than 0, and is set to packed. Stripping is, crucially, not a part of the equation. I believe the behavior with the windows should be adjusted to match what is done on macos/linux. In particular, if is set to and strip is set to , then a file should be generated. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
I believe is also effected by such inconsistencies. Would be nice to have consistent behavior. And possibly a flag that produces both an unstripped and stripped binary, though that's a separate feature.
Change:
Then, when looking for it through the `rustdoc` search, if you enter "x" or "big", search will show the `BigX` struct first. <ins> There are some limitations on the doc alias names though: you can't use `"` or whitespace. </ins>

Discussion:
From this comment: Still remaining the .
Actually, the character has a meaning in the search (for "exact" search). But instead of just removing it, maybe we should instead emit an error when we encounter it. What do you think ?
That doesn't work for though, maybe it should? It would make sense to restrict allowed characters because even whitespace is allowed at the moment which seems questionable.
It sounds like we need to make sure this lands before we branch beta or so?
Let's forbid , whitespaces and tabs in the the doc alias then.
Can we avoid ad-hoc rules and say something like "must be a rust identifier"?
Even better! Great suggestion !
Just thought about it, but it cannot be the case : we allow things like "*" or "+" (for the traits for example), so it cannot be ident only. I'll stick to the listed characters above.
The documentation () has no mention of that -- can you elaborate?
Doc aliases can be something else than a rust identifier. For example, you can look for or in the std docs, and you'll see aliases results.
Ah, I see what you mean. Okay, then I agree that we need more than just Rust identifiers, and it might be reasonable to just allow as you suggest -- everything except whitespace and quotes. I'm a bit worried that'll hurt us in terms of how expansive it is but it's probably fine.
I don't expect attributes to be used widely, so we should be fine. ;)
Is there more justification for removing whitespace support other than calling the characters questionable? If I have a struct or a function that implements an algorithm, I would like to alias the item to the plaintext name of the algorithm, for example .
I just had in mind "idents", so no whitespace in them. However I don't see any reason to not allow specfically. I'll send a PR tomorrow.
rustdoc only being ident-centric is .
path-centric would be more accurate. ;)
Change:
<ins> // Copyright 2013-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. // ignore-android: FIXME(#10381) // compile-flags:-g // debugger:break issue12886.rs:29 // debugger:run // debugger:next // check:[...]30[...]s // debugger:continue // IF YOU MODIFY THIS FILE, BE CAREFUL TO ADAPT THE LINE NUMBERS IN THE DEBUGGER COMMANDS // This test makes sure that gdb does not set unwanted breakpoints in inlined functions. If a // breakpoint existed in unwrap(), then calling `next` would (when stopped at line 27) would stop // in unwrap() instead of stepping over the function invocation. By making sure that `s` is // contained in the output, after calling `next` just once, we can be sure that we did not stop in // unwrap(). (The testing framework doesn't allow for checking that some text is *not* contained in // the output, which is why we have to make the test in this kind of roundabout way) fn bar() -> int { let s = Some(5).unwrap(); s } fn main() { let _ = bar(); } </ins>

Discussion:
Debugging code from , if I set a breakpoint in gdb inside gc_callback in I see messages like . This correctly breaks on the line, but trying to advance continues to break on the line each time in inlined code like transmute and borrow.
Good catch! I think I had a patch once that would turn off emitting source locations for inlined functions but it will probably be bit-rotted by now. I'll look into it next!
Can we try to come up with some minimal code to reproduce this behavior reliably? As pointed out, it would be great to have an autotest before closing the issue.
Wow, that was quick Thanks a lot!
At least for this example the issue seems to be fixed after PR has landed. I'll add this to the autotests next week and then, I think, we can close this issue.
Change:
= note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information = help: add `#![feature(const_generics)]` to the crate attributes to enable <del> error[E0741]: the types of const generic parameters must derive `PartialEq` and `Eq` </del> <ins> error[E0741]: `T` is not guaranteed to `#[derive(PartialEq, Eq)]`, so may not be used as the type of a const parameter </ins> --> $DIR/const-param-type-depends-on-type-param-ungated.rs:3:22 | LL | struct B<T, const N: T>(PhantomData<[T; N]>); <del> |                      ^ `T` doesn't derive both `PartialEq` and `Eq` </del> <ins> |                      ^ `T` may not derive both `PartialEq` and `Eq` | = note: it is not currently possible to use a type parameter as the type of a const parameter </ins> error: aborting due to 2 previous errors

Discussion:
I tried this code: This produces the following error on rustc 1.44.0-nightly: I guess that const generics with a generic type isn't supported/allowed. If that's the case, this should be mentioned in the error message. :
The type needs to derive , not just implement them. This is because only types can be used for const generics at the moment, but we don't expose that to the user. Maybe we could improve the diagnostic here by actually mentioning .
thanks for fixing this so quickly! Is there a chance that this restriction will be lifted, so the above code compiles?
We would like to lift the restriction, but probably not in the first stabilised version of const generics, as it's not easy to get right: we need to be very careful in making sure that we don't accidentally allow unsoundness to sneak in, and there are many subtleties.