jiebi/CodeConvo huggingface dataset:
Change:
/// // x is no longer available /// ``` /// <ins> /// `move` is also valid before an async block. /// /// ```rust /// let capture = "hello"; /// let block = async move { ///     println!("rust says {} from async block", capture); /// }; /// ``` /// </ins> /// For more information on the `move` keyword, see the [closure]'s section /// of the Rust book or the [threads] section ///

Discussion:
The page currently talks only about the use of move with closures. The keyword is also valid before an async block. For example: . This page could be updated to include that usage. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Edit  and make the text talk about async blocks as well.
claim
Change:
<ins> error[E0380]: auto traits cannot have associated items --> $DIR/issue-105732.rs:4:8 | LL | auto trait Foo { |            --- auto trait cannot have associated items LL |     fn g(&self); |     ---^-------- help: remove these associated items error[E0599]: the method `g` exists for reference `&Self`, but its trait bounds were not satisfied --> $DIR/issue-105732.rs:9:14 | LL |         self.g(); |              ^ | = note: the following trait bounds were not satisfied: `Self: Foo` which is required by `&Self: Foo` `&Self: Foo` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `g`, perhaps you need to add a supertrait for it: | LL | trait Bar: Foo { |          +++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0380, E0599. For more information about an error, try `rustc --explain E0380`. </ins>

Discussion:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.
Change:
LL | |         }> | |__________^ required by this bound in `is_maybe_transmutable` <del> error[E0277]: `()` cannot be safely transmuted into `yawning_void::Void` </del> <ins> error[E0277]: `()` cannot be safely transmuted into `yawning_void_struct::Void` </ins> --> $DIR/uninhabited.rs:49:41 | LL |     assert::is_maybe_transmutable::<(), Void>(); <del> |                                         ^^^^ `yawning_void::Void` is uninhabited </del> <ins> |                                         ^^^^ `yawning_void_struct::Void` is uninhabited | note: required by a bound in `is_maybe_transmutable` --> $DIR/uninhabited.rs:10:14 | LL |       pub fn is_maybe_transmutable<Src, Dst>() |              --------------------- required by a bound in this function LL |       where LL |           Dst: BikeshedIntrinsicFrom<Src, { |  ______________^ LL | |             Assume { LL | |                 alignment: true, LL | |                 lifetimes: true, ...  | LL | |             } LL | |         }> | |__________^ required by this bound in `is_maybe_transmutable` error[E0277]: `()` cannot be safely transmuted into `yawning_void_enum::Void` --> $DIR/uninhabited.rs:71:41 | LL |     assert::is_maybe_transmutable::<(), Void>(); |                                         ^^^^ `yawning_void_enum::Void` is uninhabited </ins> | note: required by a bound in `is_maybe_transmutable` --> $DIR/uninhabited.rs:10:14

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
// At this point we don't have explicit linkage and we're an // inlined function. If we're inlining into all CGUs then we'll <del> // be creating a local copy per CGU </del> <ins> // be creating a local copy per CGU. </ins> if generate_cgu_internal_copies { return InstantiationMode::LocalCopy; }

Discussion:
Code: If the function is marked as , it doesn't get compiled into the dll file: The reason a function may be marked as both and is so that it gets inlined when compiling the crate as a rust library, but not inlined when compiling the crate as a cdylib. There should be a warning to use something like instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Related to - I think is that we should include 'd functions in s and s, but as a short term solution, a warning is a nice idea
claim

I currently use Rust to generate a static library for FFI consumption. In some public interfaces, I call other FFI public interfaces as primarily a wrapper with a few tweaks. I'd like to mark these "inner" functions as inline, however, this seems to cause them to not show up in the final staticlib. Given this drastically simplified example: The function makes it to the static library, but the function does not: If I remove the attribute, we see both functions in the static lib: The don't seem to hint that can prevent / items from surviving all the way to the final library, or that they shouldn't be used together. I would expect any function marked and/or should be present in the final artifact, regardless of attributes. I see this behavior on stable, as well as a recent nightly. I don't know if this is a regression, as this is the first time I've run into this. Thanks! Edit: Simplified profile settings, they are not needed to reproduce. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tried with = same result
I’ve noticed this for a while but I always assumed it was intended... It would be really nice if this was fixed
This appears to have been done deliberately: Maybe it shouldn't apply to s.
Expanding on note, I would also expect this not to apply to s as well (I used the staticlib for my example, but my use case generates code for both static and dynamic library usage).
I think I'm going to take this on claim
Change:
} } } <ins> /// Lints for attempts to impl Drop on types that have `#[repr(C)]` /// attribute (see issue #24585). #[derive(Copy, Clone)] pub struct DropWithReprExtern; declare_lint! { DROP_WITH_REPR_EXTERN, Warn, "use of #[repr(C)] on a type that implements Drop" } impl LintPass for DropWithReprExtern { fn get_lints(&self) -> LintArray { lint_array!(DROP_WITH_REPR_EXTERN) } fn check_crate(&mut self, ctx: &Context, _: &ast::Crate) { for dtor_did in ctx.tcx.destructors.borrow().iter() { let (drop_impl_did, dtor_self_type) = if dtor_did.krate == ast::LOCAL_CRATE { let impl_did = ctx.tcx.map.get_parent_did(dtor_did.node); let ty = ty::lookup_item_type(ctx.tcx, impl_did).ty; (impl_did, ty) } else { continue; }; match dtor_self_type.sty { ty::ty_enum(self_type_did, _) | ty::ty_struct(self_type_did, _) | ty::ty_closure(self_type_did, _) => { let hints = ty::lookup_repr_hints(ctx.tcx, self_type_did); if hints.iter().any(|attr| *attr == attr::ReprExtern) && ty::ty_dtor(ctx.tcx, self_type_did).has_drop_flag() { let drop_impl_span = ctx.tcx.map.def_id_span(drop_impl_did, codemap::DUMMY_SP); let self_defn_span = ctx.tcx.map.def_id_span(self_type_did, codemap::DUMMY_SP); ctx.span_lint(DROP_WITH_REPR_EXTERN, drop_impl_span, "implementing Drop adds hidden state to types,  possibly conflicting with `#[repr(C)]`"); // FIXME #19668: could be span_lint_note instead of manual guard. if ctx.current_level(DROP_WITH_REPR_EXTERN) != Level::Allow { ctx.sess().span_note(self_defn_span, "the `#[repr(C)]` attribute is attached here"); } } } _ => {} } } } } </ins>

Discussion:
(imported from improperly closed bug ) As suggested by Until is done, we really should lint for this scenario.
triage: P-low
oops. triage: P-high (but nonetheless not 1.0)
I feel like this should be stronger than a medium-priority lint. I feel like rustc should reject programs that attempt to on a struct, for as long as that changes the size of that struct. In particular, not fixing this by 1.0 would foreclose the ability to change the drop flag after 1.0, since that would change the size / ABI of structs, right? Or is ABI stability not a guarantee of ?
Yeah this label got auto renamed. I'm up'ing the priority
triage: P-high I'll assign to self too
( I'm pretty confident we could fix this post 1.0, e.g. adding new warnings is allowed, and the representation issue would be "just a bug to be fixed." Nonetheless I I do I do want I do want to fix.)
Change:
let aux_dir = self.aux_output_dir(); self.build_all_auxiliary(&self.testpaths, &aux_dir, &mut rustc); <del> self.props.unset_rustc_env.iter().fold(&mut rustc, Command::env_remove); </del> rustc.envs(self.props.rustc_env.clone()); <ins> self.props.unset_rustc_env.iter().fold(&mut rustc, Command::env_remove); </ins> self.compose_and_run( rustc, self.config.compile_lib_path.to_str().unwrap(),

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
CommaRecoveryMode::LikelyTuple, ) }) <del> .is_ok())) && !matches!(self.token.kind, token::ModSep | token::RArrow) { error.span_suggestion_verbose( prev_token_before_parsing.span, format!( "consider removing the `::` here to {}", match style { PathStyle::Expr => "call the expression", PathStyle::Pat => "turn this into a tuple struct pattern", _ => { return; } } ), "", Applicability::MaybeIncorrect, ); </del> <ins> .map_err(|error| error.cancel()) => {} _ => { return; } </ins> } <ins> if let token::ModSep | token::RArrow = self.token.kind { return; } error.span_suggestion_verbose( prev_token_before_parsing.span, format!( "consider removing the `::` here to {}", match style { PathStyle::Expr => "call the expression", PathStyle::Pat => "turn this into a tuple struct pattern", _ => { return; } } ), "", Applicability::MaybeIncorrect, ); </ins> } /// Parses generic args (within a path segment) with recovery for extra leading angle brackets.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Ah, of course, we want to the returned by .
I will try to remedy the situation. claim
Change:
if let LinkerFlavor::Gcc = flavor { match ld_impl { LdImpl::Lld => { <del> let tools_path = sess.get_tools_search_paths(false); let gcc_ld_dir = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .find(|p| { p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }).exists() }) .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found")); cmd.arg({ let mut arg = OsString::from("-B"); arg.push(gcc_ld_dir); arg }); cmd.arg(format!("-Wl,-rustc-lld-flavor={}", sess.target.lld_flavor.as_str())); </del> <ins> // Implement the "self-contained" part of -Zgcc-ld // by adding rustc distribution directories to the tool search path. for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B"); arg.push(path.join("gcc-ld")); arg }); } // Implement the "linker flavor" part of -Zgcc-ld // by asking cc to use some kind of lld. cmd.arg("-fuse-ld=lld"); if sess.target.lld_flavor != LldFlavor::Ld { // Tell clang to use a non-default LLD flavor. // Gcc doesn't understand the target option, but we currently assume // that gcc is not used for Apple and Wasm targets (#97402). cmd.arg(format!("--target={}", sess.target.llvm_target)); } </ins> } } } else {

Discussion:
lld-wrapper is unhappy. I tried this code: Instead, this happened: <!-- 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</detailsNote that this worked for months. This is a regression for me.
Is this issue related to ?
I found no traces of the last working nightly.
Is this issue related to It's certainly somehow related because didn't exist before that, but I don't know how it can happen, is in fact passed as snipped posted in the original message shows.
Do you need more information?
Do you need more information? Yes, output of lld-wrapper with inserted here (You don't need whole compiler build to rebuild lld-wrapper, it's a single-file standalone program, it can be built with directly or with , and then temporarily put into the directory.)
Note that main:rs73 is the failure case.
I see. The command line is to long so it's moved to a temporary file and passed with . Neither lld-wrapper nor original (flavorless) lld support specifying the flavor inside the file. Due to the way in which and work for naked LLD never gets into the file, we should do something similar with too.
I don't know whether rustc has utilities for handling response files
Ok, it's actually clang that packs the command line into a , not rustc, so we cannot control or predict when it happens. That's pretty bad. I guess we'll have to partially revert and use something based on file names, like
Fixed in Sorry for the delay, I should have fixed this two months ago. could you test the fix on Darwin?
Change:
use std::fs::File; use std::io; use std::iter; <ins> use std::mem::ManuallyDrop; </ins> use std::path::Path; use std::slice; use std::sync::Arc;

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
fn try_remap_cnum(&self, tcx: TyCtxt<'_>, cnum: u32) -> Option<CrateNum> { let cnum_map = self.cnum_map.get_or_init(|| Self::compute_cnum_map(tcx, &self.prev_cnums[..])); <ins> debug!("try_remap_cnum({}): cnum_map={:?}", cnum, cnum_map); </ins> cnum_map[CrateNum::from_u32(cnum)] }

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
* `begin_unwind` : ___Needs filling in___ <ins> * `managed_bound` : This type implements "managed" </ins> * `no_copy_bound` : This type does not implement "copy", even if eligible * `no_send_bound` : This type does not implement "send", even if eligible <del> * `no_sync_bound` : This type does not implement "sync", even if eligible * `managed_bound` : This type implements "managed" </del> <ins> * `no_share_bound` : This type does not implement "share", even if eligible </ins> * `eh_personality` : ___Needs filling in___ * `exchange_free`

Discussion:
Lists of items on the std docs should be sorted in some fashion. Alphabetical sorting throughout may not be desirable but I thought I should list all of them here anyway. If other sorting methods are better, I could create more categories. Lists which are sorted alphabetically: [x] [x] In : managedbound should be first.
Change:
} } <del> pub fn compare_const_vals(a: &ConstVal, b: &ConstVal, ty: Ty) -> Option<Ordering> { </del> <ins> pub fn compare_const_vals<'a, 'tcx>( tcx: TyCtxt<'a, 'tcx, 'tcx>, a: &ConstVal, b: &ConstVal, ty: Ty<'tcx>, ) -> Option<Ordering> { </ins> use rustc_const_math::ConstFloat; trace!("compare_const_vals: {:?}, {:?}", a, b); use rustc::mir::interpret::{Value, PrimVal};

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:
fn main() { println!("{}", std::mem:size_of::<BTreeMap<u32, u32>>()); <del> //~^ ERROR expected token: `,` </del> <ins> //~^ 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:
$$(eval $$(call DEF_PREPARE,osx-$(1))) dist-prepare-osx-$(1): PREPARE_HOST=$(1) <del> dist-prepare-osx-$(1): PREPARE_TARGETS=$(1) </del> <ins> dist-prepare-osx-$(1): PREPARE_TARGETS=$(2) </ins> dist-prepare-osx-$(1): PREPARE_DEST_DIR=tmp/dist/pkgroot-$(1) dist-prepare-osx-$(1): PREPARE_DIR_CMD=$(DEFAULT_PREPARE_DIR_CMD) dist-prepare-osx-$(1): PREPARE_BIN_CMD=$(DEFAULT_PREPARE_BIN_CMD)

Discussion:
Currently, Servo uses snapshots generated from . This works great for self-targeting builds, but there's no support today for generating cross-compilation snapshots. This feature is required to support Servo Android test machines on Travis CI. I see that handles cross-compilation: It would be great if there were a different (?), too, to support this scenario.
If I went ahead and created such a target, is that something you would be open to?
Sounds reasonable to me!
I've started the patch to do this. There is some existing cruft from somebody making a similar half-fix previously that needs to be deleted. Doing it right I will involve switching the default behavior to package all targets, leaving the current behavior as a special case for our bots, which means we need to update the bots. It looks pretty easy though and I hope to have it done tomorrow.
Thanks! That explains the confusion I had - I kept getting halfway through it and then getting very confused because it looked like it should be doing what I wanted already.