jiebi/CodeConvo huggingface dataset:
Change:
param, if impl_trait { " +" } else { ":" }, self.tcx.def_path_str(t.def_id), <del> if has_bounds { " +"} else { "" }, </del> <ins> if has_bounds.is_some() { " + " } else { "" }, </ins> )), Applicability::MaybeIncorrect, );

Discussion:
Missing a trait bound for the trait that defines below: Results in the following suggestion with an extra colon after the plus.
you can look at and for inspiration on how to deal with this.
I came up with a different solution, but there may be a subtlety I'm missing:
Change:
(PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { use std::cmp::Ordering; <del> match (end, compare_const_vals(&lo.val, &hi.val, ty).unwrap()) { </del> <ins> match (end, compare_const_vals(self.tcx, &lo.val, &hi.val, ty).unwrap()) { </ins> (RangeEnd::Excluded, Ordering::Less) => PatternKind::Range { lo, hi, end }, (RangeEnd::Excluded, _) => {

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
let suggestion = default_variants .iter() .filter_map(|v| { <del> if v.ident == variant.ident { </del> <ins> if v.span == variant.span { </ins> None } else { Some((cx.sess.find_by_name(&v.attrs, kw::Default)?.span, String::new()))

Discussion:
Found with a thread 'rustc' panicked at 'assertion failed: !suggestion.isempty()', <details<summaryBacktrace</summary</detailsFirst ICEd in nightly-2021-07-29, likely from ( which support for enums. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
PR is up at
Change:
let ebml_w = &EBWriter::Serializer(wr); a1.serialize(ebml_w) }; <del> let d = EBReader::Doc(@bytes); </del> <ins> let d = EBReader::Doc(@move bytes); </ins> let a2: A = deserialize(&EBReader::Deserializer(d)); assert *a1 == a2; }

Discussion:
cc Maybe related to
Also affects eclectica-0.0.9 cc
Also igo-0.2.1 cc
Also isbfc-0.0.1 cc
Also cargo-update-0.8.0 () cc
Also cc
Rust commit: (looks like bug isn't here) Cargo commit: , which seems correct. is the stable/nightly issue, is the PR updating cargo submodule to fix this, which probably needs to be backported to beta. I'm uncertain, though.
cc sorry to tag you in again, but if you could help take a look at this that'd be great! If not no worries!
Hi this definitely looks related to my changes in cargo. I've investigated and this crate defines two bins ( and ). I suppose they were intended to be aliases and this was possible because of a original "bug" in cargo (falling back to ). I have mixed feelings about this. I would say that cargo should fail here instead of falling back to , but I suppose we cannot do that because of backwards compatibility. Right? fails because it defines bin targets inside directly, instead of . Seems easy and I'll try to fix this today in the evening. Could you please provide me with the cargo's output for the other crates (especially )? That would be great.
Ah yeah for now our priority is to stem the breakage, and afterwards we can evaluate warnings cycles/etc to push further towards the desired behavior here. Thanks for investigating this
I think I have fixed this, just need one more day to do some more testing and I should open a pull request tomorrow.
Added a proposed fix.
Ah we should actually leave this open to track the inclusion into beta, I'll close when all the backports are done.
Ok I've , updated our and updated our , this'll get closed when those start merging. Thanks again for fixing this
Ok, I think everything's landed here
Change:
fn main() { format!(); //~ ERROR requires at least a format string argument format!("" 1); //~ ERROR expected token: `,` <del> format!("", 1 1); //~ ERROR expected token: `,` </del> <ins> format!("", 1 1); //~ ERROR expected one of </ins> }

Discussion:
See The macro claims that it expects when failing to parse a format string argument, but it actually accepts all tokens that make up expressions in that position. The simplest fix would be to use , but that causes parsing errors directly after the format string to claim that expression tokens are expected in that position are accepted, when they are not. In other words, it would be nice to get diagnostics like this: while avoiding getting diagnostics like this:
Change:
}; // Use borrowck to get the type with unerased regions. <del> let concrete_opaque_types = &self.tcx.mir_borrowck(item_def_id).concrete_opaque_types; debug!(?concrete_opaque_types); if let Some(&concrete_type) = concrete_opaque_types.get(&self.def_id) { </del> <ins> let borrowck_results = &self.tcx.mir_borrowck(item_def_id); // If the body was tainted, then assume the opaque may have been constrained and just set it to error. if let Some(guar) = borrowck_results.tainted_by_errors { self.found = Some(ty::OpaqueHiddenType { span: DUMMY_SP, ty: Ty::new_error(self.tcx, guar) }); return; } debug!(?borrowck_results.concrete_opaque_types); if let Some(&concrete_type) = borrowck_results.concrete_opaque_types.get(&self.def_id) { </ins> debug!(?concrete_type, "found constraint"); if let Some(prev) = &mut self.found { if concrete_type.ty != prev.ty && !(concrete_type, prev.ty).references_error() {

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 (): Somehow in the second case we think that is unconstrained even though it doesn't seem to contain more or less type information than the first case. Note also that this does not error if I use RPIT instead.
I think in the second example mir building doesn't generate code for the trailing expression because it's statically known as dead code. But I thought we were keeping around the typeck types nowadays, and typeck should be the same for both functions
I don't think that's it, same error if I put the match in a branch ():
In fact this doesn't need an empty type at all:
I think we're generating bogus MIR or THIR because of that empty match -- Are you sure the bug doesn't exist on the THIR/MIR building side, (hacked to dump the instead of )
Oh I'm sure of nothing I just assumed an unreachable in a branch would not affect anything else
So: If there's a match error, we end up constructing a failure MIR body. This will prevent us from inferring the opaque later on. edit: that last sentence was a lie Let me see if I can cook up a quick fix.
Change:
} } else { // If `ctxt.coerce` is `None`, we can just ignore <del> // the type of the expresison.  This is because </del> <ins> // the type of the expression.  This is because </ins> // either this was a break *without* a value, in // which case it is always a legal type (`()`), or // else an error would have been flagged by the

Discussion:
I tried to compile some massive project and the rust compiler unexpectedly panicked. Luckily, I have managed to replicate the error in a small, reproducible example (still panics on rust playground online, 11 lines of code): I expected a regular error without a panic, but the compiler simply halted. Output of RUSTBACKTRACE=1 rustc -o -C debuginfo=2: Output of :
Maximal reduction: This didn't ICE in 1.37.0 (checked with godbolt).
triage: P-medium (based on assumption that one will always see something like that error message, with its span, before the ICE). Assigning to self for now (but I welcome others who would like to work-steal it). Removing nomination label.
assigning to as well based on insight that this ICE may be arising from diagnostics.
I believe I have a fix. I'll post it after lunch. Edit: faster than I thought.
Change:
fn check_pat(a: &ast::Pat); fn check_pat_post(a: &ast::Pat); fn check_expr(a: &ast::Expr); <ins> fn check_expr_post(a: &ast::Expr); </ins> fn check_ty(a: &ast::Ty); fn check_generic_arg(a: &ast::GenericArg); fn check_generic_param(a: &ast::GenericParam);

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:
<ins> // Copyright 2016 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. // Make sure that the spans of import errors are correct. use abc::one_el; //~^ ERROR 13:5: 13:16 use abc::{a, bbb, cccccc}; //~^ ERROR 15:11: 15:12 //~^^ ERROR 15:14: 15:17 //~^^^ ERROR 15:19: 15:25 use a_very_long_name::{el, el2}; //~^ ERROR 19:24: 19:26 //~^^ ERROR 19:28: 19:31 fn main() {} </ins>

Discussion:
an arbitrary import of the shape will give the following errors and spans: The span is always as long as the crate, but starts at the imported element This can also be used to create an unprintable span:
Change:
// CHECK-LABEL: @borrow #[no_mangle] pub fn borrow(x: &i32) -> &i32 { <del> // CHECK: load i32*, i32** %x{{.*}}, !nonnull </del> <ins> // CHECK: load {{(i32*, )?}}i32** %x{{.*}}, !nonnull </ins> x } // CHECK-LABEL: @_box #[no_mangle] pub fn _box(x: Box<i32>) -> i32 { <del> // CHECK: load i32*, i32** %x{{.*}}, !nonnull </del> <ins> // CHECK: load {{(i32*, )?}}i32** %x{{.*}}, !nonnull </ins> *x }

Discussion:
Hrm, yeah, the IR format changed from 3.6 to 3.7. In this case, it's just the extra result type in the instructions. Making that optional by changing to something like should help with that. If you still have a build using LLVM 3.6 around, it'd be great if you could create a patch for this. If not, let me know and I'll create one this evening.
I will give it a try. I am not planning to switch to 3.7 right now as there is no official release yet.
This is fixed.
Change:
.anchor { display: none; position: absolute; <del> left: -25px; </del> <ins> left: -5px; </ins> } .anchor.field { <del> left: -20px; </del> <ins> left: -5px; </ins> } .anchor:before { content: '200200a72002';

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
<ins> warning: unused variable: `bar` --> $DIR/try-removing-the-field.rs:12:20 | LL |     let Foo { foo, bar, .. } = x; |                    ^^^- |                    | |                    help: try removing the field | = note: `#[warn(unused_variables)]` on by default warning: 1 warning emitted </ins>

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
#[rustc_const_unstable(feature = "const_type_id", issue = "77125")] pub const fn of<T: ?Sized + 'static>() -> TypeId { let t: u128 = intrinsics::type_id::<T>(); <del> TypeId { t } </del> <ins> let t1 = (t >> 64) as u64; let t2 = t as u64; TypeId { t: (t1, t2) } </ins> } }

Discussion:
On Apple Silicon (unlike x8664) is 16-bytes aligned. So it takes extra space with little or no benefit. I looked at generated code, it is the same: (Note just using won't work because it will pass by reference not by value) Additionally the issue with current is that is has different alignment on different platforms. Rust does not provide guarantees about the alignment, but if this was the same everywhere, it'd make life easier. (Practically we encountered this issue when our CI worked fine on Apple x8664 macs, but the program didn't work on Apple Silicon.) rustc 1.74.0-nightly ( 2023-09-05) macOS, Apple Silicon
Note that doesn't have the same alignment on all platforms either. It will be 4-aligned on (some) 32bit platforms.
I might be wrong here, but seems to work, so I believe is . So can't said problem be eliminated by implementing on as well?
already implements . Also does not affect alignment.
If that's the case, how about
That would make hashing and probably equality slower.
on 32 bit system would not be slower
Change:
fn ty(&mut self) -> &mut Self { let ty = self.ev.tcx.type_of(self.item_def_id); <del> self.walk_ty(ty) } fn walk_ty(&mut self, ty: Ty<'tcx>) -> &mut Self { </del> ty.visit_with(self); if let ty::TyFnDef(def_id, _) = ty.sty { if def_id == self.item_def_id {

Discussion:
Works on beta, but not on nightly. This breaks miri.
That was probably me. I'll have a look
Change:
method!(visit_ty: ast::Ty, ast::TyKind::MacCall, walk_ty); fn visit_item(&mut self, item: &'b Item) { <del> let macro_use = match item.kind { </del> <ins> let orig_module_scope = self.parent_scope.module; self.parent_scope.macro_rules = match item.kind { </ins> ItemKind::MacroDef(..) => { <del> self.parent_scope.macro_rules = self.define_macro(item); return; </del> <ins> let macro_rules_scope = self.define_macro(item); visit::walk_item(self, item); macro_rules_scope </ins> } ItemKind::MacCall(..) => { <del> self.parent_scope.macro_rules = self.visit_invoc_in_module(item.id); return; </del> <ins> let macro_rules_scope = self.visit_invoc_in_module(item.id); visit::walk_item(self, item); macro_rules_scope } _ => { let orig_macro_rules_scope = self.parent_scope.macro_rules; self.build_reduced_graph_for_item(item); visit::walk_item(self, item); match item.kind { ItemKind::Mod(..) if self.contains_macro_use(&item.attrs) => { self.parent_scope.macro_rules } _ => orig_macro_rules_scope, } </ins> } <del> ItemKind::Mod(..) => self.contains_macro_use(&item.attrs), _ => false, </del> }; <del> let orig_current_module = self.parent_scope.module; let orig_current_macro_rules_scope = self.parent_scope.macro_rules; self.build_reduced_graph_for_item(item); visit::walk_item(self, item); self.parent_scope.module = orig_current_module; if !macro_use { self.parent_scope.macro_rules = orig_current_macro_rules_scope; } </del> <ins> self.parent_scope.module = orig_module_scope; </ins> } fn visit_stmt(&mut self, stmt: &'b ast::Stmt) {

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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 can hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
kind_name = "variant"; } None => { <del> let resolved_expected = fcx.infcx().ty_to_str(fcx.infcx().resolve_type_vars_if_possible(expected)); fcx.infcx().type_error_message_str(pat.span, |actual| { </del> <ins> fcx.infcx().type_error_message_str_with_expected(pat.span, |expected, actual| { expected.map_default(~"", |&e| { </ins> fmt!("mismatched types: expected `%s` but found %s", <del> resolved_expected, actual)}, ~"a structure pattern", </del> <ins> e, actual)})}, Some(expected), ~"a structure pattern", </ins> None); fcx.write_error(pat.id); kind_name = "[error]";

Discussion:
This program generates: Additionally, a similar program yields
+1, I'm running into this, too.
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?
nominating for Production Ready
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
I've fixed this in a branch. Just testing now.
Fixed pending
Fixed in
Change:
mir, rpo, tcx, <del> param_env: tcx.param_env(def_id), temp_qualif: IndexVec::from_elem(None, &mir.local_decls), </del> <ins> param_env, temp_qualif, </ins> return_qualif: None, qualif: Qualif::empty(), const_fn_arg_vars: BitVector::new(mir.local_decls.len()), <del> local_needs_drop: IndexVec::from_elem(None, &mir.local_decls), </del> temp_promotion_state: temps, promotion_candidates: vec![] }

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
} } <ins> clean::MethodItem(..) | clean::AssocConstItem(..) | clean::AssocTypeItem(..) => { let item_id = i.item_id; if item_id.is_local() && !self.effective_visibilities.is_reachable(self.tcx, item_id.expect_def_id()) { debug!("Stripper: stripping {:?} {:?}", i.type_(), i.name); return None; } } </ins> clean::StructFieldItem(..) => { if i.visibility(self.tcx) != Some(Visibility::Public) { return Some(strip_item(i));

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 the documentation for the type alias to show the method and the implementation of . Instead, the type alias does not show the method . It does however show the implementation of . ! By publicly exposing through , the documentation of on the alias is documented as I expected, but then is publicly reachable, which in my case is unwanted due to being an internal implementation detail. This also works when making the statement , which gets the docs to look like I expected them to. ! <!-- 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. --: Thanks for helping me figure out why what I was expecting wasn't happening though it looked like it should.
I think it's ok to document an impl on a reexported if the reexported item is not doc hidden. I'll send a fix in the next weeks.
Change:
/// Note that here the call to [`drop`] is for clarity - it indicates /// that we are done with the given value and it should be destroyed. /// <del> /// ## 3. Get it from C. </del> <ins> /// ## 3. Create it using `ptr::addr_of!` /// /// Instead of coercing a reference to a raw pointer, you can use the macros /// [`ptr::addr_of!`] (for `*const T`) and [`ptr::addr_of_mut!`] (for `*mut T`). /// These macros allow you to create raw pointers to fields to which you cannot /// create a reference (without causing undefined behaviour), such as an /// unaligned field. This might be necessary if packed structs or uninitialized /// memory is involved. /// /// ``` /// #[derive(Debug, Default, Copy, Clone)] /// #[repr(C, packed)] /// struct S { ///     aligned: u8, ///     unaligned: u32, /// } /// let s = S::default(); /// let p = std::ptr::addr_of!(s.unaligned); // not allowed with coercion /// ``` /// /// ## 4. Get it from C. </ins> /// /// ``` /// # #![feature(rustc_private)]

Discussion:
Rust 1.51 was released yesterday and included the  macro. Its documentation talks about its usage in creating pointers to unaligned fields without the need for an intermediate reference: Despite that, the documentation of [] states the following: The documentation of [] should be updated to reflect the new changes in the language. : and modify labels: T-doc claim []: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --