jiebi/CodeConvo huggingface dataset:
Change:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 112242 //@ check-pass //@ compile-flags: -Znormalize-docs pub trait MyTrait<'a> { type MyItem; } pub struct Inner<Q>(Q); pub struct Outer<Q>(Inner<Q>); impl<'a, Q> std::marker::Unpin for Inner<Q> where Q: MyTrait<'a>, <Q as MyTrait<'a>>::MyItem: Copy, { } </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 --
probably cc
yep yep yep, I got it :) claim

<!-- 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
reduced a bit `
Ah another bug ^^. label T-compiler A-synthetic-impls A-auto-traits
reduce:
All three reproducers will be fixed by .
I can no longer reproduce any of these issues.
Change:
|         ^^^^^^^^^^^ = help: consider adding an explicit import of `foo` to disambiguate <del> error: aborting due to 5 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> Some errors occurred: E0252, E0659. For more information about an error, try `rustc --explain E0252`.

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
hir::LocalSource::AssignDesugar(_) => ("destructuring assignment binding", None), }; self.check_irrefutable(&loc.pat, msg, sp); <del> self.check_patterns(&loc.pat); </del> <ins> self.check_patterns(&loc.pat, Irrefutable); </ins> } fn visit_param(&mut self, param: &'tcx hir::Param<'tcx>) { intravisit::walk_param(self, param); self.check_irrefutable(&param.pat, "function argument", None); <del> self.check_patterns(&param.pat); </del> <ins> self.check_patterns(&param.pat, Irrefutable); </ins> } }

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: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
builder.config.build, compiler.host, "Cross-compiling is not yet supported with `download-rustc`", ); <ins> // #102002, cleanup stage1 and stage0-sysroot folders when using download-rustc so people don't use old versions of the toolchain by accident. let _ = fs::remove_dir_all(host_dir.join("stage1")); let _ = fs::remove_dir_all(host_dir.join("stage0-sysroot")); </ins> // Copy the compiler into the correct sysroot. let ci_rustc_dir = builder.config.out.join(&*builder.config.build.triple).join("ci-rustc");

Discussion:
suggests deleting the and directories when using download-rustc, to avoid caching issues like this. still won't do the right thing, but it will at least give a hard error instead of silently using the wrong version. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: in delete the sysroots and folders, not just the current sysroot. Some background info: https://rustc-dev-
claim
Change:
"CFG_JEMALLOC_ROOT" if value.len() > 0 => { let target = self.target_config.entry(self.build.clone()) .or_insert(Target::default()); <del> target.jemalloc = Some(parse_configure_path(value)); </del> <ins> target.jemalloc = Some(parse_configure_path(value).join("libjemalloc_pic.a")); </ins> } "CFG_ARM_LINUX_ANDROIDEABI_NDK" if value.len() > 0 => { let target = "arm-linux-androideabi".to_string();

Discussion:
: “set directory where libjemallocpic.a is located”, but it actually expects full path of , not a directory. When I set (and --enable-rustbuild), then build fails: The problem is in . It works fine with .
A friendly ping, this would break most distros on a major release.
Change:
// Return types are a bit more complex. They may contain opaque `impl Trait` types. let mir_output_ty = body.local_decls[RETURN_PLACE].ty; let output_span = body.local_decls[RETURN_PLACE].source_info.span; <del> if let Err(terr) = self.eq_types( normalized_output_ty, mir_output_ty, Locations::All(output_span), ConstraintCategory::BoringNoLocation, ) { span_mirbug!( self, Location::START, "equate_inputs_and_outputs: `{:?}=={:?}` failed with `{:?}`", normalized_output_ty, mir_output_ty, terr ); }; </del> <ins> self.equate_normalized_input_or_output(normalized_output_ty, mir_output_ty, output_span); </ins> } #[instrument(skip(self), level = "debug")]

Discussion:
All of this is yanked out of my work-in-progress bug-for-bug Misskey Flavored markdown parser, which uses the trait, as defined below, to hopefully allow the compiler to create well-optimized functions via inlining and such. Where things get messy is in the introduction of the trait, which uses the same technique used by the and crates in order to remove the generic lifetime from its associated type, , since lifetime-only generic associated types aren't object-safe (yet?), despite lifetime-only generic parameters being object-safe. Object-safety is required in this case, because the syntax doesn't support cyclic types (for obvious reasons), so boxing and dynamic dispatch is necessary in order to break said cycle. as in, it behaves identically to , regardless of if that behavior is really "correct" behavior for a markdown parser or not._ <details<summarySorry for the rather large reproduction, this was as small as I was able to get it :sweat:</summary</details: <details<summary<strongBacktrace</strong</summary<p</p</details
Reduced:
Further reduced.
Further minimized:
Change:
let own = &args[self.parent_count..][..self.params.len()]; if self.has_self && self.parent.is_none() { &own[1..] } else { own } } <ins> /// Returns true if a concrete type is specified after a default type. /// For example, consider `struct T<W = usize, X = Vec<W>>(W, X)` /// `T<usize, String>` will return true /// `T<usize>` will return false pub fn check_concrete_type_after_default( &'tcx self, tcx: TyCtxt<'tcx>, args: &'tcx [ty::GenericArg<'tcx>], ) -> bool { let mut default_param_seen = false; for param in self.params.iter() { if let Some(inst) = param.default_value(tcx).map(|default| default.instantiate(tcx, args)) { if inst == args[param.index as usize] { default_param_seen = true; } else if default_param_seen { return true; } } } false } </ins> } /// Bounds on generics.

Discussion:
or The current error message does not tell me the mismatch is in rather than in . It is also inconsistent with the error message I would get if has without the default types. When removing the default for the first parameter (which is not the mismatched one) like this: the error message is clearer: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// # Examples /// /// ``` <del> /// use std::f64; </del> /// let v = f64::from_bits(0x4029000000000000); <del> /// let difference = (v - 12.5).abs(); /// assert!(difference <= 1e-5); </del> <ins> /// assert_eq!(v, 12.5); </ins> /// ``` #[stable(feature = "float_bits_conv", since = "1.20.0")] #[inline]

Discussion:
These feel appropriate to add for completeness, and would simply chain or with the appropriate integer method. I'll add a PR soon. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Byte order conversions on floats themselves make little sense. The conversions should be done before float’s functions are called.
Err, I misread the proposal the first time around...
claim
Change:
const BAR: bool = unsafe { foo(true) }; fn main() { <del> assert_eq!(BAR, true); </del> <ins> assert_eq!(BAR, true); </ins> }

Discussion:
Currently one cannot call in constant functions, so one cannot add hints of the form: These types of hints can heavily influence code generation, which can substantially change the performance of when they are invoked at run-time. It would be a shame to have to write and call and because the code generated for is sub-par. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One cannot do any sort of conditional control flow, so would currently be less than useless. Any test you can write would be undefined behaviour
the RFC for / in const was merged and is pending an implementation right? When that's implemented, will still be useless?
No it makes sense after we have conditional control flow.
As I understand / in const functions is now implemented. Can be made into a now?
yes. Basically you just need to add the attribute to the intrinsic and wrapper function. This is documented at https://rustc-dev- Let me know if anything is unclear (in which case we should update the guide)
Hi, It looks like previous PR is not being worked on currently. I'm working on this and will create a PR soon. claim
As mentioned in , this issue should be reopened (to track stablization)
cc ^
After a short discussion on Zulip, it was decided that it's best to wait for to stabilize to avoid a potential footgun wherein users use this instead of , leading to UB at runtime. I'm subscribed to the issue and intend to file a PR to stabilize this once the aforementioned happens.
Change:
impl Write for Cursor<Box<[u8]>> { #[inline] fn write(&mut self, buf: &[u8]) -> io::Result<usize> { <del> let pos = cmp::min(self.pos, self.inner.len() as u64); let amt = (&mut self.inner[(pos as usize)..]).write(buf)?; self.pos += amt as u64; Ok(amt) </del> <ins> slice_write(&mut self.pos, &mut self.inner, buf) </ins> } fn flush(&mut self) -> io::Result<()> { Ok(()) } }

Discussion:
It is currently impossible to use a std::io::Cursor over a Vec in a smart pointer (Mutex, RefCell, ...) in a sane way. Please implement Read/Write/... over Cursor<&'a mut Vec<u8. Discussed on .
Good workaround is to call the function on the mutable Vec reference when creating the Cursor. Then you'll have and Read/Write is implemented.
AFAICT, adding such an impl is a breaking change:
New implementations are allowed to cause inference breakage.
Seems reasonable. I would be interested in seeing a PR that implements this.
Change:
ret e; } <ins> fn identity_update_env_for_view_item[ENV](&ENV e, @view_item i) -> ENV { ret e; } </ins> fn identity_update_env_for_block[ENV](&ENV e, &block b) -> ENV { ret e; }

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
<ins> // Copyright 2014 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: cannot apply unary operator `!` to type `BytePos` // Very // sensitive pub struct BytePos(pub u32); // to particular // line numberings / offsets fn main() { let x = BytePos(1); assert!(x, x); } </ins>

Discussion:
When trying to build with I'm getting
Is there a temporary workaround? Thanks!
Most likely change the occurrences of (or ) to . Like .
I just tripped over this ICE in serde. I love c-reduce. It came up with the following code that reproduces the bug by reducing 203K down to this in 15 minutes: Here's the error:
Change:
// create a dummy value and continue compiling Const::from_bits(self.tcx, 0, self.param_env.and(ty)) } <ins> Err(LitToConstError::TypeError) => bug!("const_eval_literal: had type error"), </ins> } }

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and , but not on . <details<summaryNightly backtrace</summary</details
triage: P-high, assigning to self.
(This ended up being a great motivation for me to tie off some work I've been doing...)
ICE was introduced between nightly 2020-01-15 and 2010-01-16. Here are the merges from that time period: ( is independently working to identify which one is the culprit.)
Okay finished: searched nightlies: from nightly-2020-01-15 to nightly-2020-01-22 regressed nightly: nightly-2020-01-16 searched commits: from to regressed commit:
Looks like the problem was injected by PR
reassigning to
The following also causes an ICE: (Same reason, but different message.)
Fixed by
Change:
use rustc_data_structures::fx::FxHashSet; use rustc_hir as hir; <ins> use rustc_middle::mir::interpret::{InterpError, InterpErrorInfo}; </ins> use rustc_middle::ty; use rustc_middle::ty::layout::TyAndLayout; use rustc_span::symbol::{sym, Symbol};

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
.map_or(true, |d| cache.paths.contains_key(&d))); <del> let (synthetic, concrete): (Vec<&&Impl>, Vec<&&Impl>) = local.iter() </del> <ins> let (mut synthetic, mut concrete): (Vec<&&Impl>, Vec<&&Impl>) = local.iter() </ins> .partition(|i| i.inner_impl().synthetic); <ins> synthetic.sort_by(compare_impl); concrete.sort_by(compare_impl); </ins> if !foreign.is_empty() { write!(w, " <h2 id='foreign-impls' class='small-section-header'>

Discussion:
impl<'a, TIntoIterator for &'a mut [T; 12] impl<'a, TIntoIterator for &'a [T; 25] impl<'a, TIntoIterator for &'a mut [T; 21] impl<'a, TIntoIterator for &'a [T; 2] ... this ordering doesn't make any sense and makes the docs harder to navigate.
It has been fixed on nightly. The fix will come to stable eventually.
Change:
fn parse_object(&mut self, first: bool) -> JsonEvent { if self.ch_is('}') { if !first { <del> self.stack.pop(); </del> <ins> if self.stack.is_empty() { return self.error_event(TrailingComma); } else { self.stack.pop(); } </ins> } if self.stack.is_empty() { self.state = ParseBeforeFinish;

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.
Change:
macro_rules! rem_impl { ($($t:ty)*) => ($( <ins> /// This operation satisfies `n % d == n - (n / d) * d`.  The /// result has the same sign as the left operand. </ins> #[stable(feature = "rust1", since = "1.0.0")] impl Rem for $t { type Output = $t;

Discussion:
Using Google I can find lots of old arguments over how integer division should work in Rust, but I cannot find anything in the reference, the API docs for the integer types, or the API docs for the trait that says what was actually decided. (And the documentation seems to imply that , , and may not all do the same thing.) This is further confused by the integer type documentation apparently sometimes using to refer to integer division and sometimes to mathematical division. (I can't come up with out any other reasonable interpretation of in the documentation.) It would be nice if this were clearly documented somewhere, since this varies between languages and is one of the main confusions with integer arithmetic.
talks about 'overflow' and mentions wrapping, but you're right that we can surface this better.
This is about rounding, not wrapping. We use LLVM's , which rounds towards zero (and has the same sign as the dividend). We should document this (the documentation for currently lies_, claiming that it rounds towards negative infinite).
This should also leave a warning, because integer / integer is not always desired and happens by accident. Just a thought if anyone is reading this.
Change:
use std::mem; use thin_vec::ThinVec; <ins> use crate::clean::inline::merge_attrs; </ins> use crate::core::{self, DocContext, ImplTraitParam}; use crate::formats::item_type::ItemType; use crate::visit_ast::Module as DocModule;

Discussion:
Found while reducing , but the error is different (probably same root cause however) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +T-rustdoc searched nightlies: from nightly-2023-01-01 to nightly-2023-02-23 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summary</detailscc
being looked up: table:
cc
Duplicate of , fixed in

This looks similar to , but this wasn't fixed by <!-- 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 modify labels +A-resolve
This ICE seems to be related to intra-doc link resolution, not standard name resolution. My bad :sweat_smile: modify labels +A-intra-doc-links -A-resolve
Minimum reproduction code:
The issue is in rustdoc, it passes a wrong parent module ( instead of the root ) when requesting resolutions for .
The resolution exists in rustc tables, it's just attached to , not .
The issue is in rustdoc, it passes a wrong parent module is currently used for determining the parent module, but it's wrong for inlined items because for them represents the target item, not the item itself. It looks like can be used instead, I'm just not sure how consistently it's set.
Thanks for the information! Wanna send the fix? Otherwise I plan to do it in the next days.
Fixed in The issue turned out a bit deeper than described in

The  crate <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
probably duplicate of
This is some different issue than whitespace issues in , it's not resolved by I'll investigate in more detail in a couple of days.
Fixed in
Change:
<ins> fn main() {} fn foo(u: u8) { if u8 macro_rules! u8 { (u6) => { fn uuuuuuuuuuu() { use s loo mod u8 { //~^ ERROR expected `{`, found `macro_rules` //~ ERROR this file contains an un-closed delimiter </ins>

Discussion:
I'm seeing the following error on the channel, but not on or : Found with the help of .
triage: P-medium. Leaving nominated so that team double-checks that priority assignment.
This is triggered here It should be possible to use the span snippet instead. I believe it was introduced in
Change:
} fn visit_fn(&mut self, fn_kind: FnKind<'ast>, sp: Span, _: NodeId) { let rib_kind = match fn_kind { <del> // Bail if there's no body. FnKind::Fn(.., None) => return visit::walk_fn(self, fn_kind, sp), FnKind::Fn(FnCtxt::Free | FnCtxt::Foreign, ..) => FnItemRibKind, </del> <ins> // Bail if the function is foreign, and thus cannot validly have // a body, or if there's no body for some other reason. FnKind::Fn(FnCtxt::Foreign, _, sig, ..) | FnKind::Fn(_, _, sig, .., None) => { // We don't need to deal with patterns in parameters, because // they are not possible for foreign or bodiless functions. self.visit_fn_header(&sig.header); visit::walk_fn_decl(self, &sig.decl); return; } FnKind::Fn(FnCtxt::Free, ..) => FnItemRibKind, </ins> FnKind::Fn(FnCtxt::Assoc(_), ..) => NormalRibKind, FnKind::Closure(..) => ClosureOrAsyncRibKind, };

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-11-28 and stable 1.56.1 and they both ICE. In stable 1.56.1 the error message is different though, I would say it's better: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
In one of the recent nightlies the error message has changed to <details<summary<strongBacktrace</strong</summary<p</p</details