Question:
<!-- 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. --: The same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- 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 --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing

<ins> struct Checked<const F: fn(usize) -> bool>; //~^ ERROR function pointers as const generic parameters is forbidden fn not_one(val: usize) -> bool { val != 1 } const _: Checked<not_one> = Checked::<not_one>; fn main() {} </ins>


Question:
<!-- 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. --: The same problem is reproduced by rustc 1.76.0-nightly ( 2023-11-24). <!-- 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 --
Oo this looks like but it's much smaller and doesn't need any features.
searched nightlies: from nightly-2023-01-01 to nightly-2023-11-20 regressed nightly: nightly-2023-09-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
So that would be then. The panic originates .
After that error, something is still trying to create a valtree from a function pointer, it seems. I'd say that's a bug, my PR just turns it into an ICE -- but silencing the ICE does not fix the bug. Certain errors need to stop rustc from doing any further work with the faulty code. Cc
Can we turn it into a Constkind::Error instead of ICEing?
I mean we could I guess, though it seems suspicious to me that we even call this function after the type checker already determined that this is not valid as a const generic.
We check the type of const parameters separately from when we compute them. Not doing so results in query cycles iirc :thinking: so it's probably best to somewhere here instead of ICEing

<ins> error: using function pointers as const generic parameters is forbidden --> $DIR/ice-118285-fn-ptr-value.rs:1:25 | LL | struct Checked<const F: fn(usize) -> bool>; |                         ^^^^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` error: aborting due to 1 previous error </ins>


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

} } } else { <del> if matches!(def_kind, DefKind::AnonConst) && tcx.features().generic_const_exprs { let hir_id = tcx.local_def_id_to_hir_id(def_id); let parent_def_id = tcx.hir().get_parent_item(hir_id); if let Some(defaulted_param_def_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here. // (See comment in `generics_of` for more information on why the parent shenanigans is necessary) // // struct Foo<T, const N: usize = { <T as Trait>::ASSOC }>(T) where T: Trait; //        ^^^                     ^^^^^^^^^^^^^^^^^^^^^^^ the def id we are calling //        ^^^                                             explicit_predicates_of on //        parent item we dont have set as the //        parent of generics returned by `generics_of` // // In the above code we want the anon const to have predicates in its param env for `T: Trait` // and we would be calling `explicit_predicates_of(Foo)` here let parent_preds = tcx.explicit_predicates_of(parent_def_id); // If we dont filter out `ConstArgHasType` predicates then every single defaulted const parameter // will ICE because of #106994. FIXME(generic_const_exprs): remove this when a more general solution // to #106994 is implemented. let filtered_predicates = parent_preds .predicates .into_iter() .filter(|(pred, _)| { if let ty::ClauseKind::ConstArgHasType(ct, _) = pred.kind().skip_binder() { match ct.kind() { ty::ConstKind::Param(param_const) => { let defaulted_param_idx = tcx .generics_of(parent_def_id) .param_def_id_to_index[&defaulted_param_def_id.to_def_id()]; param_const.index < defaulted_param_idx } _ => bug!( "`ConstArgHasType` in `predicates_of` that isn't a `Param` const" ), </del> <ins> if matches!(def_kind, DefKind::AnonConst) && tcx.features().generic_const_exprs && let Some(defaulted_param_def_id) = tcx.hir().opt_const_param_default_param_def_id(tcx.local_def_id_to_hir_id(def_id)) { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here. // (See comment in `generics_of` for more information on why the parent shenanigans is necessary) // // struct Foo<T, const N: usize = { <T as Trait>::ASSOC }>(T) where T: Trait; //        ^^^                     ^^^^^^^^^^^^^^^^^^^^^^^ the def id we are calling //        ^^^                                             explicit_predicates_of on //        parent item we dont have set as the //        parent of generics returned by `generics_of` // // In the above code we want the anon const to have predicates in its param env for `T: Trait` // and we would be calling `explicit_predicates_of(Foo)` here let parent_def_id = tcx.local_parent(def_id); let parent_preds = tcx.explicit_predicates_of(parent_def_id); // If we dont filter out `ConstArgHasType` predicates then every single defaulted const parameter // will ICE because of #106994. FIXME(generic_const_exprs): remove this when a more general solution // to #106994 is implemented. let filtered_predicates = parent_preds .predicates .into_iter() .filter(|(pred, _)| { if let ty::ClauseKind::ConstArgHasType(ct, _) = pred.kind().skip_binder() { match ct.kind() { ty::ConstKind::Param(param_const) => { let defaulted_param_idx = tcx .generics_of(parent_def_id) .param_def_id_to_index[&defaulted_param_def_id.to_def_id()]; param_const.index < defaulted_param_idx </ins> } <del> } else { true </del> <ins> _ => bug!( "`ConstArgHasType` in `predicates_of` that isn't a `Param` const" ), </ins> } <del> }) .cloned(); return GenericPredicates { parent: parent_preds.parent, predicates: { tcx.arena.alloc_from_iter(filtered_predicates) }, }; } let parent_def_kind = tcx.def_kind(parent_def_id); if matches!(parent_def_kind, DefKind::OpaqueTy) { // In `instantiate_identity` we inherit the predicates of our parent. // However, opaque types do not have a parent (see `gather_explicit_predicates_of`), which means // that we lose out on the predicates of our actual parent if we dont return those predicates here. // // // fn foo<T: Trait>() -> impl Iterator<Output = Another<{ <T as Trait>::ASSOC }> > { todo!() } //                                                        ^^^^^^^^^^^^^^^^^^^ the def id we are calling //                                                                            explicit_predicates_of on // // In the above code we want the anon const to have predicates in its param env for `T: Trait`. // However, the anon const cannot inherit predicates from its parent since it's opaque. // // To fix this, we call `explicit_predicates_of` directly on `foo`, the parent's parent. // In the above example this is `foo::{opaque#0}` or `impl Iterator` let parent_hir_id = tcx.local_def_id_to_hir_id(parent_def_id.def_id); // In the above example this is the function `foo` let item_def_id = tcx.hir().get_parent_item(parent_hir_id); // In the above code example we would be calling `explicit_predicates_of(foo)` here return tcx.explicit_predicates_of(item_def_id); } </del> <ins> } else { true } }) .cloned(); return GenericPredicates { parent: parent_preds.parent, predicates: { tcx.arena.alloc_from_iter(filtered_predicates) }, }; </ins> } gather_explicit_predicates_of(tcx, def_id) }


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

<del> //@ known-bug: #118403 #![feature(generic_const_exprs)] pub struct X<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { (0..1).map(move |_| (0..1).map(move |_| loop {})) } } </del>


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

<del> //@ known-bug: #121574 #![feature(generic_const_exprs)] pub struct DimName<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { "0".as_bytes(move |_| (0..1).map(move |_| loop {})) } } </del>


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

<del> //@ known-bug: #121574 #![feature(generic_const_exprs)] impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> {} } </del>


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

<ins> //@ check-pass #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use pub fn y<'a, U: 'a>() -> impl IntoIterator<Item = impl IntoIterator<Item = [u8; { 1 + 2 }]> + 'a> { [[[1, 2, 3]]] } // Make sure that the `predicates_of` for `{ 1 + 2 }` don't mention the duplicated lifetimes of // the *outer* iterator. Whether they should mention the duplicated lifetimes of the *inner* // iterator are another question, but not really something we need to answer immediately. fn main() {} </ins>


Question:
<!-- 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
Is this a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.

<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/double-opaque-parent-predicates.rs:3:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>


Question:
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

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;


Question:
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

let llcx = llvm::LLVMRustContextCreate(cgcx.fewer_names); let llmod_raw = parse_module(llcx, module_name, thin_module.data(), &diag_handler)? as *const _; let mut module = ModuleCodegen { <del> module_llvm: ModuleLlvm { llmod_raw, llcx, tm }, </del> <ins> module_llvm: ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }, </ins> name: thin_module.name().to_string(), kind: ModuleKind::Regular, };


Question:
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

use std::any::Any; use std::ffi::CStr; use std::io::Write; <ins> use std::mem::ManuallyDrop; </ins> mod back { pub mod archive;


Question:
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

llcx: &'static mut llvm::Context, llmod_raw: *const llvm::Module, <del> // independent from llcx and llmod_raw, resources get disposed by drop impl tm: OwnedTargetMachine, </del> <ins> // This field is `ManuallyDrop` because it is important that the `TargetMachine` // is disposed prior to the `Context` being disposed otherwise UAFs can occur. tm: ManuallyDrop<OwnedTargetMachine>, </ins> } unsafe impl Send for ModuleLlvm {}


Question:
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

unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_target_machine(tcx, mod_name) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_target_machine(tcx, mod_name)), } </ins> } }


Question:
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

unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_informational_target_machine(tcx.sess) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_informational_target_machine(tcx.sess)), } </ins> } }


Question:
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

} }; <del> Ok(ModuleLlvm { llmod_raw, llcx, tm }) </del> <ins> Ok(ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(tm) }) </ins> } }


Question:
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

impl Drop for ModuleLlvm { fn drop(&mut self) { unsafe { <ins> ManuallyDrop::drop(&mut self.tm); </ins> llvm::LLVMContextDispose(&mut *(self.llcx as *mut _)); } }


Question:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

// current number of evaluated terminators is a power of 2. The latter gives us a cheap // way to implement exponential backoff. let span = ecx.cur_span(); <del> ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span }); </del> <ins> // We store a unique number in `force_duplicate` to evade `-Z deduplicate-diagnostics`. // `new_steps` is guaranteed to be unique because `ecx.machine.num_evaluated_steps` is // always increasing. ecx.tcx.dcx().emit_warn(LongRunningWarn { span, item_span: ecx.tcx.span, force_duplicate: new_steps, }); </ins> } }


Question:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

pub span: Span, #[help] pub item_span: Span, <ins> // Used for evading `-Z deduplicate-diagnostics`. pub force_duplicate: usize, </ins> } #[derive(Subdiagnostic)]


Question:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

<ins> //@ check-pass #![allow(long_running_const_eval)] //@ compile-flags: -Z tiny-const-eval-limit -Z deduplicate-diagnostics=yes const FOO: () = { let mut i = 0; loop { //~^ WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time //~| WARN is taking a long time if i == 1000 { break; } else { i += 1; } } }; fn main() { FOO } </ins>


Question:
I tried the following code: output after running for a very long time: modify rustc as follows results in the following output: changing the invocation to actually prints the warning at each power of two of steps. This warning should not be affected by . It's whole point is to be repeated multiple times. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I honestly don't remember if we want it to be repeated or not. Is there even a way for a single diagnostic to opt-out of deduplication? I guess we could put some number into the error message so that it's not the exact same diagnostic each time.
yes, we have full ownership of rustc, we can the deduplication code to stop duplicating this single warning while keeping everything else the same :grin:
claim

<ins> warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: constant evaluation is taking a long time --> $DIR/evade-deduplication-issue-118612.rs:8:5 | LL | /     loop { LL | | LL | | LL | | ...  | LL | |         } LL | |     } | |_____^ the const evaluator is currently interpreting this expression | help: the constant being evaluated --> $DIR/evade-deduplication-issue-118612.rs:6:1 | LL | const FOO: () = { | ^^^^^^^^^^^^^ warning: 5 warnings emitted </ins>


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

} .item-info .stab { <del> /* This min-height is needed to unify the height of the stab elements because some of them have emojis. */ min-height: 36px; display: flex; </del> <ins> display: block; </ins> padding: 3px; margin-bottom: 5px; <del> align-items: center; vertical-align: text-bottom; </del> } .item-name .stab { margin-left: 0.3125em;


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

color: var(--stab-code-color); } <del> .stab .emoji { </del> <ins> .stab .emoji, .item-info .stab::before { </ins> font-size: 1.25rem; <ins> } .stab .emoji { </ins> margin-right: 0.3rem; } <ins> .item-info .stab::before { /* ensure badges with emoji and without it have same height */ content: "0"; width: 0; display: inline-block; color: transparent; } </ins> /* Black one-pixel outline around emoji shapes */ .emoji { text-shadow: 1px 0 0 black, -1px 0 0 black, <del> 0  1px 0 black, </del> <ins> 0 1px 0 black, </ins> 0 -1px 0 black; }


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

assert-size: (".item-info .stab", {"width": 289}) assert-position: (".item-info .stab", {"x": 245}) <ins> // We check that the display of the feature elements is not broken. It serves as regression // test for <https://github.com/rust-lang/rust/issues/118615>. set-window-size: (850, 800) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System']", {"x": first_line_x, "y": first_line_y}, ) store-position: ( "//*[@class='stab portability']//code[text()='Win32_System_Diagnostics']", {"x": second_line_x, "y": second_line_y}, ) assert: |first_line_x| != |second_line_x| && |first_line_x| == 516 && |second_line_x| == 272 assert: |first_line_y| != |second_line_y| && |first_line_y| == 688 && |second_line_y| == 711 </ins> // Now we ensure that they're not rendered on the same line. <ins> set-window-size: (1100, 800) </ins> go-to: "file://" + |DOC_PATH| + "/lib2/trait.Trait.html" // We first ensure that there are two item info on the trait. assert-count: ("#main-content > .item-info .stab", 2)


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

[lib] path = "lib.rs" <ins> [features] Win32 = ["Win32_System"] Win32_System = ["Win32_System_Diagnostics"] Win32_System_Diagnostics = ["Win32_System_Diagnostics_Debug"] Win32_System_Diagnostics_Debug = [] default = ["Win32"] </ins> [dependencies] implementors = { path = "./implementors" } http = { path = "./http" }


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

// ignore-tidy-linelength #![feature(doc_cfg)] <ins> #![feature(doc_auto_cfg)] </ins> pub mod another_folder; pub mod another_mod;


Question:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.

/// Some documentation /// # A Heading pub fn a_method(&self) {} <ins> #[cfg(all( feature = "Win32", feature = "Win32_System", feature = "Win32_System_Diagnostics", feature = "Win32_System_Diagnostics_Debug" ))] pub fn lot_of_features() {} </ins> } #[doc(cfg(feature = "foo-method"))]


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

return; } }; <del> let (sig, map) = tcx.instantiate_bound_regions(sig, |br| { </del> <ins> let (unnormalized_sig, map) = tcx.instantiate_bound_regions(sig, |br| { </ins> use crate::renumber::RegionCtxt; let region_ctxt_fn = || {


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

region_ctxt_fn, ) }); <del> debug!(?sig); </del> <ins> debug!(?unnormalized_sig); </ins> // IMPORTANT: We have to prove well formed for the function signature before // we normalize it, as otherwise types like `<&'a &'b () as Trait>::Assoc` // get normalized away, causing us to ignore the `'b: 'a` bound used by the function.


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

// // See #91068 for an example. self.prove_predicates( <del> sig.inputs_and_output.iter().map(|ty| { </del> <ins> unnormalized_sig.inputs_and_output.iter().map(|ty| { </ins> ty::Binder::dummy(ty::PredicateKind::Clause(ty::ClauseKind::WellFormed( ty.into(), )))


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

term_location.to_locations(), ConstraintCategory::Boring, ); <del> let sig = self.normalize(sig, term_location); </del> <ins> let sig = self.normalize(unnormalized_sig, term_location); // HACK(#114936): `WF(sig)` does not imply `WF(normalized(sig))` // with built-in `Fn` implementations, since the impl may not be // well-formed itself. if sig != unnormalized_sig { self.prove_predicates( sig.inputs_and_output.iter().map(|ty| { ty::Binder::dummy(ty::PredicateKind::Clause( ty::ClauseKind::WellFormed(ty.into()), )) }), term_location.to_locations(), ConstraintCategory::Boring, ); } </ins> self.check_call_dest(body, term, &sig, *destination, *target, term_location); // The ordinary liveness rules will ensure that all


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

<ins> // <https://github.com/rust-lang/rust/issues/114936> fn whoops( s: String, f: impl for<'s> FnOnce(&'s str) -> (&'static str, [&'static &'s (); 0]), ) -> &'static str { f(&s).0 //~^ ERROR `s` does not live long enough } // <https://github.com/rust-lang/rust/issues/118876> fn extend<T>(input: &T) -> &'static T { struct Bounded<'a, 'b: 'static, T>(&'a T, [&'b (); 0]); let n: Box<dyn FnOnce(&T) -> Bounded<'static, '_, T>> = Box::new(|x| Bounded(x, [])); n(input).0 //~^ ERROR borrowed data escapes outside of function } // <https://github.com/rust-lang/rust/issues/118876> fn extend_mut<'a, T>(input: &'a mut T) -> &'static mut T { struct Bounded<'a, 'b: 'static, T>(&'a mut T, [&'b (); 0]); let mut n: Box<dyn FnMut(&mut T) -> Bounded<'static, '_, T>> = Box::new(|x| Bounded(x, [])); n(input).0 //~^ ERROR borrowed data escapes outside of function } fn main() {} </ins>


Question:
<!-- 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. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: 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. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

<ins> error[E0597]: `s` does not live long enough --> $DIR/check-normalized-sig-for-wf.rs:7:7 | LL |     s: String, |     - binding `s` declared here ... LL |     f(&s).0 |     --^^- |     | | |     | borrowed value does not live long enough |     argument requires that `s` is borrowed for `'static` LL | LL | } | - `s` dropped here while still borrowed error[E0521]: borrowed data escapes outside of function --> $DIR/check-normalized-sig-for-wf.rs:15:5 | LL | fn extend<T>(input: &T) -> &'static T { |              -----  - let's call the lifetime of this reference `'1` |              | |              `input` is a reference that is only valid in the function body ... LL |     n(input).0 |     ^^^^^^^^ |     | |     `input` escapes the function body here |     argument requires that `'1` must outlive `'static` error[E0521]: borrowed data escapes outside of function --> $DIR/check-normalized-sig-for-wf.rs:23:5 | LL | fn extend_mut<'a, T>(input: &'a mut T) -> &'static mut T { |               --     ----- `input` is a reference that is only valid in the function body |               | |               lifetime `'a` defined here ... LL |     n(input).0 |     ^^^^^^^^ |     | |     `input` escapes the function body here |     argument requires that `'a` must outlive `'static` error: aborting due to 3 previous errors Some errors have detailed explanations: E0521, E0597. For more information about an error, try `rustc --explain E0521`. </ins>


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

id: NodeId, parent_prefix: &[Segment], nested: bool, <ins> list_stem: bool, </ins> // The whole `use` item item: &Item, vis: ty::Visibility,


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

parent_prefix, use_tree, nested ); <del> if nested { </del> <ins> // Top level use tree reuses the item's id and list stems reuse their parent // use tree's ids, so in both cases their visibilities are already filled. if nested && !list_stem { </ins> self.r.feed_visibility(self.r.local_def_id(id), vis); }


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

for &(ref tree, id) in items { self.build_reduced_graph_for_use_tree( // This particular use tree <del> tree, id, &prefix, true, // The whole `use` item </del> <ins> tree, id, &prefix, true, false, // The whole `use` item </ins> item, vis, root_span, ); }


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

id, &prefix, true, <ins> true, </ins> // The whole `use` item item, ty::Visibility::Restricted(


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

item.id, &[], false, <ins> false, </ins> // The whole `use` item item, vis,


Question:
I have a that has started to fail running clippy, due to a compiler error compiling wayland-protocols. The dependency chain is down from iced thru "clipboardwayland" (0.2.0) to "smithay-clipboard" (0.6.6) and to "wayland-protocols" v0.29.5 "clipboardwayland" 0.2.0 is the latest version on , but it depends on "smithay-clipboard" 0.6.6, while 0.7.0 is the latest version on wayland-protocols 0.29.5 : See also: </p</details
Ruffle is running into this same ICE with wayland-protocols:
minimized:
searched nightlies: from nightly-2023-12-17 to nightly-2023-12-19 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
cc for the bisection
~This snippet doesn't reproduce the ICE.~ Upd: sorry, it does, on 2018+ edition.
Fixed in
After being released to nightly yesterday, things are back to normal and building. Thanks!

<ins> // check-pass // edition: 2018 mod outer { mod inner { pub mod inner2 {} } pub(crate) use inner::{}; pub(crate) use inner::{{}}; pub(crate) use inner::{inner2::{}}; pub(crate) use inner::{inner2::{{}}}; } fn main() {} </ins>


Question:
<!-- 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. -- In particular, this also happens 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?

/// Whether the layout is from a type that implements [`std::marker::PointerLike`]. /// /// Currently, that means that the type is pointer-sized, pointer-aligned, <del> /// and has a scalar ABI. </del> <ins> /// and has a initialized (non-union), scalar ABI. </ins> pub fn is_pointer_like(self, data_layout: &TargetDataLayout) -> bool { self.size() == data_layout.pointer_size && self.align().abi == data_layout.pointer_align.abi <del> && matches!(self.abi(), Abi::Scalar(..)) </del> <ins> && matches!(self.abi(), Abi::Scalar(Scalar::Initialized { .. })) </ins> } }


Question:
<!-- 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. -- In particular, this also happens 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?

<ins> #![feature(dyn_star)] //~^ WARN the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes union Union { x: usize, } trait Trait {} impl Trait for Union {} fn bar(_: dyn* Trait) {} fn main() { bar(Union { x: 0usize }); //~^ ERROR `Union` needs to have the same ABI as a pointer } </ins>


Question:
<!-- 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. -- In particular, this also happens 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label F-dyn_star requires-nightly
Regression in nightly-2022-10-16 found 7 bors merge commits in the specified range commit[0] 2022-10-14: Auto merge of - woppopo:const_location, r=scottmcm commit[1] 2022-10-14: Auto merge of - matthiaskrgr:rollup-xxsx6sk, r=matthiaskrgr commit[2] 2022-10-15: Auto merge of - joshtriplett:is-terminal-fd-handle, r=thomcc commit[3] 2022-10-15: Auto merge of - Aaron1011:stability-use-tree, r=cjgillot commit[4] 2022-10-15: Auto merge of - compiler-errors:dyn-star-plus, r=eholk commit[5] 2022-10-15: Auto merge of - Dylan-DPC:rollup-97cvwdv, r=Dylan-DPC commit[6] 2022-10-15: Auto merge of - Nilstrieb:query-cleanups, r=cjgillot ERROR: no CI builds available between and within last 167 days maybe ?

<ins> warning: the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/union.rs:1:12 | LL | #![feature(dyn_star)] |            ^^^^^^^^ | = note: see issue #102425 <https://github.com/rust-lang/rust/issues/102425> for more information = note: `#[warn(incomplete_features)]` on by default error[E0277]: `Union` needs to have the same ABI as a pointer --> $DIR/union.rs:14:9 | LL |     bar(Union { x: 0usize }); |         ^^^^^^^^^^^^^^^^^^^ `Union` needs to be a pointer-like type | = help: the trait `PointerLike` is not implemented for `Union` error: aborting due to 1 previous error; 1 warning emitted For more information about this error, try `rustc --explain E0277`. </ins>


Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

- [wasm32-wasip1](platform-support/wasm32-wasip1.md) - [wasm32-wasip1-threads](platform-support/wasm32-wasip1-threads.md) - [wasm32-wasip2](platform-support/wasm32-wasip2.md) <ins> - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md) </ins> - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md) - [*-win7-windows-msvc](platform-support/win7-windows-msvc.md) - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)


Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

[`thumbv8m.main-none-eabi`](platform-support/thumbv8m.main-none-eabi.md) | * | Bare Armv8-M Mainline [`thumbv8m.main-none-eabihf`](platform-support/thumbv8m.main-none-eabi.md) | * | Bare Armv8-M Mainline, hardfloat `wasm32-unknown-emscripten` | ✓ | WebAssembly via Emscripten <del> `wasm32-unknown-unknown` | ✓ | WebAssembly </del> <ins> [`wasm32-unknown-unknown`](platform-support/wasm32-unknown-unknown.md) | ✓ | WebAssembly </ins> `wasm32-wasi` | ✓ | WebAssembly with WASI (undergoing a [rename to `wasm32-wasip1`][wasi-rename]) [`wasm32-wasip1`](platform-support/wasm32-wasip1.md) | ✓ | WebAssembly with WASI [`wasm32-wasip1-threads`](platform-support/wasm32-wasip1-threads.md) | ✓ | WebAssembly with WASI Preview 1 and threads


Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

<ins> # `wasm32-unknown-unknown` **Tier: 2** The `wasm32-unknown-unknown` target is a WebAssembly compilation target which does not import any functions from the host for the standard library. This is the "minimal" WebAssembly in the sense of making the fewest assumptions about the host environment. This target is often used when compiling to the web or JavaScript environments as there is no standard for what functions can be imported on the web. This target can also be useful for creating minimal or bare-bones WebAssembly binaries. The `wasm32-unknown-unknown` target has support for the Rust standard library but many parts of the standard library do not work and return errors. For example `println!` does nothing, `std::fs` always return errors, and `std::thread::spawn` will panic. There is no means by which this can be overridden. For a WebAssembly target that more fully supports the standard library see the [`wasm32-wasip1`](./wasm32-wasip1.md) or [`wasm32-wasip2`](./wasm32-wasip2.md) targets. The `wasm32-unknown-unknown` target has full support for the `core` and `alloc` crates. It additionally supports the `HashMap` type in the `std` crate, although hash maps are not randomized like they are on other platforms. One existing user of this target (please feel free to edit and expand this list too) is the [`wasm-bindgen` project](https://github.com/rustwasm/wasm-bindgen) which facilitates Rust code interoperating with JavaScript code. Note, though, that not all uses of `wasm32-unknown-unknown` are using JavaScript and the web. ## Target maintainers When this target was added to the compiler platform-specific documentation here was not maintained at that time. This means that the list below is not exhaustive and there are more interested parties in this target. That being said since when this document was last updated those interested in maintaining this target are: - Alex Crichton, https://github.com/alexcrichton ## Requirements This target is cross-compiled. The target includes support for `std` itself, but as mentioned above many pieces of functionality that require an operating system do not work and will return errors. This target currently has no equivalent in C/C++. There is no C/C++ toolchain for this target. While interop is theoretically possible it's recommended to instead use one of: * `wasm32-unknown-emscripten` - for web-based use cases the Emscripten toolchain is typically chosen for running C/C++. * [`wasm32-wasip1`](./wasm32-wasip1.md) - the wasi-sdk toolchain is used to compile C/C++ on this target and can interop with Rust code. WASI works on the web so far as there's no blocker, but an implementation of WASI APIs must be either chosen or reimplemented. This target has no build requirements beyond what's in-tree in the Rust repository. Linking binaries requires LLD to be enabled for the `wasm-ld` driver. This target uses the `dlmalloc` crate as the default global allocator. ## Building the target Building this target can be done by: * Configure the `wasm32-unknown-unknown` target to get built. * Configure LLD to be built. * Ensure the `WebAssembly` target backend is not disabled in LLVM. These are all controlled through `config.toml` options. It should be possible to build this target on any platform. ## Building Rust programs Rust programs can be compiled by adding this target via rustup: ```sh $ rustup target add wasm32-unknown-unknown ``` and then compiling with the target: ```sh $ rustc foo.rs --target wasm32-unknown-unknown $ file foo.wasm ``` ## Cross-compilation This target can be cross-compiled from any host. ## Testing This target is not tested in CI for the rust-lang/rust repository. Many tests must be disabled to run on this target and failures are non-obvious because `println!` doesn't work in the standard library. It's recommended to test the `wasm32-wasip1` target instead for WebAssembly compatibility. ## Conditionally compiling code It's recommended to conditionally compile code for this target with: ```text #[cfg(all(target_family = "wasm", target_os = "unknown"))] ``` Note that there is no way to tell via `#[cfg]` whether code will be running on the web or not. ## Enabled WebAssembly features WebAssembly is an evolving standard which adds new features such as new instructions over time. This target's default set of supported WebAssembly features will additionally change over time. The `wasm32-unknown-unknown` target inherits the default settings of LLVM which typically matches the default settings of Emscripten as well. Changes to WebAssembly go through a [proposals process][proposals] but reaching the final stage (stage 5) does not automatically mean that the feature will be enabled in LLVM and Rust by default. At this time the general guidance is that features must be present in most engines for a "good chunk of time" before they're enabled in LLVM by default. There is currently no exact number of months or engines that are required to enable features by default. [proposals]: https://github.com/WebAssembly/proposals As of the time of this writing the proposals that are enabled by default (the `generic` CPU in LLVM terminology) are: * `multivalue` * `mutable-globals` * `reference-types` * `sign-ext` If you're compiling WebAssembly code for an engine that does not support a feature in LLVM's default feature set then the feature must be disabled at compile time. Note, though, that enabled features may be used in the standard library or precompiled libraries shipped via rustup. This means that not only does your own code need to be compiled with the correct set of flags but the Rust standard library additionally must be recompiled. Compiling all code for the initial release of WebAssembly looks like: ```sh $ export RUSTFLAGS=-Ctarget-cpu=mvp $ cargo +nightly build -Zbuild-std=panic_abort,std --target wasm32-unknown-unknown ``` Here the `mvp` "cpu" is a placeholder in LLVM for disabling all supported features by default. Cargo's `-Zbuild-std` feature, a Nightly Rust feature, is then used to recompile the standard library in addition to your own code. This will produce a binary that uses only the original WebAssembly features by default and no proposals since its inception. To enable individual features it can be done with `-Ctarget-feature=+foo`. Available features for Rust code itself are documented in the [reference] and can also be found through: ```sh $ rustc -Ctarget-feature=help --target wasm32-unknown-unknown ``` You'll need to consult your WebAssembly engine's documentation to learn more about the supported WebAssembly features the engine has. [reference]: https://doc.rust-lang.org/reference/attributes/codegen.html#wasm32-or-wasm64 Note that it is still possible for Rust crates and libraries to enable WebAssembly features on a per-function level. This means that the build command above may not be sufficient to disable all WebAssembly features. If the final binary still has SIMD instructions, for example, the function in question will need to be found and the crate in question will likely contain something like: ```rust,ignore (not-always-compiled-to-wasm) #[target_feature(enable = "simd128")] fn foo() { // ... } ``` In this situation there is no compiler flag to disable emission of SIMD instructions and the crate must instead be modified to not include this function at compile time either by default or through a Cargo feature. For crate authors it's recommended to avoid `#[target_feature(enable = "...")]` except where necessary and instead use: ```rust,ignore (not-always-compiled-to-wasm) #[cfg(target_feature = "simd128")] fn foo() { // ... } ``` That is to say instead of enabling target features it's recommended to conditionally compile code instead. This is notably different to the way native platforms such as x86_64 work, and this is due to the fact that WebAssembly binaries must only contain code the engine understands. Native binaries work so long as the CPU doesn't execute unknown code dynamically at runtime. </ins>