jiebi/CodeConvo huggingface dataset:
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. // Test that we don't ICE when inlining a function from another // crate that uses a trait method as a value due to incorrectly // translating the def ID of the trait during AST decoding. // aux-build:issue-18501.rs extern crate "issue-18501" as issue; fn main() { issue::pass_method(); } </ins>

Discussion:
While trying to replace the "secret" functions (e.g. ) used for with their UFCS versions (e.g. ), I ran into the following ICE: I couldn't get a backtrace with nor with cc
I have similar ICE without inlining: But i can't reproduce it in simple code example for now.
Caught it! Main body: Test body:
I guess this the related, since I'm actually trying to use UFCS to inline a function and the function is not defined in my crate, Using rustc 0.13.0-dev ( 2014-10-24 03:22:29 +0000) as well as master from playpen, By the way, it might be nice if playpen was able to automatically display (and/or send) that information when ICEs are found.
Some of these look similar to , but the fix for that went in recently...
your issue is , and the fix for it just landed. I think the others still occur.
your ICE does not appear to be UFCS-related. Can you open a separate issue?
I can confirm that the original example still ICEs even with the fix for , so it is a different issue:
I'm seeing a def with the wrong crate ID. It looks like an AST decoding problem. Hopefully an easy fix.
Change:
} // @has 'toggle_item_contents/enum.LargeEnum.html' <del> // @count - '//details[@class="rustdoc-toggle type-contents-toggle"]' 1 // @has - '//details[@class="rustdoc-toggle type-contents-toggle"]' 'Show 13 variants' </del> <ins> // @count - '//*[@class="rust enum"]//details[@class="rustdoc-toggle type-contents-toggle"]' 1 // @has - '//*[@class="rust enum"]//details[@class="rustdoc-toggle type-contents-toggle"]' 'Show 13 variants' </ins> pub enum LargeEnum { A, B, C, D, E, F(u8), G, H, I, J, K, L, M }

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
}) }) .collect::<Vec<_>>(); <del> run_compiler(&args, &mut callbacks, None, None, None) </del> <ins> RunCompiler::new(&args, &mut callbacks).run() </ins> }); // The extra `t` is necessary to align this label with the others. print_time_passes_entry(callbacks.time_passes, "ttotal", start.elapsed());

Discussion:
This argument list is slowly getting out of hand. Maybe we should create a builder pattern struct that doesn't require most calls to use ? Anyway, pre-existing, if you rather open an issue about it than fix it here, I'm fine with merging this PR Originally posted by in
modify labels: +A-driver +C-cleanup +T-compiler
I would like to give this a try if mentoring is available
I'll be happy to mentor, but we should wait for to get merged, because any change you do will conflict with that PR. Though you can start by basing your change on top of that PR. You will need to modify each place that is modified in that PR, so keep it bookmarked and look at it whenever you end up wondering what you may need to touch. The root change to do is to make private and add a new struct right next to it. That new struct should have a field for every parameter of the function and an inherent method () that just forwards all these fields to . You'll need a method that takes only the non- fields as parameters and creates a new instance of your builder struct with those fileds initialized and the rest set to . Then you'll need a method for each field to be able to set it. After adjusting all the callsites and everything compiles again, you should make a commit and put all follow-up changes in separate commits. As a follow up change you can make take the struct as an argument instead of all the fields individually. You can then destructure the struct in the body of to get all the fields out. There may be other things that you may notice while implementing this change that could be optimized, idk, but we can close this issue after the above changes.
Hi I was trying to get my hands on this. But since Optional fields can't be copied to runcompile, how can I pass those fields to ?. Here is code change that you suggested. I could technically replace to accept references instead of values but that will require the entire function to refactor, and I am not sure I can do that. Am I doing it wrong? What alternative I can take to get this issue fixed?
can take instead of .
Thanks just been away from rust for like 15 days and completely forgot I can do that. one more thing. was also used in miri and rls submodules.

Do I need to make a pull request there for the changes. Thanks.
Once (beta branching) is merged it is fine for miri and rls to break. Submitting a PR there is nice, but not necessary. The respective maintainers are normally the ones to fix them again.
Change:
} } <del> /// A `BuildHasher` is typically used as a factory for instances of `Hasher` /// which a `HashMap` can then use to hash keys independently. </del> <ins> /// A trait for creating instances of [`Hasher`]. /// /// A `BuildHasher` is typically used (e.g. by [`HashMap`]) to create /// [`Hasher`]s for each key such that they are hashed independently of one /// another, since [`Hasher`]s contain state. /// /// For each instance of `BuildHasher`, the [`Hasher`]s created by /// [`build_hasher`] should be identical. That is, if the same stream of bytes /// is fed into each hasher, the same output will also be generated. /// /// # Examples /// /// ``` /// use std::collections::hash_map::RandomState; /// use std::hash::{BuildHasher, Hasher}; /// /// let s = RandomState::new(); /// let mut hasher_1 = s.build_hasher(); /// let mut hasher_2 = s.build_hasher(); </ins> /// <del> /// Note that for each instance of `BuildHasher`, the created hashers should be /// identical. That is, if the same stream of bytes is fed into each hasher, the /// same output will also be generated. </del> <ins> /// hasher_1.write_u32(8128); /// hasher_2.write_u32(8128); /// /// assert_eq!(hasher_1.finish(), hasher_2.finish()); /// ``` /// /// [`build_hasher`]: #tymethod.build_hasher /// [`Hasher`]: trait.Hasher.html /// [`HashMap`]: ../../std/collections/struct.HashMap.html </ins> #[stable(since = "1.7.0", feature = "build_hasher")] pub trait BuildHasher { /// Type of the hasher that will be created.

Discussion:
Part of Here's what needs to be done to close out this issue: needs a stronger summary/explanation distinction. "This structure is zero-sized and does not need construction." is weird. also needs a stronger summary/explanation distinction. It also needs a better explanation of why it exists with an example. needs general improvement, it is the main bit of this module, but its docs feel tossed together and have few examples or coherence. needs more than just a summary line; it needs explanation and examples.
What kind of further documentation are you looking for here?
Better explanations for examples of implementing and and and more docs generally for all three.
There seem to be a lengthy example of BuildHasherDefault in this commit () Also for BuildHasher and there is a healthy amount of documentation as of now. Hasher seems to be really outdated (still lists several Implementors without mentioning they have been deprecated), which I'm looking into right now.
Thanks ! Looks like all that's left is documenting .
I am happy to mentor anyone who wants to tackle this issue.
I volunteer as a tribute :-)
wonderful! If you need any help, please just let me know, as I said above, happy to help you help me (We can do it here or ping me on IRC)
I have more specifics in the main issue above
I'm gonna tackle this one this weekend! (if that's okay with you,
Change:
<ins> // EMIT_MIR_FOR_EACH_PANIC_STRATEGY // skip-filecheck //@ unit-test: Inline //@ edition: 2021 //@ compile-flags: -Zinline-mir-hint-threshold=10000 -Zinline-mir-threshold=10000 --crate-type=lib pub async fn run(permit: ActionPermit<'_, ()>, ctx: &mut core::task::Context<'_>) { run2(permit, ctx); } // EMIT_MIR inline_coroutine_body.run2-{closure#0}.Inline.diff fn run2<T>(permit: ActionPermit<'_, T>, ctx: &mut core::task::Context) { _ = || { let mut fut = ActionPermit::perform(permit); let fut = unsafe { core::pin::Pin::new_unchecked(&mut fut) }; _ = core::future::Future::poll(fut, ctx); }; } pub struct ActionPermit<'a, T> { _guard: core::cell::Ref<'a, T>, } impl<'a, T> ActionPermit<'a, T> { async fn perform(self) { core::future::ready(()).await } } </ins>

Discussion:
on commit If you don't set a you will OOM while optimizing syn with these very silly flags. I also have another example of this that produces a "but found ConstICE. They look similar, I'll post the other one later if someone wants.
I've been able to minimize to this:
Here is a further minimized -only repro: The came out of the innards of . The use of is not critical, but the use of a type with both a lifetime and a type generic is; for example, will do too. Tested with the above RUSTFLAGS, under . T/ <details<summaryBacktrace</summary</details
Change:
<ins> // Regression test for issue 81708 and issue 91816 where running a drop // elaboration on a MIR which failed borrowck lead to an ICE. static A: () = { let a: [String; 1]; //~^ ERROR destructors cannot be evaluated at compile-time a[0] = String::new(); //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR use of possibly-uninitialized variable }; struct B<T>([T; 1]); impl<T> B<T> { pub const fn f(mut self, other: T) -> Self { let _this = self; //~^ ERROR destructors cannot be evaluated at compile-time self.0[0] = other; //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR use of moved value self } } fn main() {} </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. --The panic happens 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can't seem to reproduce this locally, does it go away if you update your compiler?
Current compiler is: rustc 1.57.0 ( 2021-11-29) And the same happens when I use beta and nightly: beta: cargo 1.56.0-beta ( 2021-09-01) nightly: cargo 1.57.0-nightly ( 2021-09-18) I remembered I was using mold linker () but I switched to the default linker and the same happens, other then that my setup is normal
Actually I can confirm its reproducible, I just tried it with and the same thing happens maybe you didn't checkout the ice branch?
Ahhh, oops. Didn't notice it was on a different branch. Sorry, my bad! Yes, I can reproduce it fine locally.
MCVE: This code has move errors and fails const-checking, just like the original example. The ICE occurs after errors are emitted. did you truncate the logs in your original post? One option is to change the following statement to : For the non-const version, we abort before we ever get to drop elaboration due to the errors, though I'm not sure why.
For const items is queried earlier, without an intermediate exit point:
yes the error log is truncated, I have a move error

<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.
Change:
bb, ), LookupResult::Parent(..) => { <del> span_bug!( </del> <ins> self.tcx.sess.delay_span_bug( </ins> terminator.source_info.span, <del> "drop of untracked value {:?}", bb </del> <ins> &format!("drop of untracked value {:?}", bb), </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. --The panic happens 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can't seem to reproduce this locally, does it go away if you update your compiler?
Current compiler is: rustc 1.57.0 ( 2021-11-29) And the same happens when I use beta and nightly: beta: cargo 1.56.0-beta ( 2021-09-01) nightly: cargo 1.57.0-nightly ( 2021-09-18) I remembered I was using mold linker () but I switched to the default linker and the same happens, other then that my setup is normal
Actually I can confirm its reproducible, I just tried it with and the same thing happens maybe you didn't checkout the ice branch?
Ahhh, oops. Didn't notice it was on a different branch. Sorry, my bad! Yes, I can reproduce it fine locally.
MCVE: This code has move errors and fails const-checking, just like the original example. The ICE occurs after errors are emitted. did you truncate the logs in your original post? One option is to change the following statement to : For the non-const version, we abort before we ever get to drop elaboration due to the errors, though I'm not sure why.
For const items is queried earlier, without an intermediate exit point:
yes the error log is truncated, I have a move error

<!-- 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. --ICE in illegal code in static block, rustc stable/beta/nightly. Found and reduced 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. --: Also happens with <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing as in the prioritization working group.
Change:
echo $$MATCHES ;  fi $(Q)$(PREPARE_LIB_CMD) `ls -drt1 $(PREPARE_WORKING_SOURCE_LIB_DIR)/$(1)` $(PREPARE_WORKING_DEST_LIB_DIR)/ endef # Copy a man page # $(1) - source dir <ins> # # See above for an explanation on the surrounding blank lines </ins> define PREPARE_MAN @$(call E, prepare: $(PREPARE_DEST_MAN_DIR)/$(1)) $(Q)$(PREPARE_MAN_CMD) $(PREPARE_SOURCE_MAN_DIR)/$(1) $(PREPARE_DEST_MAN_DIR)/$(1) endef PREPARE_TOOLS = $(filter-out compiletest rustbook error-index-generator, $(TOOLS))

Discussion:
Also .
Like any good bug, turning on debugging changes behaviour (VERBOSE=1). It creates a directory called ' From make output:
Found the problem, making PR.
Change:
) => { db.span_note(span_def, "the macro is defined here"); } <del> BuiltinLintDiagnostics::ElidedLifetimesInPaths( n, path_span, incl_angl_brckt, insertion_span, anon_lts, ) => { add_elided_lifetime_in_path_suggestion( sess.source_map(), &mut db, n, path_span, incl_angl_brckt, insertion_span, anon_lts, ); } </del> BuiltinLintDiagnostics::UnknownCrateTypes(span, note, sugg) => { db.span_suggestion(span, &note, sugg, Applicability::MaybeIncorrect); }

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
} #[derive(LintDiagnostic)] <del> #[diag(passes_macro_export)] pub struct MacroExport; </del> <ins> pub enum MacroExport { #[diag(passes_macro_export)] Normal, #[diag(passes_invalid_macro_export_arguments)] UnknownItem { name: Symbol }, #[diag(passes_invalid_macro_export_arguments_too_many_items)] TooManyItems, } </ins> #[derive(LintDiagnostic)] #[diag(passes_plugin_registrar)]

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 to see this happen: it shouldn't compile Instead, this happened: it compiles <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
For anyone who would like to work on this, the following code needs to be adjusted to check if the meta-item list is empty or if it only contains the identifier (i.e. only allowing the attribute to be or : Due to backward compatibility concerns, probably only a future-incompat warning should be issued if the verification fails. label T-compiler A-attributes
claim
First rust-lang/rust contribution I hope this goes well
Change:
if start_r == end_r { // Trace `block_r` elements from the right side. start_r = MaybeUninit::slice_as_mut_ptr(&mut offsets_r); <del> end_r = MaybeUninit::slice_as_mut_ptr(&mut offsets_r); </del> <ins> end_r = start_r; </ins> let mut elem = r; for i in 0..block_r {

Discussion:
Similar to I tried this code: I expected to see this happen: Miri does not detect UB Instead, this happened: Miri detects UB (experimentally) <!-- 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<summaryBacktrace</summary<p</p</details
cc
FWIW, I have now detected this bug through the tests in and .
Looks like the problem is in this line: re-borrows an on the entire slice, thus invalidation previously created pointers. So this is yet another instance of
Actually, just to be sure, are we interested in patching out all such instances of this in std/alloc/core? I know I personally would like the standard library to be clean against Miri with so that I can check libraries for stacked borrows issues. I just did a quick skim now that I understand the rules and I think I can spot a few other issues, so I'm not sure if these were deliberately left in, or if I'm just the first person to be looking this carefully.
So far we fixed various issues of this sort that people noticed, but there was never a concerted effort to find all of them. So they were not deliberately left in, just not found yet. Whether we want to fix them all is up to who ultimately decide about the std library implementation.
So far the fixes have been localized enough that it's been easy to take them (eg ). If anything comes up that requires drastic changes to fix then there might be a conversation about it, but for simple ones that don't increase maintenance burden I think they'll be happily accepted.
Change:
} fn visit_struct_field(&mut self, s: &'v StructField) { walk_struct_field(self, s) } fn visit_enum_def(&mut self, enum_definition: &'v EnumDef, <del> generics: &'v Generics, item_id: NodeId) { </del> <ins> generics: &'v Generics, item_id: NodeId, _: Span) { </ins> walk_enum_def(self, enum_definition, generics, item_id) } fn visit_variant(&mut self, v: &'v Variant, g: &'v Generics, item_id: NodeId) {

Discussion:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.
Change:
Ok(variant) }).collect::<Result<IndexVec<VariantIdx, _>, _>>()?; <ins> size = size.align_to(align.abi); </ins> let abi = if prefix.abi.is_uninhabited() || variants.iter().all(|v| v.abi.is_uninhabited()) { Abi::Uninhabited

Discussion:
I just ran into this ICE: I can't share the code but here are some observations: The ICE occurs in debug mode as well. It does not occur when running . It does not* occur on my MacBook (same nightly, different architecture). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Can you try to isolate the code, e.g. produce some code (not longer than 50 lines) that reproduces this issue?
I have no idea where to even start. Maybe a  run will help.
How big is the code? You could start by removing 'mod xxx' in your Remove types that are not needed. Then if you only have a few files left, merge them into one and remove more things (e.g. not needed functions, structs, enums), try to replace macros with their actual content.
Using I have determined that the ICE started to appear with (). I'll try to isolate the code now.
i'm hitting this too, will see if i can make a small repro. building for target from a linux x86_64 host.
My project doesn't build for ARM even with , which casts doubt on the above rollup merge containing the cause, I think. (Also possible that there are two similar bugs introduced at different times.) I'll try to bisect.
My bisect indicates the regression was introduced in . Armed with this clue I'm trying to figure out which part of my (giant) project is triggering it in order to make a repro.
I've narrowed down the block of code that triggers the regression, and simplified it to the extent possible, but when extracted from the project it no longer causes rustc to panic. In case it's useful: If the line with the arrow is commented out, the code compiles. Uncommented, it fails with: Will update if I have any success producing a standalone reproduction.
OK, I managed to extract a standalone reproduction:
cc
I a comment in the repo; you can make it build or fail to build by just reversing the order of two lines of code.
I updated the repo by folding a minimised implementation of into it rather than depending on the crate, since seemed to be necessary to trigger the bug.

In doing so I updated to std::future and the ICE disappeared. Adding to round-trip the future through a 0.1 Future brings the ICE back. (see comments in )
claim
Thanks for reporting this! Fix should be landing soon.
Change:
<ins> // compile-flags: --emit metadata --crate-type lib --edition 2018 #![crate_name = "foo"] pub mod bar { pub use bool; pub use char as my_char; } </ins>

Discussion:
When re-exporting a primitive type, rustdoc ICEs. This was found when creating . Rustdoc also fails to link the re-export to the primitive docs. Reproduction: commands: Backtrace:
I plan on investigating this issue tomorrow, as it is likely a blocker for
-- this is blocking , and I was unable to come up with a simple patch to fix this. Is this a known-hard problem, or should I try to keep digging? contains my initial patch, but it fails tests (e.g., auto impls for primitives, among other problems).
I'll try to take a look shortly. And no, never heard of it before you opened this issue. Don't hesitate to ping me if I forget.