jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0412]: cannot find type `OsStr` in this scope --> $DIR/issue-84108.rs:6:24 | LL | static FOO: (dyn AsRef<OsStr>, u8) = ("hello", 42); |                        ^^^^^ not found in this scope | help: consider importing this struct | LL | use std::ffi::OsStr; | error[E0412]: cannot find type `Path` in this scope --> $DIR/issue-84108.rs:9:14 | LL | const BAR: (&Path, [u8], usize) = ("hello", [], 42); |              ^^^^ not found in this scope | help: consider importing this struct | LL | use std::path::Path; | error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/issue-84108.rs:9:12 | LL | const BAR: (&Path, [u8], usize) = ("hello", [], 42); |            ^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[u8]` = note: only the last element of a tuple may have a dynamically sized type error[E0277]: the size for values of type `[u8]` cannot be known at compilation time --> $DIR/issue-84108.rs:13:13 | LL | static BAZ: ([u8], usize) = ([], 0); |             ^^^^^^^^^^^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `[u8]` = note: only the last element of a tuple may have a dynamically sized type error: aborting due to 4 previous errors Some errors have detailed explanations: E0277, E0412. For more information about an error, try `rustc --explain E0277`. </ins>

Discussion:
The bug should be different from , as the stack traces are different. <!-- 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
Bisected:
Weirdly, the ICE only happens when you don't import . I.e., this ICEs: but this gives an appropriate unsized field error:
The error happens when a is involved, which makes the sizedness check for not to be evaluated. A way to side-step the issue is to change to be
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
A potential duplicate. <!-- 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
Change:
<ins> fn main() { a((), 1i32 == 2u32); //~^ ERROR cannot find function `a` in this scope //~| ERROR mismatched types } </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
Regression in /
Perhaps ? :thinking: cc
list of files that reproduce the crash ( is eough) `
I think we should change to a

Found with a From : From : Deep recursion involving ? Regression in nightly-2022-10-07, apparently in rollup . I suspect (
Change:
/// Changes the current working directory to the specified path. /// <ins> /// # Platform-specific behavior /// /// This function currently corresponds to the `chdir` function on Unix /// and the `SetCurrentDirectoryW` function on Windows. /// </ins> /// Returns an [`Err`] if the operation fails. /// /// # Examples

Discussion:
As of now, the stable and nightly documentation on only states And proceeds to note a couple of errors the function may fail with. This does not mention the fact that (as far as I am aware, testing on Linux) the path is also canonicalized, having resolved all symlinks in any segment of the path. I'd imagine not documenting this behavior could lead to confusion and/or bugs, if it already hasn't. I tried this code within a symlink folder pointing to : I expected to see get the output: Instead, this was output: Currently using the nightly compiler. For obvious reasons, there's no backtrace. Update: Read a bit through the code and realized this behavior might be libc-dependent on my system returns
For UNIX Rust just calls and that behavior is documented in the , so it will be the same on all conforming implementations. We should document which platform-specific function we call here just like we do with other filesystem functions (e.g. ). label T-libs A-docs
It was also missing for so I opened for both.
Thanks a lot
Change:
let (param_env, unevaluated) = unevaluated.prepare_for_eval(tcx, param_env); // try to resolve e.g. associated constants to their definition on an impl, and then // evaluate the const. <del> let c = tcx.const_eval_resolve_for_typeck(param_env, unevaluated, span)?; Ok(c.expect("`ty::Const::eval` called on a non-valtree-compatible type")) </del> <ins> let Some(c) = tcx.const_eval_resolve_for_typeck(param_env, unevaluated, span)? else { // This can happen when we run on ill-typed code. let e = tcx.sess.span_delayed_bug( span.unwrap_or(DUMMY_SP), "`ty::Const::eval` called on a non-valtree-compatible type", ); return Err(e.into()); }; Ok(c) </ins> } ConstKind::Value(val) => Ok(val), ConstKind::Error(g) => Err(g.into()),

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 same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- 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 --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing
Change:
<ins> error[E0597]: `local` does not live long enough --> $DIR/local-outlives-static-via-hrtb.rs:24:28 | LL |     assert_static_via_hrtb(&local); |     -----------------------^^^^^^- |     |                      | |     |                      borrowed value does not live long enough |     argument requires that `local` is borrowed for `'static` LL |     assert_static_via_hrtb_with_assoc_type(&&local); LL | } | - `local` dropped here while still borrowed error[E0597]: `local` does not live long enough --> $DIR/local-outlives-static-via-hrtb.rs:25:45 | LL |     assert_static_via_hrtb_with_assoc_type(&&local); |     ----------------------------------------^^^^^^- |     |                                       | |     |                                       borrowed value does not live long enough |     argument requires that `local` is borrowed for `'static` LL | } | - `local` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from
Change:
assert-css: ("#method.must_use", {"color": "rgb(221, 221, 221)", "background-color": "rgb(73, 74, 61)"}, ALL) goto: file://|DOC_PATH|/test_docs/index.html <del> assert-css: (".section-header a", {"color": "rgb(221, 221, 221)"}, ALL) </del> <ins> assert-css: (".small-section-header a", {"color": "rgb(221, 221, 221)"}, ALL) goto: file://|DOC_PATH|/test_docs/struct.HeavilyDocumentedStruct.html assert-css: (".section-header a", {"color": "rgb(210, 153, 29)"}, ALL) </ins> // Light theme local-storage: {"rustdoc-theme": "light", "rustdoc-use-system-theme": "false"}

Discussion:
They used to be blue and are now black. I don't think this change was intentional, although we have been thinking about migrating more headers to be black recently. I think this regressed very recently, since I probably would have noticed it otherwise. !
I wonder if this was caused by or ? Those were both merged recently, though the second one doesn't seem like it could have changed colors. cc
This regressed in , which as one of the rules for an anchor to be styled black. The goal with that change was to make the section headings on module pages black (e.g. ). Those have . However, headings generated from Markdown in a docblock also have . I think the right short-term fix is: Section headings on module pages get , like their peers on other pages. Remove the CSS rule for to be black. It's not really clear to me why Markdown gets , and Rustdoc-generated headings get , particularly given that the Rustdoc headings are almost always bigger. Probably we should rename these to and .
Since you figured out a way to fix this regression, do you want to assign yourself and open a PR with the fix?
Will do.
Change:
#[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> fn is_null(self) -> bool { self as usize == 0 } </del> <ins> fn is_null(self) -> bool { self == 0 as *mut T } </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
Consider the following benchmark: Which produces the following output: test _range ... bench: ns/iter (+/- 1033) test assembly ... bench: ns/iter (+/- 248) test enumerate ... bench: ns/iter (+/- 566) test iter ... bench: ns/iter (+/- 465) test position ... bench: ns/iter (+/- 384) is the correct abstraction for this but its code is 50% slower than the naive assembly implementation and 40% slower than .
I'm getting different results: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 8183) test enumerate ... bench: ns/iter (+/- 1615) test iter ... bench: ns/iter (+/- 4164) test position ... bench: ns/iter (+/- ) test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured (the assembly version segfaulted on me).
wow. What platform?
On a macbook. Here's another run without a bunch of stuff in the background screwing up the variance: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 2331) test enumerate ... bench: ns/iter (+/- 2851) test iter ... bench: ns/iter (+/- 3995) test position ... bench: ns/iter (+/- 978)
The IL for -s inner loop is (de-gensymmed) Which looks sane, except for the spurious null check (which remains in the assembly). Benchmarks on my machine:
The spurious null check is the issue – writing a over it in the object code gives ±385 ns/iter on my laptop.
New code: New results: Unacceptable performance.
Change:
unsafe { let ret = libc::pthread_join(self.id, ptr::null_mut()); mem::forget(self); <del> debug_assert_eq!(ret, 0); </del> <ins> assert!(ret == 0, "failed to join thread: {}", io::Error::from_raw_os_error(ret)); </ins> } }

Discussion:
Considering following snippets: Currently on linux, the spawned thread will just panic at option unwrap which happen inside std library: It makes no sense to call join inside the associated thread, but a meaningless panic is sure not the good way to handle this situation. Maybe we should return an error which contains the join handle, so the caller can recover the failure. If panic is preferred, then a more friendly message should be good for users.
This seems like a reasonable-ish panic, though it would perhaps be better to have the error be returned within the result, though the current behavior is as documented, so I think it's reasonable.

Gives (on playground): There are two problems here: error message is absolutely terrible. the sake of safety, we might need to do something other than panic if this happens. This could affect crates which require that join() never returns early, like crossbeam.
Possibly in or otherwise, but this seems to have since been fixed -- this now deadlocks.
Change:
} Len(place) => { <del> let len = match self.get_const(place)? { Value::Immediate(src) => src.len(&self.ecx).discard_err()?, Value::Aggregate { fields, .. } => fields.len() as u64, Value::Uninit => match place.ty(self.local_decls(), self.tcx).ty.kind() { ty::Array(_, n) => n.try_eval_target_usize(self.tcx, self.param_env)?, _ => return None, }, </del> <ins> let len = if let ty::Array(_, n) = place.ty(self.local_decls(), self.tcx).ty.kind() { n.try_eval_target_usize(self.tcx, self.param_env)? } else { match self.get_const(place)? { Value::Immediate(src) => src.len(&self.ecx).discard_err()?, Value::Aggregate { fields, .. } => fields.len() as u64, Value::Uninit => return None, } </ins> }; ImmTy::from_scalar(Scalar::from_target_usize(len, self), layout).into() }

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:
} match *rcvr_args.type_at(0).kind() { ty::Closure(closure_def_id, args) => { <del> let trait_closure_kind = tcx.fn_trait_kind_from_def_id(trait_id).unwrap(); Some(Instance::resolve_closure( tcx, closure_def_id, args, trait_closure_kind, )) </del> <ins> Some(Instance::resolve_closure(tcx, closure_def_id, args, target_kind)) </ins> } ty::FnDef(..) | ty::FnPtr(..) => Some(Instance { def: ty::InstanceDef::FnPtrShim(trait_item_id, rcvr_args.type_at(0)),

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/integer-literal-generic-arg-in-where-clause.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
() Gives the error: This compiles fine with const_generics not enabled, and is a regression cc
(discovered by
cc Simplified:
Isn't this expected fallout?
This is an expected consequence of
Seems like is what's supposed to eventually fix this?
triage: P-medium (nightly-only regression on feature that is known to have bugs)
I think we've discussed this before, but what do you think of special-casing literals, to unblock at least some common usecases like this?
I can't reproduce on master, this may have gotten fixed? (Note that the playground is severely outdated, a fix is underway for that though)
pointed out that most likely fixed this.
Change:
} } <ins> let mut mpis = vec![mpi]; let move_paths = &self.move_data.move_paths; mpis.extend(move_paths[mpi].parents(move_paths).map(|(mpi, _)| mpi)); </ins> let mut stack = Vec::new(); <del> stack.extend(predecessor_locations(self.body, location).map(|predecessor| { let is_back_edge = location.dominates(predecessor, &self.dominators); (predecessor, is_back_edge) })); </del> <ins> let mut back_edge_stack = Vec::new(); predecessor_locations(self.body, location).for_each(|predecessor| { if location.dominates(predecessor, &self.dominators) { back_edge_stack.push(predecessor) } else { stack.push(predecessor); } }); let mut reached_start = false; /* Check if the mpi is initialized as an argument */ let mut is_argument = false; for arg in self.body.args_iter() { let path = self.move_data.rev_lookup.find_local(arg); if mpis.contains(&path) { is_argument = true; } } </ins> let mut visited = FxHashSet::default(); let mut move_locations = FxHashSet::default(); let mut reinits = vec![]; let mut result = vec![]; <del> 'dfs: while let Some((location, is_back_edge)) = stack.pop() { </del> <ins> let mut dfs_iter = |result: &mut Vec<MoveSite>, location: Location, is_back_edge: bool| { </ins> debug!( "report_use_of_moved_or_uninitialized: (current_location={:?}, back_edge={})", location, is_back_edge ); if !visited.insert(location) { <del> continue; </del> <ins> return true; </ins> } // check for moves

Discussion:
Forgetting to initialize a non-Copy variable in a loop and then referring to it gives a 'borrowed after move' error, instead of a 'possibly-uninitialized variable' error: Using a type like does result in the right error: Tested with 1.43.0 (stable) and 1.45.0-nightly.
In both Ada and D languages (in different ways, in Ada it's more refined) there's a way to tell the type system that the input variable to that bla function is not initialized and that bla must initialize it, and inside bla you can't read it before it's initialized. This means you have a way to propagate the not initialized state in function arguments, and safety is preserved. In practice this is not a big problem for Rust because in Rust you can return tuples and now Rustc is getting logic to optimize this usage pattern.
Uh, this issue is just about the error message. That this code gives an error is fine.
I'd be interested in fixing this myself, but I'm not sure where to start.
This is an issue for a command line program I'm writing. At the beginning of a function, I declare some uninitialized variables, and then I have a loop for each one. In this loop, it will read user input, and if it is valid, assign the variable that value. The loop will never complete without the variable being initialized, but rustc refuses to compile because it thinks the variable could be uninitialized after the loop.
That sounds like a different issue. This issue is about a confusing error message. The example is supposed to not compile. If the compiler rejects correct code, that's another issue.
To add context, I find this example illustrates the problem more clearly for me: the same code with the same types, just outside a loop context:
Change:
// (See issue: https://github.com/rust-lang/rust/issues/117271) assert!( matches!(&*cx.tcx.sess.target.arch, "wasm32" | "wasm64") <del> || fn_abi.conv == Conv::PtxKernel, "`PassMode::Direct` for aggregates only allowed on wasm and `extern "ptx-kernel"` fnsnProblematic type: {:#?}", </del> <ins> || matches!(spec_abi, SpecAbi::PtxKernel | SpecAbi::Unadjusted), r#"`PassMode::Direct` for aggregates only allowed for "unadjusted" and "ptx-kernel" functions and on wasmnProblematic type: {:#?}"#, </ins> arg.layout, ); }

Discussion:
Crate bytecount compilation fails with latest nightly on NanoPC-T6 (RK3588 ARM / aarch64). It worked yesterday. I tried this code: Updating index Adding bytecount v0.6.7 to dependencies. Features: generic-simd htmlreport packedsimd runtime-dispatch-simd Updating index Compiling bytecount v0.6.7 Intrinsic has incorrect return type! ptr in function ZN4core9corearch10armshared4neon9generated11vld1qu8x417hd6e0965b4ff7ff22E LLVM ERROR: Broken function found, compilation aborted! error: could not compile (lib) Compiling bytecount v0.6.7 Compiling bytecounttest v0.1.0 (/home/pi/bytecounttest) Finished dev [unoptimized + debuginfo] target(s) in 0.90s Linux NanoPC-T6 5.10.160 SMP Thu Jul 20 15:53:55 CST 2023 aarch64 aarch64 aarch64 GNU/Linux PRETTYNAME="Ubuntu 22.04.3 LTS" NAME="Ubuntu" VERSIONID="22.04" VERSION="22.04.3 LTS (Jammy Jellyfish)" VERSIONCODENAME=jammy ID=ubuntu IDLIKE=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" UBUNTUCODENAME=jammy I expected to see this happen: Finished dev [unoptimized + debuginfo] target(s) in 1.32s Instead, this happened: LLVM ERROR: Broken function found, compilation aborted!
searched nightlies: from nightly-2023-11-19 to nightly-2023-11-20 regressed nightly: nightly-2023-11-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailslooks like something in that PR changed ABI behavior and now LLVM and rustc disagree. Don't know who's wrong.
Hm, I don't know how that "unadjusted" ABI stuff works...
should fix this. I am not sure how to add a test.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
/// # Ok(()) /// # } /// ``` <ins> #[stable(feature = "rust1", since = "1.0.0")] </ins> #[rustc_deprecated(since = "1.1.0", reason = "replaced with std::os::unix::fs::symlink and  std::os::windows::fs::{symlink_file, symlink_dir}")] <del> #[stable(feature = "rust1", since = "1.0.0")] </del> pub fn soft_link<P: AsRef<Path>, Q: AsRef<Path>>(src: P, dst: Q) -> io::Result<()> { fs_imp::symlink(src.as_ref(), dst.as_ref()) }

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .