jiebi/CodeConvo huggingface dataset:
Change:
} }; <ins> // # Then compute the dynamic size // The full formula for the size would be: // let unsized_offset_adjusted = unsized_offset_unadjusted.align_to(unsized_align); // let full_size = (unsized_offset_adjusted + unsized_size).align_to(full_align); // However, `unsized_size` is a multiple of `unsized_align`. // Therefore, we can equivalently do the `align_to(unsized_align)` *after* adding `unsized_size`: // let full_size = (unsized_offset_unadjusted + unsized_size).align_to(unsized_align).align_to(full_align); // Furthermore, `align >= unsized_align`, and therefore we only need to do: // let full_size = (unsized_offset_unadjusted + unsized_size).align_to(full_align); let full_size = bx.add(unsized_offset_unadjusted, unsized_size); </ins> // Issue #27023: must add any necessary padding to `size` // (to make it a multiple of `align`) before returning it. //

Discussion:
Execute with Miri: The problem is that and do not take the reduced field alignment into account and calculate the offset as-if the standard alignment was in place.
The labels are incorrect. Neither does this require nightly, nor is it related to const-eval. This is I-unsound on stable.
label I-prioritize (Looks like can't set .)
Error: Label can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'const-eval' ' "I-unsoun'... Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .
label -I-prioritize +P-medium
labels -T-types Discussed in types team on-site -- we think this is a MIR building bug, in any case, not part of T-types. Throwing hot back to compiler team.
It was actually a bug in the codegen backend, introduced when support for was -- the existing code has logic that assumed "if it is packed then alignment is 1", and that was never re-visited.
Ah, scratch that -- there was a different related bug (the sizeofval / alignofval computation for packed structs with tail was wrong), caused by what I said above. This here was caused by the codegen backend just never considering packed types when computing the offset of the unsized field. Almost always this happened to work since the unsized field is a slice/str and so its alignment (and therefore its offset) is dynamically known, but when dyn trait tails are involved this starts to go wrong. This got fixed by ; will add a test.
Change:
}; } <del> fn should_abort_on_panic(tcx: TyCtxt<'_>, fn_def_id: DefId, abi: Abi) -> bool { // Not callable from C, so we can safely unwind through these if abi == Abi::Rust || abi == Abi::RustCall { return false; } // Validate `#[unwind]` syntax regardless of platform-specific panic strategy </del> <ins> fn should_abort_on_panic(tcx: TyCtxt<'_>, fn_def_id: DefId, _abi: Abi) -> bool { // Validate `#[unwind]` syntax regardless of platform-specific panic strategy. </ins> let attrs = &tcx.get_attrs(fn_def_id); let unwind_attr = attr::find_unwind_attr(Some(tcx.sess.diagnostic()), attrs); <del> // We never unwind, so it's not relevant to stop an unwind </del> <ins> // We never unwind, so it's not relevant to stop an unwind. </ins> if tcx.sess.panic_strategy() != PanicStrategy::Unwind { return false; } <del> // We cannot add landing pads, so don't add one </del> <ins> // We cannot add landing pads, so don't add one. </ins> if tcx.sess.no_landing_pads() { return false; } // This is a special case: some functions have a C abi but are meant to // unwind anyway. Don't stop them. match unwind_attr { <del> None => false, // FIXME(#58794) </del> <ins> None => false, // FIXME(#58794); should be `!(abi == Abi::Rust || abi == Abi::RustCall)` </ins> Some(UnwindAttr::Allowed) => false, Some(UnwindAttr::Aborts) => true, }

Discussion:
I would expect the following code to abort, and never print : But instead, the attribute . Cc
That looks like a bug. cc
is just , and having in the testcase may create the wrong impression (i.e. this bug has nothing to do with FFI). Still, the attribute should either work and cause an abort or error as unapplicable.
I deliberately made it explicit, but sure, I can adjust the example.
Agreed that this just looks like a bug that needs to be fixed.
Change:
<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // library portion of regression test for #87674 pub struct Foo<const N: usize>([(); N + 1]) where [(); N + 1]: ; // library portion of regression test for #87603 pub struct S<T: Copy + Default, const N: usize> where [T; N * 2]: Sized, { pub s: [T; N * 2], } impl<T: Default + Copy, const N: usize> S<T, N> where [T; N * 2]: Sized, { pub fn test() -> Self { S { s: [T::default(); N * 2] } } } </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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
} } <ins> debug!(?trait_sig, ?impl_sig, "equating function signatures"); let trait_fty = tcx.mk_fn_ptr(ty::Binder::dummy(trait_sig)); let impl_fty = tcx.mk_fn_ptr(ty::Binder::dummy(impl_sig)); </ins> // Unify the whole function signature. We need to do this to fully infer // the lifetimes of the return type, but do this after unifying just the // return types, since we want to avoid duplicating errors from // `compare_predicate_entailment`. <del> match infcx .at(&cause, param_env) .eq(tcx.mk_fn_ptr(ty::Binder::dummy(trait_sig)), tcx.mk_fn_ptr(ty::Binder::dummy(impl_sig))) { </del> <ins> match infcx.at(&cause, param_env).eq(trait_fty, impl_fty) { </ins> Ok(infer::InferOk { value: (), obligations }) => { ocx.register_obligations(obligations); } Err(terr) => { <del> let guar = tcx.sess.delay_span_bug( return_span, format!("could not unify `{trait_sig}` and `{impl_sig}`: {terr:?}"), </del> <ins> // This function gets called during `compare_predicate_entailment` when normalizing a // signature that contains RPITIT. When the method signatures don't match, we have to // emit an error now because `compare_predicate_entailment` will not report the error // when normalization fails. let emitted = report_trait_method_mismatch( tcx, &mut cause, infcx, terr, (trait_m, trait_fty), (impl_m, impl_fty), &trait_sig, &impl_trait_ref, </ins> ); <del> return Err(guar); </del> <ins> return Err(emitted); </ins> } }

Discussion:
Essentially, if my trait has and my impl has the compiler panics. Note that the code is invalid and compilation should fail. <!-- 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 I'm using which is experimental. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This happens for all type mismatches in the arguments (but not the arity!) A : <details<summaryWith the following backtrace: </summary</details
When not using a normal , the proper error is emitted here inside : But something gets messed up with the return position impl trait in trait desugaring that doesn't make this work (the arity check above does work). claim
Change:
"thin-local" => Ok(RustcLto::ThinLocal), "thin" => Ok(RustcLto::Thin), "fat" => Ok(RustcLto::Fat), <ins> "off" => Ok(RustcLto::Off), </ins> _ => Err(format!("Invalid value for rustc LTO: {}", s)), } }

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
let show_underline = !(parts.len() == 1 && parts[0].snippet.trim() == complete.trim()) && complete.lines().count() == 1; <del> let lines = sm.span_to_lines(parts[0].span).unwrap(); </del> <ins> let lines = sm .span_to_lines(parts[0].span) .expect("span_to_lines failed when emitting suggestion"); </ins> assert!(!lines.lines.is_empty());

Discussion:
(reduced sample courtesy of Output:
triage: diagnostics produced prior to ICE seem like they probably help user fix problem (maybe)? So calling this P-medium. Removing nomination label.
Change:
// alive, and using ty::get is unsafe when the ctxt is no longer alive. enum t_opaque {} <ins> #[allow(raw_pointer_deriving)] </ins> #[deriving(Clone, Eq, TotalEq, Hash)] pub struct t { priv inner: *t_opaque }

Discussion:
In the following, the does the wrong thing: it shallow copies the pointer when the semantics mean it should be making a new allocation and copying the data; there's no indication of this until runtime double-frees/segfaults. Some possible resolutions: do nothing: unsafe code is unsafe have lints for + unsafe pointers have completely disabled on unsafe pointers remove the trait impls for raw pointers
I favor a lint.
(I'm happy to mentor this.)
I'm interested in doing this. I'll find on IRC.
Change:
<del> // Copyright 2015 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. // error-pattern:thread 'main' panicked at 'attempt to multiply with overflow' // compile-flags: -C debug-assertions fn main() { let _x = 2i32.pow(1024); } </del>

Discussion:
Today I learned that eight to the power of eight is zero. Who'da thunk? Incorrect: :arrowright: :x: :arrowright: :x: :arrowright: :x: Correct: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: :arrowright: overflow :whitecheckmark: Oddly enough, this one breaks the pattern: :arrowright: overflow :whitecheck_mark: Haven't bothered with further cases; at this point it's probably best to just look at the implementation and see what's going on.
was supposed to fix this; looks like it missed the unsigned version?
says that is on nightly.
I meant that fixed this for pow() on signed integers, but not on unsigned integers; it looks like the implementation is copy-pasted for some reason.
Could I take a stab at this?
Sure; feel free to ask if you have questions.
Is overflow checking off in the libcore tests? It'd be nice to be able to write some standard tests for overflow, but they seem to not panic even on cases that should right now.
Overflow checking in unit tests () reflects whether the whole compiler was built in debug or release mode. If you need to specify the overflow mode, you can use a separate test which explicitly specifies , like .
This has since been fixed, in , which it looks like also a test, so closing.
Change:
}) .enumerate() .map(|(i, r)| match r { <del> Err(TypeError::Sorts(exp_found)) => Err(TypeError::ArgumentSorts(exp_found, i)), Err(TypeError::Mutability) => Err(TypeError::ArgumentMutability(i)), </del> <ins> Err(TypeError::Sorts(exp_found) | TypeError::ArgumentSorts(exp_found, _)) => { Err(TypeError::ArgumentSorts(exp_found, i)) } Err(TypeError::Mutability | TypeError::ArgumentMutability(_)) => { Err(TypeError::ArgumentMutability(i)) } </ins> r => r, }); Ok(ty::FnSig {

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. --: Also get this using stable: You can see it on the playground: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can reproduce even without the type aliases: Edit: even smaller reproducer: Produces this output: () :
After some testing, this can be reproduced since 1.53, might have been introduced in
Change:
if let Some(NonRecursive) = TriColorDepthFirstSearch::new(&body).run_from_start(&mut vis) { return; } <ins> if vis.reachable_recursive_calls.is_empty() { return; } </ins> vis.reachable_recursive_calls.sort();

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. --I tried this code which causes a stack overflow due to a recursive call of I mistakenly . I expected to see the warning. However, the compiler didn't complain it. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.43.0 showed the warning. (ref. ) The warning isn't shown on 1.44.0 or later, including the current stable 1.47.0. <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- 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 --
I think this was caused by , but it looks like expected behavior: If diverges, the self-recursion never happens.
Though maybe the lint should assume that functions returning an inhabited type won't diverge (since otherwise they should be marked ). I can definitely see why people would write code like this, so linting on it makes sense.
I personally feel that we should lint for functions if they don't return an uninhabited type. Even if someone wants to exit recursion by unwinding I do feel that a lint is still appropriate here as it is really bad style imo.
Thanks for the quick response. Yeah, it'd be natural to expect a function whose return type is not to return eventually. Probably, we might want to have the following rules?: for self-recursion unless a function returning an uninhabited type is called in advance. a non-diverge function is called before a self-recursion, show a message like "if this diverges, please annotate it." in addition to the warning. 1 would help my case and 2 would help the case of . (2 is not necessary, though.)
Assigning as and removing .
Change:
self.check_unused_parens_expr(cx, &value, msg, followed_by_block); } <del> fn check_pat(&mut self, cx: &EarlyContext<'_>, p: &ast::Pat, _: &mut bool) { </del> <ins> fn check_pat(&mut self, cx: &EarlyContext<'_>, p: &ast::Pat) { </ins> use ast::PatKind::{Paren, Range}; // The lint visitor will visit each subpattern of `p`. We do not want to lint any range // pattern no matter where it occurs in the pattern. For something like `&(a..=b)`, there

Discussion:
The parameter is a hack (to fix ) that should be refactored. The idea is that the state should be contained in instead. This should be straightforward to fix. the parameter from (You'll also need to update the signature of in . a method with an identical signature below it. the condition from an early lint pass for at the end. a field to in (Look at for an example of a lint with fields.) You'll also need to initialise it with here: should be replaced with an assignment of the new field in to : should be early-exited if the field is . a implementation to and reset the field to if the pattern ID matches the field ID. sure the UI tests still pass with no changes.
hi I'm happy to take care of this one if it's not taken already.
go ahead! Let me know if you have any questions or problems with the implementation! :)
Change:
<ins> // check-pass #![feature(trait_alias)] struct MyStruct {} trait MyFn = Fn(&MyStruct); fn foo(_: impl MyFn) {} fn main() { foo(|_| {}); } </ins>

Discussion:
This code produce compiling error: () Errors: But when non aliased trait used, then no error occured. That is when we replace with
May be "F-trait_alias" label needed for this issue.
Fixed on latest nightly 2023-01-15. label: +F-trait_alias +E-needs-test
Change:
<ins> // check-pass trait A { type Foo; } impl<T> A for T { type Foo = (); } fn foo() -> impl std::borrow::Borrow<<u8 as A>::Foo> { () } fn main() { foo(); } </ins>

Discussion:
Using the syntax does not work as a generic to an impl Trait in return position. Error As a parameter it does work: This issue looks related, but specifically calls out type equality constraints.
cc is this a lazy-norm issue?
This was fixed by , which includes tests, so maybe this should just be closed?
Closing per comment
Change:
} fn check_ty(&mut self, cx: &EarlyContext<'_>, ty: &ast::Ty) { <ins> if let ast::TyKind::Paren(_) = ty.kind && Some(&ty.id) == self.parens_in_cast_in_lt.last() { return; } </ins> match &ty.kind { ast::TyKind::Array(_, len) => { self.check_unused_delims_expr(

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: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- 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. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
std::mem::take(&mut self.inner.borrow_mut().region_obligations) } <ins> /// NOTE: Prefer using [`InferCtxt::check_region_obligations_and_report_errors`] /// instead of calling this directly. /// </ins> /// Process the region obligations that must be proven (during /// `regionck`) for the given `body_id`, given information about /// the region bounds in scope and so forth. This function must be

Discussion:
into causes an internal compiler panic This causes an internal compiler error: This seems related to , except this is using
:
This is not specific to . The following produces the same kind of error.
modify labels: +regression-from-stable-to-stable The ICE happens on stable regardless of having the feature gate or not (the ICE does not requires a nightly compiler to reproduce)
Change:
// figure out which generic parameter it corresponds to and return // the relevant type. let generics = match path.res { <del> Res::Def(DefKind::Ctor(..), def_id) => { </del> <ins> Res::Def(DefKind::Ctor(..), def_id) | Res::Def(DefKind::AssocTy, def_id) => { </ins> tcx.generics_of(tcx.parent(def_id).unwrap()) } Res::Def(_, def_id) => tcx.generics_of(def_id), <del> Res::Err => return tcx.types.err, </del> res => { tcx.sess.delay_span_bug( DUMMY_SP, <del> &format!("unexpected const parent path def {:?}", res,), </del> <ins> &format!( "unexpected const parent path def, parent: {:?}, def: {:?}", parent_node, res ), </ins> ); return tcx.types.err; }

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. --I was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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 updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.