jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-pass // The actual regression test from #63479. (Including this because my // first draft at fn-ptr-is-structurally-matchable.rs failed to actually // cover the case this hit; I've since expanded it accordingly, but the // experience left me wary of leaving this regression test out.) #[derive(Eq)] struct A { a: i64 } impl PartialEq for A { #[inline] fn eq(&self, other: &Self) -> bool { self.a.eq(&other.a) } } type Fn = fn(&[A]); fn my_fn(_args: &[A]) { println!("hello world"); } const TEST: Fn = my_fn; struct B(Fn); fn main() { let s = B(my_fn); match s { B(TEST) => println!("matched"), _ => panic!("didn't match") }; } </ins>

Discussion:
A contrived example: This code will build on stable and beta, but not on nightly. It looks like it's related to possibly?
Compiler team triage: Definitely related to . Going to assign to for follow-up, although they are on leave until early September. It seems like this falls in a grey area: it was being accepted due to bugs in the existing code-base, however it is also a case that we likely could accept regardless of what rules we ultimately adopted. (Because the constant itself is a fn pointer.) is this regression affecting a real project?
I would say this is definitely a bug and the old behavior was correct: we're comparing function pointers so it shouldn't matter whether params derive or implement PartialEq, since no concrete parameter will be compared, but the functions themselves. Real projects being affected: I spotted the regression when updating my erlang VM implementation to latest nightly (and latest tokyo async/await): I define an Export as an enum that can either be a native function or an erlang function: Then in the instruction engine I cheat and override some of the exports to define them as a instruction (for example apply/2, apply/3 both need to modify the flow to jump to a different instruction): First I define a constant pointing to the function I want to override: Then I match on it and override: So the reason the code fails here is because is defined as , and has some custom code defined for . It's a bit of a hack, but this is more or less how erlang itself implements these specific instructions.
Reduced:
Changing to a raw pointer makes it compile successfully:
check-in from compiler triage: is back next week. A few weeks back, reported a real project affected by this regression (sorry!). As I wrote last week, from a lang-team perspective this falls into a grey zone, though I personally am inclined to try and accept the code, both for backwards compat reasons and because I don't think there's a compelling reason not to (though that depends on what complications result, I suppose). Overall, we need to settle our "constants in match patterns" story.
I'm going to leave this one nominated to bring it to felix's attention.
For the time being I've worked around the problem by taking the function pointers, casting them to usize then comparing that:
triage: P-high. Assigning to self.

Lets see if I can come up with something to fix this before this regression leaks out to stable.
(okay, after looking at the code, I think this should be pretty easy to fix and backport.)
Change:
/// previous state (if any). pub fn reset_headers() { USED_HEADER_MAP.with(|s| s.borrow_mut().clear()); <del> TEST_IDX.with(|s| s.set(0)); </del> } impl<'a> fmt::String for Markdown<'a> {

Discussion:
For example, the code snippet for with suspicious muffin-related content. This seems to be the snippet for the  function (which is also the first function on the page with example code). All other code snippets on the page lead to the same muffin code. This is on Chrome 39.0.2171.95 (64-bit) on Mac OS X 10.10.1. !
It looks like this is caused by rustdoc rendering all of the examples with the same id. If you look at the playpen js code in rustdoc: you see that it depends on all the same ids being different. However, if you look at the source of the StrExt example you linked, you see they all have "rust-example-rendered-0" as the id. I think the error comes from somewhere in here, but it's not obvious to me how to fix it. I'll look into the issue, but this is my first little bit of work on rust so it may take a second/I'd appreciate insight as to what the problem might be.
nominating for I-muffins
Change:
<ins> error: unused return value of `f` that must be used --> $DIR/decorate-can-emit-warnings.rs:9:5 | LL |     f(); |     ^^^ | = note: requested on the command line with `-D unused-must-use` help: use `let _ = ...` to ignore the resulting value | LL |     let _ = f(); |     +++++++ error: aborting due to 1 previous error </ins>

Discussion:
Input:
Bisects to Rust 1.55.0, and nightly-2021-07-20. In older stable and nightly releases, this compiles successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection points to rollup If I had to guess, I'd say that looks like the one. It's the only one in the rollup touching diagnostic code. Possibly my reasoning is off (pls correct me).
Something went wrong with your bisect, as is from 2022-02-02, whereas this ICE is present in nightly-2021-07-20. looks the most likely to me.
Either way, this is probably easier to debug from scratch instead of digging around commits. Previous issue with this ICE message should reveal information on how to fix these issues, which arise from eagerly formatting paths in lints instead of only when they're emitted.
Fix for a similar issue :
Change:
bv.to_string(ccx)).as_slice()); } <del> let bound_data = GEPi(bcx, llbox, &[0u, abi::box_field_body, i]); </del> <ins> let bound_data = GEPi(bcx, llbox, &[0u, abi::BOX_FIELD_BODY, i]); </ins> match bv.action { ast::CaptureByValue => {

Discussion:
There are three versions of these layouts for functions, traits, and slices, but the compiler relies on these being the same. We should replace them with a single layout: and or something. While we're at it, we should probably find uses of len/length names in the DST code and replace it with something more generic.
I merged the constants. Could you elaborate on the length names? Are there more constants like these?
What still needs to be done here, if anything?
Looks done.
Change:
let lltypes = map::mk_hashmap::<ty::t, TypeRef>(hasher, eqer); let sha1s = map::mk_hashmap::<ty::t, str>(hasher, eqer); let short_names = map::mk_hashmap::<ty::t, str>(hasher, eqer); <del> let sha = std::sha1::mk_sha1(); let link_meta = link::build_link_meta(sess, *crate, output, sha); </del> let crate_map = decl_crate_map(sess, link_meta.name, llmod); let ccx = @{sess: sess,

Discussion:
For compatibility with clang and for debugging convenience, should disassemble the bitcode.
Change:
Target::Field | Target::Arm | Target::MacroDef => { self.inline_attr_str_error_with_macro_def(hir_id, attr, "no_mangle"); } <ins> // FIXME: #[no_mangle] was previously allowed on non-functions/statics, this should be an error // The error should specify that the item that is wrong is specifically a *foreign* fn/static // otherwise the error seems odd Target::ForeignFn | Target::ForeignStatic => { let foreign_item_kind = match target { Target::ForeignFn => "function", Target::ForeignStatic => "static", _ => unreachable!(), }; self.tcx.struct_span_lint_hir(UNUSED_ATTRIBUTES, hir_id, attr.span, |lint| { lint.build(&format!( "`#[no_mangle]` has no effect on a foreign {}", foreign_item_kind )) .warn( "this was previously accepted by the compiler but is  being phased out; it will become a hard error in  a future release!", ) .span_label(*span, format!("foreign {}", foreign_item_kind)) .note("symbol names in extern blocks are not mangled") .span_suggestion( attr.span, "remove this attribute", String::new(), Applicability::MachineApplicable, ) .emit(); }); } </ins> _ => { // FIXME: #[no_mangle] was previously allowed on non-functions/statics and some // crates used this, so only emit a warning.

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: I expected to see this happen: no warning. Instead, this happened: ~The attribute is actually applied correctly, otherwise we would get undefined symbol error.~ Also, the extern variable is clearly declared as static, so the warning does not really make sense. Edit: it seems that the code also works without the attribute. So is the attribute actually not needed? Anyway, the warning about is confusing. This problem occurred in our embedded project , where the static global variables are used to provide references to linker symbols. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.47 stable. Haven't tried newer nightly. : modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
No, this is working correctly. does nothing on extern items, which already do not get mangled, even without the attribute.
OK, sorry for not understanding the behavior of on extern items.
So maybe this should not be marked as regression, this is just a confusing but indeed correct warning message. Is there a way to remove the labels?
claim
Change:
<ins> enum MyEnum { Tuple(i32), Struct{ s: i32 }, } fn foo(en: MyEnum) { match en { MyEnum::Tuple => "", //~^ ERROR expected unit struct/variant or constant, found tuple variant `MyEnum::Tuple` MyEnum::Struct => "", //~^ ERROR expected unit struct/variant or constant, found struct variant `MyEnum::Struct` }; } fn main() {} </ins>

Discussion:
Code Example (): <img width="805" alt="image" src="https://user-"Currently we provide a "do you mean..." for the but not for the . We probably should provide one for both.
Consider fixing Btw (which is a similar enhancement)
I'd like to work on this if it is still available.
go ahead! Ideally, you could turn the output into but just changing the tuple case would be enough.
I created a PR, could you please help review. I took a look at your suggestion of updating all the errors to , that seemed too many changes, not sure if it was necessary, so I just the tuple case.
Change:
err_ub!(InvalidFunctionPointer(..)) | err_unsup!(ReadBytesAsPointer) => { "invalid drop function pointer in vtable (not pointing to a function)" }, <del> err_ub!(InvalidDropFn(..)) => </del> <ins> err_ub!(InvalidVtableDropFn(..)) => </ins> { "invalid drop function pointer in vtable (function has incompatible signature)" }, ); try_validation!( self.ecx.read_size_and_align_from_vtable(vtable), self.path, <ins> err_ub!(InvalidVtableSize) => { "invalid vtable: size is bigger than largest supported object" }, err_ub!(InvalidVtableAlignment(msg)) => { "invalid vtable: alignment {}", msg }, </ins> err_unsup!(ReadPointerAsBytes) => { "invalid size or align in vtable" }, ); // FIXME: More checks for the vtable.

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
use syntax::ast::FloatTy; let layout = self.layout_of(ty)?; <del> // do the strongest layout check of the two let align = layout.align.max(ptr_align); self.memory.check_align(ptr, align)?; </del> <ins> self.memory.check_align(ptr, ptr_align)?; </ins> if layout.size.bytes() == 0 { return Ok(Some(Value::ByVal(PrimVal::Undef)));

Discussion:
I recently updated my nightly toolchain for rust, and compiled a project I was working on. Previously I was on the version, and updated to the version. I encountered a compiler error when dealing with statements and Associated Constants, centered around alignment issues of the associated constant. After some testing, I managed to create a simple example with the code below: : : I've also tested and encountered this error on the following versions: nightly-2018-04-27-x8664-pc-windows-msvc nightly-2018-04-28-x8664-pc-windows-msvc nightly-2018-04-29-x8664-pc-windows-msvc nightly-2018-04-30-x8664-pc-windows-msvc
Sounds like some alignment check is getting the alignment from the wrong side of an assignment. I hope it wasn't introduced in a beta backported bugfix, we need to check that.
Ok, It's just in nightly, not in beta! I'll try to bisect
Change:
} else if is_assign == IsAssign::Yes && let Some(lhs_deref_ty) = self.deref_once_mutably_for_diagnostic(lhs_ty) { <del> suggest_deref_binop(lhs_deref_ty); </del> <ins> suggest_deref_binop(&mut err, lhs_deref_ty); </ins> } else if is_assign == IsAssign::No <del> && let Ref(_, lhs_deref_ty, _) = lhs_ty.kind() </del> <ins> && let Ref(region, lhs_deref_ty, mutbl) = lhs_ty.kind() </ins> { if self.type_is_copy_modulo_regions( self.param_env, *lhs_deref_ty, ) { <del> suggest_deref_binop(*lhs_deref_ty); </del> <ins> suggest_deref_binop(&mut err, *lhs_deref_ty); } else { let lhs_inv_mutbl = mutbl.invert(); let lhs_inv_mutbl_ty = Ty::new_ref( self.tcx, *region, ty::TypeAndMut { ty: *lhs_deref_ty, mutbl: lhs_inv_mutbl, }, ); suggest_different_borrow( &mut err, lhs_inv_mutbl_ty, Some(lhs_inv_mutbl), rhs_ty, None, ); if let Ref(region, rhs_deref_ty, mutbl) = rhs_ty.kind() { let rhs_inv_mutbl = mutbl.invert(); let rhs_inv_mutbl_ty = Ty::new_ref( self.tcx, *region, ty::TypeAndMut { ty: *rhs_deref_ty, mutbl: rhs_inv_mutbl, }, ); suggest_different_borrow( &mut err, lhs_ty, None, rhs_inv_mutbl_ty, Some(rhs_inv_mutbl), ); suggest_different_borrow( &mut err, lhs_inv_mutbl_ty, Some(lhs_inv_mutbl), rhs_inv_mutbl_ty, Some(rhs_inv_mutbl), ); } </ins> } } else if self.suggest_fn_call(&mut err, lhs_expr, lhs_ty, |lhs_ty| { is_compatible_after_call(lhs_ty, rhs_ty)

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
<ins> //@ check-pass //@ edition:2018 #![warn(unused_imports)] mod foo { macro_rules! foo1 { () => (); } pub(crate) use foo1; } fn main () { bar!(); macro_rules! bar { () => (); } use bar; mod m { bar1!(); macro_rules! bar1 { () => (); } use bar1; } { foo::foo1!(); } { use foo::foo1; foo1!(); } { use foo::foo1; //~ WARNING unused import: `foo::foo1` foo::foo1!(); } } </ins>

Discussion:
This (very contrived) example emits a warning: Playground: This is a false positive because removing results in a compilation error: Same for and .
It seems this regressed somewhere between 1.34.0 and 1.35.0
More accurately, it looks like the false positive has been present since the introduction of the warning in
I was actually a little surprised that did not cause a compilation error due to two imports of the same name at the same level.
I got something similar while implementing ops::Div when removed, it errors
This issue no longer reproduces and can be closed when a corresponding test is .
Change:
"serde_derive", "serde_json", "tempfile", <del> "tester 0.7.0", </del> <ins> "tester", </ins> "winapi 0.3.8", ]

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium, removing nomination label.
Change:
let x = ManuallyDrop::new(TypeWithDrop); drop(x); <ins> // also test unsizing let x : Box<ManuallyDrop<[TypeWithDrop]>> = Box::new(ManuallyDrop::new([TypeWithDrop, TypeWithDrop])); drop(x); </ins> }

Discussion:
currently requires . It would be nice if we could remove this restriction. I'm not sure how to do it with the current implementation using though.
Doesn't seem possible until we get by-value DSTs
care to explain why?
Ah, nevermind. It would just need to make unsized, too.
The and methods can keep could keep their bounds, we just need to relax the bound on the struct itself, and make sure . Then the following code would be possible:
I guess this would be possible by allowing types to be when there is only one variant. I was worried that would be unsound, but then I realized, the only way to create a DST type would be from an unsize coercion, and then way you know what the erased type is and can get the vtable/slice length then, just like any other unsize coercion.
See
Change:
#![allow(internal_features)] #![allow(rustc::diagnostic_outside_of_impl)] #![allow(rustc::untranslatable_diagnostic)] <ins> #![feature(assert_matches)] </ins> #![feature(associated_type_bounds)] #![feature(box_patterns)] #![feature(control_flow_enum)]

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. --issue appeared when going from 1 -2, was able to fix it by adding 3 <!-- 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
I've only skimmed the code but this is very likely due to the diagnostic method constructing a projection, more precisely an , with created for the trait item, not the associated type (with (pseudo) ), so we're missing the own generic arguments for the GAT.
Change:
impl<I: DoubleEndedIterator, U, F> DoubleEndedIterator for FlatMap<I, U, F> where F: FnMut(I::Item) -> U, <del> U: IntoIterator, U::IntoIter: DoubleEndedIterator, </del> <ins> U: IntoIterator<IntoIter: DoubleEndedIterator>, </ins> { #[inline] fn next_back(&mut self) -> Option<U::Item> { self.inner.next_back() }

Discussion:
Follow up of . These two particular cases could not be refactored due to an ambiguity issue: With Result (line numbers are off): With Result (line numbers are off): cc
cc also
Thanks for this report. If you/Centril/someone could produce a MCVE, I would then be happy to investigate further... right now I don't have the time to reduce it though, I'm afraid.
I tried again for an hour or two without success. Unfortunately I don't know enough about the internals to understand how this could happen. I'll look at the associated type bounds PR, maybe that will help.
This is odd; I basically pasted the code in verbatim into the , made it compile, and the made the tweaks above. The issue still won't reproduce but it does reproduce when I . Maybe this is a bootstrapping issue... in which case we'll know in a few hours.
Change:
gated_spans: GatedSpans::default(), symbol_gallery: SymbolGallery::default(), reached_eof: Lock::new(false), <ins> env_depinfo: Default::default(), </ins> } }

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
use rustc::ty::util::Discr; use rustc::ty::util::IntTypeExt; use rustc::ty::subst::UnpackedKind; <del> use rustc::ty::{self, AdtKind, ToPolyTraitRef, Ty, TyCtxt}; </del> <ins> use rustc::ty::{self, AdtKind, DefIdTree, ToPolyTraitRef, Ty, TyCtxt}; </ins> use rustc::ty::{ReprOptions, ToPredicate}; use rustc::util::captures::Captures; use rustc::util::nodemap::FxHashMap;

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
<del> include ../../run-make-fulldeps/tools.mk </del> <ins> # ignore-none no-std is not supported # ignore-nvptx64-nvidia-cuda FIXME: can't find crate for `std` </ins> <del> # FIXME https://github.com/rust-lang/rust/issues/78911 # ignore-32bit wrong/no cross compiler and sometimes we pass wrong gcc args (-m64) </del> <ins> include ../../run-make-fulldeps/tools.mk </ins> # Tests that we don't ICE during incremental compilation after modifying a # function span such that its previous end line exceeds the number of lines

Discussion:
Some run-make tests require an directive as a workaround for link failures that occur during CI. and or modified tests to include this directive in order to avoid at least this error: . I assume that this shouldn't be necessary, and that there is actually some deficiency in our CI build system that we can fix.
Never mind, it may not be related. Sorry for the noise.