jiebi/CodeConvo huggingface dataset:
Change:
<ins> // ICEs if checking if there is a significant destructor causes a query cycle // check-pass #![warn(rust_2021_incompatible_closure_captures)] pub struct Foo(Bar); pub struct Bar(Baz); pub struct Baz(Vec<Foo>); impl Foo { pub fn baz(self, v: Baz) -> Baz { (|| v)() } } fn main() {} </ins>

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. --Error <codeerror[E0391] cycle detected when computing when has a significant destructor</codeoccurs when warn/deny lint on rust beta and nightly with a certain code snippet. On rust stable, it compiles without any issues. Looks like an issue of rustc (). I tried this code: It compiles successfully on stable or with : But with this lint warned (or denied) it does not compile on rust beta and on rust nightly with error: : <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisects to , CC Although this is a regression from stable to beta, there's not enough time for it to get fixed before release.
Oops. Yeah, i read the error message and immediately knew what was going on. I can hopefully get a patch up for this tomorrow. claim
label regression-from-stable-to-stable, -regression-from-stable-to-beta
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
#![feature(bigint_helper_methods)] #![feature(cell_update)] #![feature(const_align_offset)] <del> #![feature(const_assume)] </del> #![feature(const_align_of_val_raw)] #![feature(const_black_box)] #![feature(const_caller_location)]

Discussion:
The feature gate for the issue is . It makes usable in const contexts. Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- 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. --- [x] Implemented in [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [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. --<!-- Include a list of all the PRs that were involved in implementing the feature. --
Do you want to stabilize the feature? I was asked to use in const context here:
WG-const-eval has confirmed that this is fine: Feel free to send in a PR flipping the stability attribute. It's an unstable intrinsic so we aren't really committing to anything.
Change:
#[cfg(not(target_os = "espidf"))] let detail = unsafe { <del> str::from_utf8(CStr::from_ptr(libc::gai_strerror(err)).to_bytes()).unwrap().to_owned() </del> <ins> // We can't always expect a UTF-8 environment. When we don't get that luxury, // it's better to give a low-quality error message than none at all. CStr::from_ptr(libc::gai_strerror(err)).to_string_lossy() </ins> }; #[cfg(target_os = "espidf")]

Discussion:
version: nightly-2023-11-22 os: centos-7 panic: thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } note: run with environment variable to display a backtrace thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } thread '' panicked at called on an value: Utf8Error { validupto: 4, errorlen: Some(1) } thread '' panicked at called on an value: Utf8Error { validupto: 4, error_len: Some(1) }
You are using a nightly that is over half a year old. Try using the latest nightly to see if it reproduces. If it does, please set and report back the printed backtrace as well as the project on which you get this panic.
Based on my testing, the latest version also has this issue.
It would appear that your libc's  function is not returning a UTF-8 encoded string (the fourth byte is invalid).
Can you share some of your system config, especially your locale? gai_strerror returning invalid UTF-8 is certainly not something expected by std.
<img width="955" alt="image" src=""
Which Chinese locale exactly? Could you show the values of the environment variables?
Sorry, the environment is no longer available, but it seems that using unwrap in is too risky.
It's probably not a UTF-8 locale. I would really recommend changing your locale to a UTF-8 one if possible, then this should work again. But you're right, this unwrap shouldn't be there, normal uses from lossy, which will give a bad error but at least won't crash. I'll send a PR.
Change:
<ins> error: expected parameter name, found `,` --> $DIR/issue-110892.rs:27:9 | LL |         , |         ^ expected parameter name error: expected parameter name, found `,` --> $DIR/issue-110892.rs:28:9 | LL |         , |         ^ expected parameter name error: expected parameter name, found `,` --> $DIR/issue-110892.rs:29:9 | LL |         , |         ^ expected parameter name error: expected parameter name, found `,` --> $DIR/issue-110892.rs:30:9 | LL |         , |         ^ expected parameter name error[E0308]: mismatched types --> $DIR/issue-110892.rs:31:10 | LL |     const fn from_options( |              ------------ implicitly returns `()` as its body has no tail or `return` expression ... LL |     ) -> Assume {} |          ^^^^^^ expected `Assume`, found `()` error: aborting due to 5 previous errors For more information about this error, try `rustc --explain E0308`. </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<!-- 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:
<del> error[E0275]: overflow evaluating the requirement `<fn() -> Foo {foo} as FnOnce<()>>::Output == fn() -> Foo {foo}` </del> <ins> error[E0275]: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` </ins> --> $DIR/issue-53398-cyclic-types.rs:5:13 | LL | fn foo() -> Foo { |             ^^^ <ins> | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_53398_cyclic_types`) </ins> error: aborting due to previous error

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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- 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 --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
opt_body: Option<&hir::Body<'_>>, ) { let first_hir_id = hir_ids_and_spans[0].0; if let Some(name) = self.should_warn(var).filter(|name| name != "self") { // annoying: for parameters in funcs like `fn(x: i32) // {ret}`, there is only one node, so asking about

Discussion:
Consider the following file in a cargo package: Cargo will warn that is not used. Upon running , cargo will change the second parameter from to , making the compilation fail. Even worse, if contained a field then would change the variable without producing any warning. a new cargo binary project with the above snippet in (presumably with ) No response No response
just applies any  suggestion produced by . In this case, the suggestion from is to replace with . I went ahead and ran to see if it could help me understand what is going on better: ` (I cleaned up the expanded code slightly, but it is the same) Looking at the expanded code, it makes me think that is seeing in as the source of the problem since it expands to and is unused in this case. The normal suggestion is to add an underscore to so it would not be "unused". So suggests to change the being passed to the macro call as it does not understand that the warning is really coming from within the macro, not the call itself. It also could be suggesting this as is not valid rust (macro?) syntax. If you change your example slightly, correctly suggests the problem comes from within the macro call. To me, this seems like a problem with , but I do not know enough about the compiler internals to be 100% certain.
Transferred to rust-lang/rust, since the suggestions are generated by the compiler.
Yes, this issue comes from rustc. The lint is emitted from here Maybe we only point out that there is an unused variable coming from , but without the suggestion? I'm not sure what is a proper lint for this test case. any thoughts on it?
The quick and straightforward way to fix this would be to only emit the suggestion in this lint if the span has the root context, but then a subset of valid suggestions wouldn't be emitted. I had an older PR that I'm having trouble finding that would automatically do that for every diagnostic, but IIRC it had some negative perf impact when not implementing it very simplistic. In this we can probably instead check that all of the spans involved have the same . If they don't, don't suggest changes.
Change:
promotions } <ins> /// This function returns `true` if the function being called in the array /// repeat expression is a `const` function. crate fn is_const_fn_in_array_repeat_expression<'tcx>( ccx: &ConstCx<'_, 'tcx>, place: &Place<'tcx>, body: &Body<'tcx>, ) -> bool { match place.as_local() { // rule out cases such as: `let my_var = some_fn(); [my_var; N]` Some(local) if body.local_decls[local].is_user_variable() => return false, None => return false, _ => {} } for block in body.basic_blocks() { if let Some(Terminator { kind: TerminatorKind::Call { func, destination, .. }, .. }) = &block.terminator { if let Operand::Constant(box Constant { literal: ty::Const { ty, .. }, .. }) = func { if let ty::FnDef(def_id, _) = *ty.kind() { if let Some((destination_place, _)) = destination { if destination_place == place { if is_const_fn(ccx.tcx, def_id) { return true; } } } } } } } false } </ins>

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
<ins> pub trait Foo: Sized { const SIZE: usize; fn new(slice: &[u8; Foo::SIZE]) -> Self; //~^ ERROR: type annotations needed: cannot resolve `_: Foo` } pub struct Bar<T: ?Sized>(T); impl Bar<[u8]> { const SIZE: usize = 32; fn new(slice: &[u8; Self::SIZE]) -> Self { Foo(Box::new(*slice)) //~ ERROR: expected function, found trait `Foo` } } fn main() {} </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
"expect-test", "itertools 0.9.0", "minifier", <del> "pulldown-cmark 0.9.0", </del> <ins> "pulldown-cmark", </ins> "rayon", "regex", "rustdoc-json-types",

Discussion:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax
Change:
/// Free-form case. Only for errors that are never caught! Unsupported(String), <del> /// FIXME(#64506) Error used to work around accessing projections of /// uninhabited types. UninhabitedValue, </del> // -- Everything below is not categorized yet -- FunctionAbiMismatch(Abi, Abi), FunctionArgMismatch(Ty<'tcx>, Ty<'tcx>),

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
/// common in C++. /// /// [`as_mut_ptr`]: #method.as_mut_ptr <del> #[unstable(feature = "slice_ptr_range", issue = "65807")] </del> <ins> #[stable(feature = "slice_ptr_range", since = "1.48.0")] </ins> #[rustc_const_unstable(feature = "const_ptr_offset", issue = "71499")] #[inline] pub const fn as_mut_ptr_range(&mut self) -> Range<*mut T> {

Discussion:
Tracking issue for by See
Anything holding up stabilization on this? I'd like to be able to use this to check if two slices overlap, as pointers implement . It seems like a simple API that doesn't have a ton of complexity to it.
Note that with these functions can be made . The stabilization of these methods as can just be tracked as part of .
Thanks! PR: .
Change:
.stdout(::std::io::process::InheritFd(1)) .stderr(::std::io::process::InheritFd(2)); match cmd.status() { <del> Ok(_) => {}, </del> <ins> Ok(status) => { if !status.success() { sess.err(format!("linking of {} with `{}` failed", output_path.display(), cmd).as_slice()); sess.abort_if_errors(); } }, </ins> Err(e) => { sess.err(format!("could not exec the linker `{}`: {}", pname,

Discussion:
Tried to compile rustc on my Windows 7 x64 (MSYS2) when it crashed. Crashed even after running first. For the record, I tried to compile with set.
As of parallel codegen is enabled by default. Thus, the crash always occurs when compiling rustc. I was now able to get the full stack backtrace:
cc (looks like a duplicate codegen bug)
Actually we have two different problems here: ICE when linking fails on Windows. I've made an attempt to fix it in of fails with parallel codegen. I've created a new issue () to not confuse these two.
Change:
} } <del> Some(cx.enter_alias(args, def_id.to_def_id(), |cx| clean_ty(ty, cx))) </del> <ins> Some(cx.enter_alias(args, def_id.to_def_id(), |cx| clean_ty(&ty, cx))) </ins> } pub(crate) fn clean_ty<'tcx>(ty: &hir::Ty<'tcx>, cx: &mut DocContext<'tcx>) -> Type {

Discussion:
rustdoc renders renamed imports () using the new, private name (e.g., in ). This is confusing behavior since the new name is an implementation detail. I think it should be using the original item's name instead. As an example, returns a , but the module it's defined in renames to . I would expect rustdoc to still show the item's definition name, but instead it shows the private name.
I don't think this should be changed until is fixed. Otherwise you could have two items shown with the same name and namespace in the same scope.
Code to reproduce: I don't think we need to wait for to be fixed as the fix for this doesn't impact it: if the re-export is not publicly reexported, we simply show the item underneath. When we will it will handle it the same.
Change:
LL | LL |         let x = 5; |         ^^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL |         r#let x = 5; |         ^^^^^ </del> error[E0574]: expected struct, variant or union type, found macro `try` --> $DIR/try-block-in-edition2015.rs:4:33

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
main: &(dyn Fn() -> i32 + Sync + crate::panic::RefUnwindSafe), argc: isize, argv: *const *const u8, <del> ) -> isize { use crate::panic; use crate::sys_common; </del> <ins> ) -> Result<isize, !> { use crate::{mem, panic, sys, sys_common}; let rt_abort = move |e| { mem::forget(e); rtabort!("initialization or cleanup bug"); }; // Guard against the code called by this function from unwinding outside of the Rust-controlled // code, which is UB. This is a requirement imposed by a combination of how the // `#[lang="start"]` attribute is implemented as well as by the implementation of the panicking // mechanism itself. // // There are a couple of instances where unwinding can begin. First is inside of the // `rt::init`, `rt::cleanup` and similar functions controlled by libstd. In those instances a // panic is a libstd implementation bug. A quite likely one too, as there isn't any way to // prevent libstd from accidentally introducing a panic to these functions. Another is from // user code from `main` or, more nefariously, as described in e.g. issue #86030. </ins> // SAFETY: Only called once during runtime initialization. <del> unsafe { sys_common::rt::init(argc, argv) }; let exit_code = panic::catch_unwind(main); sys_common::rt::cleanup(); exit_code.unwrap_or(101) as isize </del> <ins> panic::catch_unwind(move || unsafe { sys_common::rt::init(argc, argv) }).map_err(rt_abort)?; let ret_code = panic::catch_unwind(move || panic::catch_unwind(main).unwrap_or(101) as isize) .map_err(move |e| { mem::forget(e); rtprintpanic!("drop of the panic payload panicked"); sys::abort_internal() }); panic::catch_unwind(sys_common::rt::cleanup).map_err(rt_abort)?; ret_code </ins> } #[cfg(not(test))]

Discussion:
See for an example of the problem. Here we panic without any landing pads available upstack, because we are already the top-most(-ish) frame in the first place. This is UB.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Playground link with full code:
FWIW, Miri does detect this. :)
Change:
// write Makefile-compatible dependency rules let files: Vec<String> = sess.codemap().files.borrow() .iter().filter(|fmap| fmap.is_real_file()) <del> .map(|fmap| fmap.name.to_string()) </del> <ins> .map(|fmap| escape_dep_filename(fmap.name.as_slice())) </ins> .collect(); let mut file = try!(io::File::create(&deps_filename)); for path in out_filenames.iter() {

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!