jiebi/CodeConvo huggingface dataset:
Code change:
Hi, I'm building a project and I'm using the nightly channel. I was testing it with several builds between 2019-09-20 and 2019-10-27, all with the same results – when targetting native, the compilation succeeds, when targetting WASM, we see ICE. Unfortunately, it was hard for me to minimize the example. Fortunately, the codebase is pretty small. Here is the exact commit: After downloading it you can run and it should succeed. But if you run (which is 1-line wrapper over ), we get: After commenting out this line, everything should compile OK (WASM target should compile as well): EDIT The backtrace from the compiler is not very helpful: However, there is some additional info:
That code is a mess! After an hour of digging through the code and removing half of it - the code that triggers the error is: I try to produce a MCVE out of it currently
Yes, the code is in a very work-in-progress state, so there are a lot of places which should be refactored or even removed, sorry for that. The line that I mentioned in my original post calls the function that you have pointed to. The function alone compiles well to WASM. It does not compile when used as follow:
Seems to be related to . Here's something small-ish: I may give it a shot later, but now I'm gonna head home :)
that is amazing! I've created yet shorter version (still, there may be things to simplify here):
modify labels: -O-wasm +F-typealiasimpl_trait
< 50 loc :tada:
thank you for tracking it down
could you please change the title of this issue to something different, e.g. "ICE with impl Fn alias"? It's not about WASM anymore ;)
Because a lot has changed, here's a summary: <details<summaryMCVE</summary</details<details<summaryBacktrace</summary</details
Relevant log output: <details</detailsIt looks like is getting normalied to (since the underlying type of is ) when we attempt to compute the layout of a type. However, the still contains , which will not match with the normalized version. I think the solution is to normalize the when we call on it.
triage: has PR. marking P-high, removing I-nominated.
It seems the ICE (with MCVE) has been fixed in latest nightly.
It has been fixed by , marked as E-needstest
Reopening due to

Related discussion:
text: <ins> // build-pass trait AssociatedConstant { const DATA: (); } impl<F, T> AssociatedConstant for F where F: FnOnce() -> T, T: AssociatedConstant, { const DATA: () = T::DATA; } impl AssociatedConstant for () { const DATA: () = (); } fn foo() -> impl AssociatedConstant { () } fn get_data<T: AssociatedConstant>(_: T) -> &'static () { &T::DATA } fn main() { get_data(foo); } </ins>
Code change:
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.

Related discussion:
text: [[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",
Code change:
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.

Related discussion:
text: [[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",
Code change:
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.

Related discussion:
text: "num_cpus", "ordslice", "racer", <del> "rand 0.6.1", </del> <ins> "rand 0.7.0", </ins> "rayon", "regex", "rls-analysis",
Code change:
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.

Related discussion:
text: "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",
Code change:
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.

Related discussion:
text: 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",
Code change:
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.

Related discussion:
text: ] [[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 = [
Code change:
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.

Related discussion:
text: <del> Subproject commit a18df16181947edd5eb593ea0f2321e0035448ee </del> <ins> Subproject commit 5db91c7b94ca81eead6b25bcf6196b869a44ece0 </ins>
Code change:
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:

Related discussion:
text: <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>
Code change:
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:

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: 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 {
Code change:
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.

Related discussion:
text: 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(
Code change:
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.

Related discussion:
text: ) -> 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.
Code change:
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.

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: <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>
Code change:
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.

Related discussion:
text: 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); }