Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

[[package]] name = "jsonrpc-core" <del> version = "13.1.0" </del> <ins> version = "13.2.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "dd42951eb35079520ee29b7efbac654d85821b397ef88c8151600ef7e2d00217" </del> <ins> checksum = "91d767c183a7e58618a609499d359ce3820700b3ebb4823a18c343b4a2a41a0d" </ins> dependencies = [ "futures", "log",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

[[package]] name = "rls" <del> version = "1.39.0" </del> <ins> version = "1.40.0" </ins> dependencies = [ "cargo", "cargo_metadata 0.8.0", "clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.0", </ins> "failure", "futures", "heck",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

"num_cpus", "ordslice", "racer", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rayon", "regex", "rls-analysis",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

"rls-rustc", "rls-span", "rls-vfs", <del> "rustc-serialize", </del> "rustc-workspace-hack", "rustc_tools_util 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustfmt-nightly",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

version = "0.6.0" dependencies = [ "clippy_lints", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.0", </ins> "failure", "futures", "log", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rls-data", "rls-ipc", "serde",


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

] [[package]] <del> name = "rustc-serialize" version = "0.3.24" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "dcf128d1287d2ea9d80910b5f1120d0b8eede3fbf1abe91c40d39ea7d51e6fda" [[package]] </del> name = "rustc-std-workspace-alloc" version = "1.99.0" dependencies = [


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.

<del> Subproject commit a18df16181947edd5eb593ea0f2321e0035448ee </del> <ins> Subproject commit 5db91c7b94ca81eead6b25bcf6196b869a44ece0 </ins>


Question:
Hi there! This is the second time I've compiled code with Rust ever, and my first time filing a bug report, so I may need some guidance if the info here isn't quite enough to work with :). Learning about println! in Rust by Example, I incorrectly entered the below code. I looked at the documentation and realized I had made a mistake, but the compiler still panicked and recommended I open a bug report. I really believe in Rust and want to see this project succeed, hopefully this information is helpful! I tried this code: println!("Pi is roughly: {:.*}, 3, 3.") Expected to see this happen: "Pi is roughly 3.142" Instead, this happened: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', note: run with environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.38.0 ( 2019-09-23) running on x8664-unknown-linux-gnu :rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x8664-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 Backtrace: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::panicking::panicboundscheck at 12: syntaxext::format::expandpreparsedformatargs 13: syntaxext::format::expandformatargsimpl 14: <F as syntax::ext::base::TTMacroExpander::expand 15: syntax::ext::expand::MacroExpander::expandfragment 16: syntax::ext::expand::MacroExpander::expandcrate 17: rustcinterface::passes::configureandexpandinner::{{closure}} 18: rustc::util::common::time 19: rustcinterface::passes::configureandexpandinner 20: rustcinterface::passes::configureandexpand::{{closure}} 21: rustcdatastructures::boxregion::PinnedGenerator<I,A,R::new 22: rustcinterface::passes::configureandexpand 23: rustcinterface::queries::Query<T::compute 24: rustcinterface::queries::<impl rustcinterface::interface::Compiler::expansion 25: rustcinterface::interface::runcompilerinexistingthreadpool 26: std::thread::local::LocalKey<T::with 27: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: end of query stack
This code fails on nightly, beta, and stable. Here's a link to the minimal failing code:
The entirety of the println is a string: So it shouldn't compile,instead it should print this error:
I believe the error is caused in the following line: the correct code would be , but you have encountered a bug in the compiler's diagnostic machinery. The output you should have seen is

format!("are {} arguments", count) }, )); <del> e.span_label( self.args[pos].span, "this parameter corresponds to the precision flag", ); </del> <ins> if let Some(arg) = self.args.get(pos) { e.span_label( arg.span, "this parameter corresponds to the precision flag", ); } </ins> zero_based_note = true; } _ => {}


Question:
Hi there! This is the second time I've compiled code with Rust ever, and my first time filing a bug report, so I may need some guidance if the info here isn't quite enough to work with :). Learning about println! in Rust by Example, I incorrectly entered the below code. I looked at the documentation and realized I had made a mistake, but the compiler still panicked and recommended I open a bug report. I really believe in Rust and want to see this project succeed, hopefully this information is helpful! I tried this code: println!("Pi is roughly: {:.*}, 3, 3.") Expected to see this happen: "Pi is roughly 3.142" Instead, this happened: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', note: run with environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.38.0 ( 2019-09-23) running on x8664-unknown-linux-gnu :rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x8664-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 Backtrace: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::panicking::panicboundscheck at 12: syntaxext::format::expandpreparsedformatargs 13: syntaxext::format::expandformatargsimpl 14: <F as syntax::ext::base::TTMacroExpander::expand 15: syntax::ext::expand::MacroExpander::expandfragment 16: syntax::ext::expand::MacroExpander::expandcrate 17: rustcinterface::passes::configureandexpandinner::{{closure}} 18: rustc::util::common::time 19: rustcinterface::passes::configureandexpandinner 20: rustcinterface::passes::configureandexpand::{{closure}} 21: rustcdatastructures::boxregion::PinnedGenerator<I,A,R::new 22: rustcinterface::passes::configureandexpand 23: rustcinterface::queries::Query<T::compute 24: rustcinterface::queries::<impl rustcinterface::interface::Compiler::expansion 25: rustcinterface::interface::runcompilerinexistingthreadpool 26: std::thread::local::LocalKey<T::with 27: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: end of query stack
This code fails on nightly, beta, and stable. Here's a link to the minimal failing code:
The entirety of the println is a string: So it shouldn't compile,instead it should print this error:
I believe the error is caused in the following line: the correct code would be , but you have encountered a bug in the compiler's diagnostic machinery. The output you should have seen is

println!("{:foo}", 1); //~ ERROR unknown format trait `foo` println!("{5} {:4$} {6:7$}", 1); //~^ ERROR invalid reference to positional arguments 4, 5, 6 and 7 (there is 1 argument) <ins> // We used to ICE here because we tried to unconditionally access the first argument, which // doesn't exist. println!("{:.*}"); //~^ ERROR 2 positional arguments in format string, but no arguments were given </ins> }


Question:
Hi there! This is the second time I've compiled code with Rust ever, and my first time filing a bug report, so I may need some guidance if the info here isn't quite enough to work with :). Learning about println! in Rust by Example, I incorrectly entered the below code. I looked at the documentation and realized I had made a mistake, but the compiler still panicked and recommended I open a bug report. I really believe in Rust and want to see this project succeed, hopefully this information is helpful! I tried this code: println!("Pi is roughly: {:.*}, 3, 3.") Expected to see this happen: "Pi is roughly 3.142" Instead, this happened: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', note: run with environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.38.0 ( 2019-09-23) running on x8664-unknown-linux-gnu :rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x8664-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 Backtrace: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::panicking::panicboundscheck at 12: syntaxext::format::expandpreparsedformatargs 13: syntaxext::format::expandformatargsimpl 14: <F as syntax::ext::base::TTMacroExpander::expand 15: syntax::ext::expand::MacroExpander::expandfragment 16: syntax::ext::expand::MacroExpander::expandcrate 17: rustcinterface::passes::configureandexpandinner::{{closure}} 18: rustc::util::common::time 19: rustcinterface::passes::configureandexpandinner 20: rustcinterface::passes::configureandexpand::{{closure}} 21: rustcdatastructures::boxregion::PinnedGenerator<I,A,R::new 22: rustcinterface::passes::configureandexpand 23: rustcinterface::queries::Query<T::compute 24: rustcinterface::queries::<impl rustcinterface::interface::Compiler::expansion 25: rustcinterface::interface::runcompilerinexistingthreadpool 26: std::thread::local::LocalKey<T::with 27: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: end of query stack
This code fails on nightly, beta, and stable. Here's a link to the minimal failing code:
The entirety of the println is a string: So it shouldn't compile,instead it should print this error:
I believe the error is caused in the following line: the correct code would be , but you have encountered a bug in the compiler's diagnostic machinery. The output you should have seen is

= note: positional arguments are zero-based = note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html <ins> error: 2 positional arguments in format string, but no arguments were given --> $DIR/ifmt-bad-arg.rs:92:15 | LL |     println!("{:.*}"); |               ^^--^ |                 | |                 this precision flag adds an extra required argument at position 0, which is why there are 2 arguments expected | = note: positional arguments are zero-based = note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html </ins> error[E0308]: mismatched types --> $DIR/ifmt-bad-arg.rs:78:32 |


Question:
Hi there! This is the second time I've compiled code with Rust ever, and my first time filing a bug report, so I may need some guidance if the info here isn't quite enough to work with :). Learning about println! in Rust by Example, I incorrectly entered the below code. I looked at the documentation and realized I had made a mistake, but the compiler still panicked and recommended I open a bug report. I really believe in Rust and want to see this project succeed, hopefully this information is helpful! I tried this code: println!("Pi is roughly: {:.*}, 3, 3.") Expected to see this happen: "Pi is roughly 3.142" Instead, this happened: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', note: run with environment variable to display a backtrace. error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.38.0 ( 2019-09-23) running on x8664-unknown-linux-gnu :rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x8664-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 Backtrace: thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', stack backtrace: 0: backtrace::backtrace::libunwind::trace at 1: backtrace::backtrace::traceunsynchronized at 2: std::syscommon::backtrace::print at 3: std::syscommon::backtrace::print at 4: std::panicking::defaulthook::{{closure}} at 5: std::panicking::defaulthook at 6: rustc::util::common::panichook 7: std::panicking::rustpanicwithhook at 8: std::panicking::continuepanicfmt at 9: rustbeginunwind at 10: core::panicking::panicfmt at 11: core::panicking::panicboundscheck at 12: syntaxext::format::expandpreparsedformatargs 13: syntaxext::format::expandformatargsimpl 14: <F as syntax::ext::base::TTMacroExpander::expand 15: syntax::ext::expand::MacroExpander::expandfragment 16: syntax::ext::expand::MacroExpander::expandcrate 17: rustcinterface::passes::configureandexpandinner::{{closure}} 18: rustc::util::common::time 19: rustcinterface::passes::configureandexpandinner 20: rustcinterface::passes::configureandexpand::{{closure}} 21: rustcdatastructures::boxregion::PinnedGenerator<I,A,R::new 22: rustcinterface::passes::configureandexpand 23: rustcinterface::queries::Query<T::compute 24: rustcinterface::queries::<impl rustcinterface::interface::Compiler::expansion 25: rustcinterface::interface::runcompilerinexistingthreadpool 26: std::thread::local::LocalKey<T::with 27: syntax::withglobals note: Some details are omitted, run with for a verbose backtrace. query stack during panic: end of query stack
This code fails on nightly, beta, and stable. Here's a link to the minimal failing code:
The entirety of the println is a string: So it shouldn't compile,instead it should print this error:
I believe the error is caused in the following line: the correct code would be , but you have encountered a bug in the compiler's diagnostic machinery. The output you should have seen is

= note: expected type `&usize` found type `&{float}` <del> error: aborting due to 35 previous errors </del> <ins> error: aborting due to 36 previous errors </ins> For more information about this error, try `rustc --explain E0308`.


Question:
When trying to compile the following code, a panic occurs on :
Also happens on nightly
ICE reproduces all the way back to 1.36.0; before that, it still ICEs but in a different place.
Maximal reduction: ICE arises in: Blame: cc
I suspect this is a duplicate of . But the test case is slightly different so I'll leave it open for now
triage: P-medium (via analogy with priority on ), removing nomination label.
Triage: This is no longer ICE with the latest nightly:

<ins> use std::mem::size_of; struct Foo<'s> { //~ ERROR: parameter `'s` is never used array: [(); size_of::<&Self>()], //~^ ERROR: generic `Self` types are currently not permitted in anonymous constants } // The below is taken from https://github.com/rust-lang/rust/issues/66152#issuecomment-550275017 // as the root cause seems the same. const fn foo<T>() -> usize { 0 } struct Bar<'a> { //~ ERROR: parameter `'a` is never used beta: [(); foo::<&'a ()>()], //~ ERROR: a non-static lifetime is not allowed in a `const` } fn main() {} </ins>


Question:
When trying to compile the following code, a panic occurs on :
Also happens on nightly
ICE reproduces all the way back to 1.36.0; before that, it still ICEs but in a different place.
Maximal reduction: ICE arises in: Blame: cc
I suspect this is a duplicate of . But the test case is slightly different so I'll leave it open for now
triage: P-medium (via analogy with priority on ), removing nomination label.
Triage: This is no longer ICE with the latest nightly:

<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/issue-64173-unused-lifetimes.rs:16:23 | LL |     beta: [(); foo::<&'a ()>()], |                       ^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = help: add `#![feature(generic_const_exprs)]` to the crate attributes to enable error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/issue-64173-unused-lifetimes.rs:4:28 | LL |     array: [(); size_of::<&Self>()], |                            ^^^^ error[E0392]: parameter `'s` is never used --> $DIR/issue-64173-unused-lifetimes.rs:3:12 | LL | struct Foo<'s> { |            ^^ unused parameter | = help: consider removing `'s`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: parameter `'a` is never used --> $DIR/issue-64173-unused-lifetimes.rs:15:12 | LL | struct Bar<'a> { |            ^^ unused parameter | = help: consider removing `'a`, referring to it in a field, or using a marker such as `PhantomData` error: aborting due to 4 previous errors Some errors have detailed explanations: E0392, E0658. For more information about an error, try `rustc --explain E0392`. </ins>


Question:
It is linked to This is the tests we need to add (the list is non-exhaustive): [x] a UI test for each setting [x] click on element in the sidebar hidden by default to be sure it gets fully un-collapsed and scrolled to [x] make tests for each shortcut [x] make tests for source code navigation (through files in the first time should be enough) [ ] run all the previous tests in mobile mode
I think this issue can now be closed. For the mobile tests, I also think we them where it was necessary.

<ins> // This test ensures that the "Auto-hide item methods' documentation" setting is working as // expected. define-function: ( "check-setting", (storage_value, setting_attribute_value, toggle_attribute_value), block { assert-local-storage: {"rustdoc-auto-hide-method-docs": |storage_value|} click: "#settings-menu" wait-for: "#settings" assert-property: ("#auto-hide-method-docs", {"checked": |setting_attribute_value|}) assert-attribute: (".toggle.method-toggle", {"open": |toggle_attribute_value|}) } ) goto: "file://" + |DOC_PATH| + "/lib2/struct.Foo.html" // We check that the setting is disabled by default. call-function: ("check-setting", { "storage_value": null, "setting_attribute_value": "false", "toggle_attribute_value": "", }) // Now we change its value. click: "#auto-hide-method-docs" assert-local-storage: {"rustdoc-auto-hide-method-docs": "true"} // We check that the changes were applied as expected. reload: call-function: ("check-setting", { "storage_value": "true", "setting_attribute_value": "true", "toggle_attribute_value": null, }) // And now we re-disable the setting. click: "#auto-hide-method-docs" assert-local-storage: {"rustdoc-auto-hide-method-docs": "false"} // And we check everything is back the way it was before. reload: call-function: ("check-setting", { "storage_value": "false", "setting_attribute_value": "false", "toggle_attribute_value": "", }) </ins>


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

use rustc_data_structures::fx::FxHashMap; use rustc_index::vec::IndexVec; use rustc::ty::layout::{ <del> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, </del> <ins> LayoutOf, TyLayout, LayoutError, HasTyCtxt, TargetDataLayout, HasDataLayout, Size, </ins> }; use crate::rustc::ty::subst::Subst;


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

use crate::const_eval::error_to_const_error; use crate::transform::{MirPass, MirSource}; <ins> /// The maximum number of bytes that we'll allocate space for a return value. const MAX_ALLOC_LIMIT: u64 = 1024; </ins> pub struct ConstProp; impl<'tcx> MirPass<'tcx> for ConstProp {


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

ecx .layout_of(body.return_ty().subst(tcx, substs)) .ok() <del> // Don't bother allocating memory for ZST types which have no values. .filter(|ret_layout| !ret_layout.is_zst()) </del> <ins> // Don't bother allocating memory for ZST types which have no values // or for large values. .filter(|ret_layout| !ret_layout.is_zst() && ret_layout.size < Size::from_bytes(MAX_ALLOC_LIMIT)) </ins> .map(|ret_layout| ecx.allocate(ret_layout, MemoryKind::Stack)); ecx.push_stack_frame(


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

) -> Option<()> { let span = source_info.span; <ins> // #66397: Don't try to eval into large places as that can cause an OOM if place_layout.size >= Size::from_bytes(MAX_ALLOC_LIMIT) { return None; } </ins> let overflow_check = self.tcx.sess.overflow_checks(); // Perform any special handling for specific Rvalue types.


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn foo() -> [u8; 4 * 1024 * 1024 * 1024 * 1024] { unimplemented!() } fn main() { foo(); } </ins>


Question:
A MSVC x8664 bors job has failed on two unrelated PRs (, ) with the : In both cases, attempted to allocate several GB of memory while compiling the crate. One of these failures was in the job, and the other was in . This failure appears to be spurious: a previous version of passed the same job.
I wonder if we could get a backtrace or something from this allocation -- it seems... suspicious that we're only sometimes OOMing. It's also interesting to note that this is almost exactly 4 GB in a single allocation, which is surprising generally ( is not a big crate -- 300 lines or so, with comments etc).
On my PR it was a different (almost) power of two: edit In both cases, the size of the allocation is 8 bytes less than a power of two.
So I minimized this to: on a recent nightly gives: It looks like the compiler is trying to allocate enough space to store a value of the return type. As long as I use a large enough value it reproduces reliably and it isn't specific to Windows: . I bisected this to and I'm guessing (cc is the root cause.
Yes, that seems likely. I will take a look at this tonight.
should we put on hold while this is sorted out?
Yeah, let's do that just to be safe.
triage: P-high. Removing nomination label.

<ins> // check-pass // only-x86_64 // Checks that the compiler does not actually try to allocate 4 TB during compilation and OOM crash. fn main() { [0; 4 * 1024 * 1024 * 1024 * 1024]; } </ins>


Question:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.

fallback_has_occurred: bool, mutate_fullfillment_errors: impl Fn(&mut Vec<traits::FulfillmentError<'tcx>>), ) { <del> if let Err(mut errors) = self.fulfillment_cx.borrow_mut().select_where_possible(self) { </del> <ins> let result = self.fulfillment_cx.borrow_mut().select_where_possible(self); if let Err(mut errors) = result { </ins> mutate_fullfillment_errors(&mut errors); self.report_fulfillment_errors(&errors, self.inh.body_id, fallback_has_occurred); }


Question:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.

<ins> // #66353: ICE when trying to recover from incorrect associated type trait _Func<T> { fn func(_: Self); } trait _A { type AssocT; } fn main() { _Func::< <() as _A>::AssocT >::func(()); //~^ ERROR the trait bound `(): _A` is not satisfied //~| ERROR the trait bound `(): _Func<_>` is not satisfied } </ins>


Question:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.

<ins> error[E0277]: the trait bound `(): _A` is not satisfied --> $DIR/issue-66353.rs:12:14 | LL |     _Func::< <() as _A>::AssocT >::func(()); |              ^^^^^^^^^^^^^^^^^^ the trait `_A` is not implemented for `()` error[E0277]: the trait bound `(): _Func<_>` is not satisfied --> $DIR/issue-66353.rs:12:41 | LL |     fn func(_: Self); |     ----------------- required by `_Func::func` ... LL |     _Func::< <() as _A>::AssocT >::func(()); |                                         ^^ the trait `_Func<_>` is not implemented for `()` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>


Question:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense. Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?

} fn check_pat(&mut self, cx: &LateContext<'_, '_>, p: &hir::Pat<'_>) { <del> if let &PatKind::Binding(_, _, ident, _) = &p.kind { </del> <ins> if let &PatKind::Binding(_, hid, ident, _) = &p.kind { if let hir::Node::Pat(parent_pat) = cx.tcx.hir().get(cx.tcx.hir().get_parent_node(hid)) { if let PatKind::Struct(_, field_pats, _) = &parent_pat.kind { for field in field_pats.iter() { if field.ident != ident { // Only check if a new name has been introduced, to avoid warning // on both the struct definition and this pattern. self.check_snake_case(cx, "variable", &ident); } } return; } } </ins> self.check_snake_case(cx, "variable", &ident); } }


Question:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense. Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?

<ins> #![deny(non_snake_case)] #![allow(unused_variables)] #![allow(dead_code)] enum Foo { Bad { lowerCamelCaseName: bool, //~^ ERROR structure field `lowerCamelCaseName` should have a snake case name }, Good { snake_case_name: bool, }, } fn main() { let b = Foo::Bad { lowerCamelCaseName: true }; match b { Foo::Bad { lowerCamelCaseName } => {} Foo::Good { snake_case_name: lowerCamelCaseBinding } => { } //~^ ERROR variable `lowerCamelCaseBinding` should have a snake case name } if let Foo::Good { snake_case_name: anotherLowerCamelCaseBinding } = b { } //~^ ERROR variable `anotherLowerCamelCaseBinding` should have a snake case name if let Foo::Bad { lowerCamelCaseName: yetAnotherLowerCamelCaseBinding } = b { } //~^ ERROR variable `yetAnotherLowerCamelCaseBinding` should have a snake case name } </ins>


Question:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense. Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?

<ins> error: structure field `lowerCamelCaseName` should have a snake case name --> $DIR/issue-66362-no-snake-case-warning-for-field-puns.rs:7:9 | LL |         lowerCamelCaseName: bool, |         ^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `lower_camel_case_name` | note: lint level defined here --> $DIR/issue-66362-no-snake-case-warning-for-field-puns.rs:1:9 | LL | #![deny(non_snake_case)] |         ^^^^^^^^^^^^^^ error: variable `lowerCamelCaseBinding` should have a snake case name --> $DIR/issue-66362-no-snake-case-warning-for-field-puns.rs:20:38 | LL |         Foo::Good { snake_case_name: lowerCamelCaseBinding } => { } |                                      ^^^^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `lower_camel_case_binding` error: variable `anotherLowerCamelCaseBinding` should have a snake case name --> $DIR/issue-66362-no-snake-case-warning-for-field-puns.rs:24:41 | LL |     if let Foo::Good { snake_case_name: anotherLowerCamelCaseBinding } = b { } |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `another_lower_camel_case_binding` error: variable `yetAnotherLowerCamelCaseBinding` should have a snake case name --> $DIR/issue-66362-no-snake-case-warning-for-field-puns.rs:27:43 | LL |     if let Foo::Bad { lowerCamelCaseName: yetAnotherLowerCamelCaseBinding } = b { } |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `yet_another_lower_camel_case_binding` error: aborting due to 4 previous errors </ins>


Question:
One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation. But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct). Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g. if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .
(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.

// are contravariant while return-position lifetimes are // covariant). _marker: PhantomData<fn(&'a ()) -> &'a ()>, <ins> // Ensure `Context` is `!Send` and `!Sync` in order to allow // for future `!Send` and / or `!Sync` fields. _marker2: PhantomData<*mut ()>, </ins> } impl<'a> Context<'a> {


Question:
One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation. But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct). Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g. if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .
(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.

#[must_use] #[inline] pub const fn from_waker(waker: &'a Waker) -> Self { <del> Context { waker, _marker: PhantomData } </del> <ins> Context { waker, _marker: PhantomData, _marker2: PhantomData } </ins> } /// Returns a reference to the [`Waker`] for the current task.


Question:
One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation. But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct). Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g. if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .
(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.

<del> use core::task::{Context, Poll, RawWaker, RawWakerVTable, Waker}; </del> <ins> use core::task::{Poll, RawWaker, RawWakerVTable, Waker}; </ins> #[test] fn poll_const() {


Question:
One issue that came up in the discussion is that the type implements . This might have been introduced accidentally. probably does not matter at all, given that users will only observe a by reference. However has the impliciation that we will not be able to add non thread-safe methods to - e.g. in order to optimize thread-local wake-ups again. It might be interesting to see whether and support could be removed from the type. Unfortunately that is however a breaking change - even though it is not likely that any code currently uses out of the direct path. In a similar fashion it had been observed in the implementation of () that the type is also and . While it had been expected for - given that s are used to wake-up tasks from different threads, it might not have been for . One downside of s being is that it prevents optimizations. E.g. in linked ticket the original implementation contained an optimization that while a was not d (and thereby equipped with a different vtable) it could wake-up the local eventloop again by just setting a non-synchronized boolean flag in the current thread. However given that could be transferred to another thread, and called from there even within the context - this optmization is invalid. Here it would also be interesting if the requirement could be removed. I expect the amount of real-world usages to be in the same ballpark as sending across threads - hopefully 0. But it's again a breaking change cc , , ,
Even if this weren't a breaking change, I'd want to see some really good evidence these optimizations would matter for real world code before choosing to make these types non-. I don't think getting rid of an atomic update in is a compelling example. Basically, in my view the current API is intentional and correct.
was introduced to leave room for future unforeseen requirements, and being restricts its usefulness as such, which is unfortunate. I can see a case for since we have , but it's difficult to imagine a case where it makes sense to be accessing a single from multiple threads concurrently.
I have an example of where the current API is resulting in performance issues: I am trying to implement a combined Executor/Reactor around a winit event loop. To wake up the event loop from a different thread we have to post a message to the event loop which can be a non-trivial operation. But on the same thread, we know that we don't need to wake up the eventloop, so we can use much cheaper mechanisms like an atomic bool.
But that would be true if wakers were just also, which was an intentional part of the simplification from the previous design.
I think the point is that being precludes the otherwise noninvasive restoration of a more efficient through an additional method on .
I don't think it should be the judgement of the libs team (or any of us) to determine whether something is good enough and not needs to be further optimized for any use-case. Rusts goal as a language is to enable zero cost abstractions. This requires in my opinion to not be opinionated on any design choices which have a performance/footprint impact. I think some of the decisions that have been taken in the async/await world however are opinionated, and will have an impact on use-cases that currently are still better implemented with different mechanisms. I do not really want to elaborate on anything more particular, because I fear this would bring the discussion back to a arguing whether any X% performance degradation is still good enough. That is an OK decision to have for a software project whichs needs to decide whether Rusts async/await support is good enough for them, and whether they have to apply workarounds or not. But it's not a discussion which will move the issue here any more forward, because for yet another project the outcoming of the discussion might be different. PS: I do think it's okay and good if libraries like tokio or async-std are being more opinionated about what threading models they support, and they might sacrifice performance gains in rare usage scenarios for easy of use. But and language features are different, and we expect people to use them also for niche use-cases (e.g. there is certainly a lot of cool evaluation going on with the use of async/await in embedded contexts or kernels - where requirements might be very different than for a webserver based on tokio).
This is a trade off: Context is either Sync or it isn't, some users benefit from one choice (they can use references to Context as threadsafe) and some users benefit from the other choice (they can have nonthreadsafe constructs inside the Context construct). Ultimately the libs team has to decide one way or the other on these points in the API where there is a trade off between thread safety and not. However, this decision has already been made and it would be a breaking change to change it, so this discussion is moot.
Do you have an example where this is actually done within the ecosystem, or a use-case for it? As far as I can tell, this would require spawning a thread using something like and capturing the from within a ?
A common way a user could depend on a type being is to store it in an and send it across threads. This isn't very likely for Context but it is a very reasonable pattern for .
I think its a fair point that we didnt intentionally make context send and sync, and that this precludes adding more fields to context that are not send and sync, and that since context is just a buffer for future changes, it would probably have been better to make it non-threadsafe. But now its a breaking change. If crater showed no regressions and there's no known patterns it nullifies, I would be open to changing this about Context personally, but I am somewhat doubtful the libs team as a whole would approve making a breaking change to support hypothetical future extensions. If anyone on the thread wants to pursue a change to context (not waker), they should get crater results as the next step of the conversation.
There is no discussion about being or not - it obviously has to be. The question is purely about . And in order to do what you describe you have to store an and send it somewhere. Which is very doubtful to happen, due to the not very useful lifetime and due to already being an like thing internally. As mentioned, the most likely way to see this behavior is some scoped thread API being used inside - or people doing some very advanced synchronization against an IO driver running in another thread. For all those there are certainly better ways than to rely on being . E.g. to return a flag from the synchronized section and call from the original thread when done. Or to and send the if there is doubt whether it needs to be persisted somewhere else. And yes, the impact on is even bigger. It was meant as an extension point. But we can not add any functions to it which are not thread-safe. E.g. if we want to add methods which spawn another task on the same thread as the current executor thread, and which allows for spawning futures (like Tokios ) - we would have an issue.
Why would these be "certainly better" than just calling from the scoped threads?
To be a little more expansive: the scoped threadpool you're talking about could very well not be scoped inside a poll method - rather, the waker could be cloned once and then owned by one thread and referenced by many other scoped threads in some sort of threadpool construct for CPU bound tasks. This seems like a perfectly valid implementation which allows you to divide up the work among many threads without cloning the waker many times. This is potentially an optimization. I don't think this optimization is very important, but I don't think the optimizations allowed by making waker are very important either. The point is that there's a trade off between the optimizations allowed by assuming references to wakers can be shared across threads and the optimizations allowed by assuming they can't be, its not the case that one side is inherently the "zero cost" side.
We discussed this at the recent Libs meeting and felt that deferring to would make sense here.
Though I don't have the bandwidth to carry this, this definitely seems interesting. Seeing projects such as and closed-source initiatives lead me to believe that there may actually be a decent case to enable some form of -to avoid the synchronization overhead on single-threaded runtimes. I don't know if we should make this a priority, but at least we probably shouldn't close it just yet.
I think bringing back would be a nice additional improvement. But for the moment it would be nice to just fix the general sync-ness, which blocks all other fixes and improvements.
As the person who originally introduced , it was very much a conscious decision to get rid of it and to make and . This was called out explicitly .
The cited discussion in the RFC justifies making Send, and predates the decision to (re)introduce . Making doesn't defeat the objectives discussed there. In particular, it does not impact ergonomics for the common case at all.
This was recently closed, however the issue mentions both and . The recent change only affects . There is good reason that is , however after reading this issue I'm unsure that there are good reasons why is .
(NOT A CONTRIBUTION) Waker supports wakebyref, and so it is possible to pass to another thread and wake it from that thread. This functionality would not be possible without Waker being Sync. Supporting wakers that are either not Send or not Sync will best be done by adding new APIs to Context and a new LocalWaker type.
Forgive me the naive question, but how does a type work with ? As I understand, requires , as a concrete type not a trait, so this would also require a trait? At this point we have two completely incompatible async systems... Which is only useful if is not cheap to clone, and has the burden of another lifetime bound. It surprises me that the docs don't say anything about the intended cost of .
(NOT A CONTRIBUTION) Future::poll does not take Waker as an argument, Future::poll takes Context. Context could have the ability to set a LocalWaker, so that an executor could set this. Reactors which operate on the same thread as the future that polls them could migrate to using the LocalWaker argument instead of Waker. Here is a pre-RFC that someone wrote with a possible API: Commentary like this is both factually wrong and not helpful for the mood of the thread.

static WAKER: Waker = unsafe { Waker::from_raw(VOID_WAKER) }; <del> static CONTEXT: Context<'static> = Context::from_waker(&WAKER); static WAKER_REF: &'static Waker = CONTEXT.waker(); WAKER_REF.wake_by_ref(); </del> <ins> WAKER.wake_by_ref(); </ins> }


Question:
This works; let's consider adding a test for it since it's a bit of a special case. Reported to be working in by
do you mind if I add this? My laptop is no longer broken ^^ so I can actually get some work done without disappearing for a week at a time. I put this in a file called and ran , is that about the right approach?
It is, but I'd recommend using to make it go faster. Also use to just test that file. Also, I'd rename the test to not suggest ... something like .
I ran about an hour ago and that worked fine (although it took a while ^^). However, since then I updated nightly and I'm now getting compile errors when building stage 1: What am I doing wrong? Full error: (cross posted from https://rust-)

<ins> // check-pass #![feature(const_if_match)] enum E { A, B, C } const fn f(e: E) -> usize { match e { _ => 0 } } fn main() { const X: usize = f(E::C); assert_eq!(X, 0); assert_eq!(f(E::A), 0); } </ins>


Question:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

variant_index: VariantIdx, dest: PlaceTy<'tcx, M::PointerTag>, ) -> InterpResult<'tcx> { <del> let variant_scalar = Scalar::from_u32(variant_index.as_u32()).into(); </del> <ins> // Layout computation excludes uninhabited variants from consideration // therefore there's no way to represent those variants in the given layout. if dest.layout.for_variant(self, variant_index).abi.is_uninhabited() { throw_ub!(Unreachable); } </ins> match dest.layout.variants { layout::Variants::Single { index } => { <del> if index != variant_index { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> assert_eq!(index, variant_index); </ins> } layout::Variants::Multiple { discr_kind: layout::DiscriminantKind::Tag,


Question:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

discr_index, .. } => { <del> if !dest.layout.ty.variant_range(*self.tcx).unwrap().contains(&variant_index) { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> // No need to validate that the discriminant here because the // `TyLayout::for_variant()` call earlier already checks the variant is valid. </ins> let discr_val = dest.layout.ty.discriminant_for_variant(*self.tcx, variant_index).unwrap().val;


Question:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

discr_index, .. } => { <del> if !variant_index.as_usize() < dest.layout.ty.ty_adt_def().unwrap().variants.len() { throw_ub!(InvalidDiscriminant(variant_scalar)); } </del> <ins> // No need to validate that the discriminant here because the // `TyLayout::for_variant()` call earlier already checks the variant is valid. </ins> if variant_index != dataful_variant { let variants_start = niche_variants.start().as_u32(); let variant_index_relative = variant_index.as_u32()


Question:
I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .

<ins> // build-pass // compile-flags: --crate-type lib // Regression test for ICE which occurred when const propagating an enum with three variants // one of which is uninhabited. pub enum ApiError {} #[allow(dead_code)] pub struct TokioError { b: bool, } pub enum Error { Api { source: ApiError, }, Ethereum, Tokio { source: TokioError, }, } struct Api; impl IntoError<Error> for Api { type Source = ApiError; fn into_error(self, error: Self::Source) -> Error { Error::Api { source: (|v| v)(error), } } } pub trait IntoError<E> { /// The underlying error type Source; /// Combine the information to produce the error fn into_error(self, source: Self::Source) -> E; } </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> // edition:2018 use std::sync::{Arc, Mutex}; pub async fn f(_: ()) {} pub async fn run() { let x: Arc<Mutex<()>> = unimplemented!(); f(*x.lock().unwrap()).await; } </ins>


Question:
I hit this problem while trying to make a task joining function. The problem occured when I started messing around with Arc<RwLock<FuturesUnordered. The nightly compiler crashes on this too. Problematic code: Clone the smtpbis repo on the rustice branch. : rustc 1.39.0 ( 2019-11-04) binary: rustc commit-hash: commit-date: 2019-11-04 host: x86_64-unknown-linux-gnu release: 1.39.0 LLVM version: 9.0 Backtrace:
for exact reproduction:
Does this reproduce on nightly?
yes, I get the error using rustc 1.41.0-nightly ( 2019-11-28)
line seems to be the culprit. It only exhibits when going over crate bound (at least I couldn't minify it further). in the binaries folder:
cc
triage: P-high, at least to identify whether this is a long-standing bug or a stable-to-stable regression. Removing nomination.
This won't build on 1.30:
Removing and as the bug's been fixed in , but leaving open to add a regression test.
I'm confused. Did you add a testcase for this or not?
As discussed in , we didn't add the test case there due to diffs of diagnostics on some environment.

<ins> // aux-build: issue_67893.rs // edition:2018 // dont-check-compiler-stderr // FIXME(#71222): Add above flag because of the difference of stderrs on some env. extern crate issue_67893; fn g(_: impl Send) {} fn main() { g(issue_67893::run()) //~^ ERROR: `std::sync::MutexGuard<'_, ()>` cannot be sent between threads safely } </ins>