jiebi/CodeConvo huggingface dataset:
Change:
states: The second half of the second sentence is plain wrong and . modify labels: T-doc, T-libs, C-enhancement. (Is tagging T-doc ?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Yes, it allows for easy searching of doc issue (at least for me), with .

Discussion:
/// Capture a [closure]'s environment by value. /// /// `move` converts any variables captured by reference or mutable reference <del> /// to owned by value variables. The three [`Fn` trait]'s mirror the ways to capture /// variables, when `move` is used, the closures is represented by the `FnOnce` trait. </del> <ins> /// to owned by value variables. </ins> /// /// ```rust /// let capture = "hello";

/// }; /// ``` /// <ins> /// Note: `move` closures may still implement [`Fn`] or [`FnMut`], even though /// they capture variables by `move`. This is because the traits implemented by /// a closure type are determined by *what* the closure does with captured /// values, not *how* it captures them: /// /// ```rust /// fn create_fn() -> impl Fn() { ///     let text = "Fn".to_owned(); /// ///     move || println!("This is a: {}", text) /// } /// ///     let fn_plain = create_fn(); /// ///     fn_plain(); /// ``` /// </ins> /// `move` is often used when [threads] are involved. /// /// ```rust
Change:
<!-- 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. --repo @ Rustc simply hangs when running Edit: while rustc is crunching on the hang:
cc ? edit: I assume this is due to
O_o yea, I'll have a look
Wild speculation: might have the same cause (EDIT: Backtrace says yes)

Discussion:
} self.basic_blocks[bb].terminator = Some(terminator); <del> changed |= inner_changed; </del> } if !changed {

Terminator { kind: TerminatorKind::Goto { ref mut target }, .. } => target, _ => unreachable!(), }; <ins> *changed |= *target != last; </ins> *target = last; debug!("collapsing goto chain from {:?} to {:?}", current, target);

self.pred_count[*target] += 1; self.pred_count[current] -= 1; } <del> *changed = true; </del> self.basic_blocks[current].terminator = Some(terminator); } }

<ins> // Caused an infinite loop during SimlifyCfg MIR transform previously. // // build-pass fn main() { loop { continue; } } </ins>
Change:
<!-- 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. --Code is from glaciers , original ticket: The code still ICEs when checking with <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Triage: It's now compiled fine with the latest nightly, perhaps it's fixed by .

Discussion:
<ins> // edition:2018 // compile-flags: -Z mir-opt-level=2 -Z unsound-mir-opts #[inline(always)] pub fn f(s: bool) -> String { let a = "Hello world!".to_string(); let b = a; let c = b; if s { c } else { String::new() } } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // edition:2018 // build-pass #![feature(async_closure)] use std::future::Future; fn async_closure() -> impl Future<Output = u8> { (async move || -> u8 { 42 })() } fn main() { let _fut = async_closure(); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // build-pass #![feature(type_alias_impl_trait)] use std::marker::PhantomData; trait MyIndex<T> { type O; fn my_index(self) -> Self::O; } trait MyFrom<T>: Sized { type Error; fn my_from(value: T) -> Result<Self, Self::Error>; } trait F {} impl F for () {} type DummyT<T> = impl F; fn _dummy_t<T>() -> DummyT<T> {} struct Phantom1<T>(PhantomData<T>); struct Phantom2<T>(PhantomData<T>); struct Scope<T>(Phantom2<DummyT<T>>); impl<T> Scope<T> { fn new() -> Self { unimplemented!() } } impl<T> MyFrom<Phantom2<T>> for Phantom1<T> { type Error = (); fn my_from(_: Phantom2<T>) -> Result<Self, Self::Error> { unimplemented!() } } impl<T: MyFrom<Phantom2<DummyT<U>>>, U> MyIndex<Phantom1<T>> for Scope<U> { type O = T; fn my_index(self) -> Self::O { MyFrom::my_from(self.0).ok().unwrap() } } fn main() { let _pos: Phantom1<DummyT<()>> = Scope::new().my_index(); } </ins>

<ins> // edition:2018 // build-pass // compile-flags: -Z mir-opt-level=2 -L. // aux-build:issue_76375_aux.rs #![crate_type = "lib"] extern crate issue_76375_aux; pub async fn g() { issue_76375_aux::f(true); h().await; } pub async fn h() {} </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // ignore-cloudabi no std::fs // build-pass use std::fs::File; use std::io::{BufRead, BufReader}; fn file_lines() -> impl Iterator<Item = String> { BufReader::new(File::open("").unwrap()) .lines() .map(Result::unwrap) } fn main() { for _ in file_lines() {} } </ins>
Change:
The test is failing on AArch64's CI:
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Just like with every LLVM update it might fix itself or get worse after
The test is causing an infinite loop due to the link register being updated during the call to zzz, that call is causing the link register to be the ret instruction after that call, the ret instruction then returns to the link register causing an infinite loop. Normally before the call the link register would be saved and then restored after the call, however due to this being a naked function that isn't happening. The emitted LLVM IR is just calling the function and that call isn't preserving anything so this could change in a future version of LLVM I suppose. Although with c++ and clang that code would fail to compile as you can only use asm inside a naked function. suggests it's a bug in rustc for allowing the code to compile, is that still your understanding? I also suspect it's why this was raised. I can get the test to pass, but I'm wondering if the test is actually correct in it's current state. EDIT: It's probably worth pointing out that the code in that test will segfault on x86_64
The test is definitely incorrect. Using anything other than inline asm in a naked function is UB.

Discussion:
// We have to ignore android because of this issue: // https://github.com/rust-lang/rust/issues/74847 // ignore-android <ins> // // We need to use inline assembly, so just use one platform // only-x86_64 </ins> // compile-flags:-g

// lldb-command:continue <ins> #![feature(asm)] </ins> #![feature(naked_functions)] #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section]

} #[naked] <del> fn naked(x: usize, y: usize) { zzz(); // #break </del> <ins> extern "C" fn naked(x: usize, y: usize) { unsafe { asm!("ret"); } // #break </ins> } <del> fn zzz() { () } </del>
Change:
: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is it a regression from stable to beta if it doesn't compile on stable? I this to the original comment: On rust stable 1.45.1, it causes this compilation error instead:
Yes, the error message regressed. I don't know if the code is supposed to compile on beta or if it should still fail with the same error, but an ICE is a regression either way.
I think the failure is introduced in and this unwrap causes it: So, my thought is we shouldn't unwrap here and return instead if it's . is this correct?
Yes, return an error mentioning that unsizing is only allowed for references right now.

Discussion:
_, ) => Err((span, "function pointer casts are not allowed in const fn".into())), Rvalue::Cast(CastKind::Pointer(PointerCast::Unsize), op, cast_ty) => { <del> let pointee_ty = cast_ty.builtin_deref(true).unwrap().ty; </del> <ins> let pointee_ty = if let Some(deref_ty) = cast_ty.builtin_deref(true) { deref_ty.ty } else { // We cannot allow this for now. return Err(( span, "unsizing casts are only allowed for references right now".into(), )); }; </ins> let unsized_ty = tcx.struct_tail_erasing_lifetimes(pointee_ty, tcx.param_env(def_id)); if let ty::Slice(_) | ty::Str = unsized_ty.kind { check_operand(tcx, op, span, def_id, body)?;

<ins> // Regression test for #75118. use std::ptr::NonNull; pub const fn dangling_slice<T>() -> NonNull<[T]> { NonNull::<[T; 0]>::dangling() //~^ ERROR: unsizing casts are only allowed for references right now } fn main() {} </ins>

<ins> error[E0723]: unsizing casts are only allowed for references right now --> $DIR/unsizing-cast-non-null.rs:6:5 | LL |     NonNull::<[T; 0]>::dangling() |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information = help: add `#![feature(const_fn)]` to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0723`. </ins>
Change:
<!-- 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: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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 not available in stable.

Discussion:
); self.add_typo_suggestion(err, suggestion, ident.span); <ins> let import_suggestions = self.lookup_import_candidates( ident, Namespace::MacroNS, parent_scope, |res| match res { Res::Def(DefKind::Macro(MacroKind::Bang), _) => true, _ => false, }, ); show_candidates(err, None, &import_suggestions, false, true); </ins> if macro_kind == MacroKind::Derive && (ident.name == sym::Send || ident.name == sym::Sync) { let msg = format!("unsafe traits like `{}` should be implemented explicitly", ident); err.span_note(ident.span, &msg);

| LL |         print!(); |         ^^^^^ <ins> | = note: consider importing this macro: std::print </ins> error: aborting due to previous error

LL |         assert_eq!(0, 0); |         ^^^^^^^^^^^^^^^^^ | <ins> = note: consider importing one of these items: core::panic std::panic </ins> = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0433]: failed to resolve: use of undeclared type `Vec`

| LL | macro_rules! macro_one { () => ("one") } | ---------------------- similarly named macro `macro_one` defined here <ins> | = note: consider importing this macro: two_macros::macro_two </ins> error: aborting due to previous error

| LL |     macro_two!(); |     ^^^^^^^^^ <ins> | = note: consider importing this macro: two_macros::macro_two </ins> error: aborting due to previous error
Change:
This is a tracking issue for , made const in . The feature gate for the issue is . [x] Merge the implementation PR [x] Final Comment Period (FCP) [x] Stabilization PR ()
This is an unsafe operation and thus likely also blocked on Cc
Now that rust-lang/rfcs is merged: merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Stabilization PR is already up:

Discussion:
/// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_str_from_utf8_unchecked", issue = "75196")] </del> <ins> #[rustc_const_stable(feature = "const_str_from_utf8_unchecked", since = "1.55.0")] </ins> #[rustc_allow_const_fn_unstable(const_fn_transmute)] pub const unsafe fn from_utf8_unchecked(v: &[u8]) -> &str { // SAFETY: the caller must guarantee that the bytes `v` are valid UTF-8.
Change:
It's clocking in at 20 minutes and seems to be doing nothing -- I suspect that this might be a result of changes to x.py defaults but have not confirmed. We should fix this.
(link to the PR: )
We discussed this during the and agreed to remove the builder. The builder doesn't provide much value for the stability of the project, as it rarely fails and we'd catch any failure it would prevent as soon as we promote nightly to beta.
To fix this issue, the builders needs to be removed from and .

Discussion:
- name: x86_64-gnu-distcheck os: ubuntu-latest-xl env: {} <del> - name: x86_64-gnu-full-bootstrap os: ubuntu-latest-xl env: {} </del> - name: x86_64-gnu-llvm-8 env: RUST_BACKTRACE: 1

<del> FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  g++  make  file  curl  ca-certificates  python3  git  cmake  sudo  gdb  libssl-dev  pkg-config  xz-utils COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV RUST_CONFIGURE_ARGS  --build=x86_64-unknown-linux-gnu  --enable-full-bootstrap ENV SCRIPT python3 ../x.py --stage 2 build # In general this just slows down the build and we're just a smoke test that # a full bootstrap works in general, so there's not much need to take this # penalty in build times. ENV NO_LLVM_ASSERTIONS 1 ENV NO_DEBUG_ASSERTIONS 1 </del>

- name: x86_64-gnu-distcheck <<: *job-linux-xl <del> - name: x86_64-gnu-full-bootstrap <<: *job-linux-xl </del> - name: x86_64-gnu-llvm-8 env: RUST_BACKTRACE: 1
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
Is the failure at issue?
No, that builder is in the auto-fallible section. The problem is here: We probably want to put a on the llvmasm in blackbox. I presume that's fine for miri? We don't want some sort of "black box intrinsic" I think since there's nothing for miri to really do
Okay, thanks. (For future reference, where did you see that log? All the other CI tests that I can see passed.)
Issues like this one are "toolstate" issues; they're autofiled when tools break in the tools builders. That breakage, however, does not actually fail the builder, instead it just files this issue. This is because miri (and the other tools using this system) are out-of-tree, managed via submodules, and we don't want to be updating the submodules in more than one PR at a time generally speaking (that just causes pain for everyone involved).
Got it, thanks.
There is no way Miri can support inline assembly, so yeah, a sounds about right. I will submit a PR. I hope that black_box was not for soundness reasons; see for a discussion on why that does not work.
If by that you mean "to avoid UB", then no it certainly wasn't. TCO of the frame is sound, one just gets a full rather than short backtrace.
Yes that looks like a valid use of black_box, good. :)

Discussion:
<del> Subproject commit cf633d0e897c065381b7b7d14984830176caf8b2 </del> <ins> Subproject commit 1edd231065c8eb75abf42bb375adda2120c9a6bf </ins>
Change:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

Discussion:
<ins> // compile-flags: -Zmir-opt-level=3 // run-pass #![feature(const_generics)] #![allow(incomplete_features)] fn main() { fn foo<const N: usize>() -> [u8; N] { [0; N] } let _x = foo::<1>(); } </ins>

<ins> // check-pass fn main() { let array = [0x42u8; 10]; for b in &array { let lo = b & 0xf; let hi = (b >> 4) & 0xf; } } </ins>

<ins> // check-pass #![allow(unreachable_patterns)] fn main() { const CONST: &[Option<()>; 1] = &[Some(())]; match &[Some(())] { &[None] => {} CONST => {} &[Some(())] => {} } } </ins>

<ins> const F: &'static dyn PartialEq<u32> = &7u32; fn main() { let a: &dyn PartialEq<u32> = &7u32; match a { F => panic!(), //~ ERROR: `&dyn PartialEq<u32>` cannot be used in patterns } } </ins>

<ins> error: `&dyn PartialEq<u32>` cannot be used in patterns --> $DIR/issue-72565.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>

<ins> #![feature(type_alias_impl_trait)] trait Allocator { type Buffer; } struct DefaultAllocator; impl<T> Allocator for DefaultAllocator { //~^ ERROR: the type parameter `T` is not constrained type Buffer = (); } type A = impl Fn(<DefaultAllocator as Allocator>::Buffer); fn foo() -> A { |_| () } fn main() {} </ins>

<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74244.rs:9:6 | LL | impl<T> Allocator for DefaultAllocator { |      ^ unconstrained type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </ins>
Change:
The reference functions named and , but those functions anywhere in rustc. It seems the docs for this module have , so perhaps that is why?
modify labels to T-doc C-enhancement
It looks like has the .
modify labels: A-codegen
I finally have enough knowledge to fix these!

Discussion:
<del> //! Codegen the completed AST to the LLVM IR. //! //! Some functions here, such as codegen_block and codegen_expr, return a value -- //! the result of the codegen to LLVM -- while others, such as codegen_fn //! and mono_item, are called only for the side effect of adding a //! particular definition to the LLVM IR output we're producing. </del> <ins> //! Codegen the MIR to the LLVM IR. </ins> //! //! Hopefully useful general knowledge about codegen: //! <del> //! * There's no way to find out the `Ty` type of a Value. Doing so </del> <ins> //! * There's no way to find out the [`Ty`] type of a [`Value`]. Doing so </ins> //!   would be "trying to get the eggs out of an omelette" (credit: <del> //!   pcwalton). You can, instead, find out its `llvm::Type` by calling `val_ty`, //!   but one `llvm::Type` corresponds to many `Ty`s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same `llvm::Type`. </del> <ins> //!   pcwalton). You can, instead, find out its [`llvm::Type`] by calling [`val_ty`], //!   but one [`llvm::Type`] corresponds to many [`Ty`]s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same [`llvm::Type`]. //! //! [`Ty`]: rustc_middle::ty::Ty //! [`val_ty`]: common::val_ty </ins> use super::ModuleLlvm;

} } <ins> /// Get the [LLVM type][Type] of a [`Value`]. </ins> pub fn val_ty(v: &Value) -> &Type { unsafe { llvm::LLVMTypeOf(v) } }

<del> //! Codegen the completed AST to the LLVM IR. //! //! Some functions here, such as `codegen_block` and `codegen_expr`, return a value -- //! the result of the codegen to LLVM -- while others, such as `codegen_fn` //! and `mono_item`, are called only for the side effect of adding a //! particular definition to the LLVM IR output we're producing. //! //! Hopefully useful general knowledge about codegen: //! //! * There's no way to find out the `Ty` type of a `Value`. Doing so //!   would be "trying to get the eggs out of an omelette" (credit: //!   pcwalton). You can, instead, find out its `llvm::Type` by calling `val_ty`, //!   but one `llvm::Type` corresponds to many `Ty`s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same `llvm::Type`. </del> use crate::back::write::{ compute_per_cgu_lto_type, start_async_codegen, submit_codegened_module_to_llvm, submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, ComputedLtoType, OngoingCodegen,
Change:
mentions "Panics [...] if begin end, or if end len", which I think is correct. However, mentions "Panics [...] if begin = len", which I think is wrong, isn't it? Shouldn't this be "Panics [...] if begin len"? The current stable compiler doesn't seem to create a panicking program when I use "begin = len". The documentation for slice slicing doesn't mention anything at all: It would be great to have the (correct) description there as well. I think this has already been fixed in and (more than 4 years ago), but it seems to have gotten lost again since then? Or am I missing something?
You're right, I guess it's a copy/paste error from in ? We're happy to see a PR to fix it :)

Discussion:
/// # Panics /// /// Panics if `begin` does not point to the starting byte offset of <del> /// a character (as defined by `is_char_boundary`), or if `begin >= len`. </del> <ins> /// a character (as defined by `is_char_boundary`), or if `begin > len`. </ins> #[stable(feature = "str_checked_slicing", since = "1.20.0")] unsafe impl SliceIndex<str> for ops::RangeFrom<usize> { type Output = str;
Change:
Hypothetically we could have a we expect this not to happen, so this is an invariant of MIR that we can check cc

Discussion:
use crate::util::storage::AlwaysLiveLocals; use super::MirPass; <del> use rustc_middle::mir::visit::{PlaceContext, Visitor}; </del> <ins> use rustc_middle::mir::{ interpret::Scalar, visit::{PlaceContext, Visitor}, }; </ins> use rustc_middle::mir::{ AggregateKind, BasicBlock, Body, BorrowKind, Local, Location, MirPhase, Operand, Rvalue, SourceScope, Statement, StatementKind, Terminator, TerminatorKind, VarDebugInfo, }; use rustc_middle::ty::relate::{Relate, RelateResult, TypeRelation}; use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt}; <ins> use rustc_target::abi::Size; </ins> #[derive(Copy, Clone, Debug)] enum EdgeKind {

), ); } <del> for (_, target) in targets.iter() { </del> <ins> let target_width = self.tcx.sess.target.pointer_width; let size = Size::from_bits(match switch_ty.kind() { ty::Uint(uint) => uint.normalize(target_width).bit_width().unwrap(), ty::Int(int) => int.normalize(target_width).bit_width().unwrap(), ty::Char => 32, ty::Bool => 1, other => bug!("unhandled type: {:?}", other), }); for (value, target) in targets.iter() { if Scalar::<()>::try_from_uint(value, size).is_none() { self.fail( location, format!("the value {:#x} is not a proper {:?}", value, switch_ty), ) } </ins> self.check_edge(location, target, EdgeKind::Normal); } self.check_edge(location, targets.otherwise(), EdgeKind::Normal);
Change:
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! And nominating for compiler team prioritization.
Here's the fix by oli:
It looks like the PR is merged. Should this issue be closed or are there further steps to complete until it's fully fixed?
The submodule should be updated to fix toolstate.
Thanks! I'm trying to understand the protocol around tool breakages, so I was trying to understand why the issue wasn't yet closed :)
I'll get into Miri and then submit a submodule update that will close this issue. :) I often wait a bit after Miri is fixed before doing the submodule update, to collect more things into the same update. It's okay when Miri is missing for a few days.

Discussion:
<del> Subproject commit 1edd231065c8eb75abf42bb375adda2120c9a6bf </del> <ins> Subproject commit 1bfb26d6cae6f535ac1034877635fc0cef87fe64 </ins>