Question:
I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack": To reproduce: out the branch the patch listed below (uncomment a single line) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --Backtrace N/A.
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See for explanation) <details<summarystable</summary</details<details<summarynightly</summary</details
This is causing the overflow: Trying to get rid of serde ~and bisecting~ right now. Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. This is a edition2018 specific bug, because there's no need for anymore. If I add that to the outer scope, the overflow will go away. For reference, here's a code that a user would write, therefore I think this should be P-High The workaround is to move the to the outer scope.
Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however!
note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the the compiler fails earlier in the pipeline. reduced testcase also runs on the if needed, btw!
cc
For reference: The small error went away with , which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I believe I managed to hit this specific crash while working on ( is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete , here's the gist of it (in ) : This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single dependency. The points for reproducing the issue in a project are the following: As pointed out by the title of this issue, there needs to be an declaration inside of a trait implementation, which references the same crate the trait is coming from. There also needs an exposed function referencing a type from that same crate, i.e. either returning it, or receiving it as a parameter (either directly, or through a reference or pointer). The exposed function can be either a function, or a private function marked with the attribute (the attribute is how I encountered the crash at first). The common denominator with Serde here is the in "hack" to make proc macros as hygienic as possible, first suggested in , which I discovered through the explanation in . I had just tried to use this same trick, as we've had , and that's when the compiler crashed with the stack overflow: And here's my : I know nothing about 's internals, but here are a few additional observations I made while making this test case: Unlike what's described in the first message, both Rust-LV2 and my test project only reproduce the crash by actually building the project using (in either debug or release mode). Using on those projects did not crash. This is also corroborated by the fact that introducing a type error in the exposed function does not result in a crash either — the type error stops the rustc before it actually builds anything. The exposed function can be either in the same module as the trait implementations, or in a submodule, as long as it is either public or the function is (which, in a way, bypasses module visibility). If the function is either private, or marked but in a private module, the compiler does not crash. The "exposed function" part of the crash does not apply to all exposed items: replacing the function with e.g. does not trigger a crash. If a second declaration is in the implementation of another trait (here demonstrated with ) then the crash does not happen anymore. Having it only in the impl does not trigger the crash either. It behaves like there is a cache of some sort on these 'extern crate' declarations, and having a cache miss inside of the trait impl referenced by that crate causes the crash. Hope this helps! :slightlysmiling_face:
I remember this, it is an old issue -
If returns and finishes , then this issue should be fixed as well. Narrator: eddyb never returned.
Ah, right, that got lost in the chaos of Rust 2018 + all the changes. Fingers crossed that code hasn't gotten crazier since.
A different reproducer (one above will stop working soon; probably).
Finally found some time for this, some notes: had been superseded by work, seems to be correct, so there's not really anything to do by trying to rebase that PR is what never happened, and should be relatively simple by comparison right now we prioritize over "Rust 2018 paths to " (whether in or elsewhere), as the "source of ", but I'm not sure the latter ends up being used with -introduced names, so I'm hoping flipping that priority direction is enough to get better results
Also, I don't recall seeing - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see

<ins> // run-pass // edition:2018 // aux-crate:issue_55779_extern_trait=issue-55779-extern-trait.rs use issue_55779_extern_trait::Trait; struct Local; struct Helper; impl Trait for Local { fn no_op(&self) { // (Unused) extern crate declaration necessary to reproduce bug extern crate issue_55779_extern_trait; // This one works // impl Trait for Helper { fn no_op(&self) { } } // This one infinite-loops const _IMPL_SERIALIZE_FOR_HELPER: () = { // (extern crate can also appear here to reproduce bug, // as in originating example from serde) impl Trait for Helper { fn no_op(&self) { } } }; } } fn main() { } </ins>


Question:
I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack": To reproduce: out the branch the patch listed below (uncomment a single line) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --Backtrace N/A.
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See for explanation) <details<summarystable</summary</details<details<summarynightly</summary</details
This is causing the overflow: Trying to get rid of serde ~and bisecting~ right now. Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. This is a edition2018 specific bug, because there's no need for anymore. If I add that to the outer scope, the overflow will go away. For reference, here's a code that a user would write, therefore I think this should be P-High The workaround is to move the to the outer scope.
Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however!
note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the the compiler fails earlier in the pipeline. reduced testcase also runs on the if needed, btw!
cc
For reference: The small error went away with , which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I believe I managed to hit this specific crash while working on ( is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete , here's the gist of it (in ) : This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single dependency. The points for reproducing the issue in a project are the following: As pointed out by the title of this issue, there needs to be an declaration inside of a trait implementation, which references the same crate the trait is coming from. There also needs an exposed function referencing a type from that same crate, i.e. either returning it, or receiving it as a parameter (either directly, or through a reference or pointer). The exposed function can be either a function, or a private function marked with the attribute (the attribute is how I encountered the crash at first). The common denominator with Serde here is the in "hack" to make proc macros as hygienic as possible, first suggested in , which I discovered through the explanation in . I had just tried to use this same trick, as we've had , and that's when the compiler crashed with the stack overflow: And here's my : I know nothing about 's internals, but here are a few additional observations I made while making this test case: Unlike what's described in the first message, both Rust-LV2 and my test project only reproduce the crash by actually building the project using (in either debug or release mode). Using on those projects did not crash. This is also corroborated by the fact that introducing a type error in the exposed function does not result in a crash either — the type error stops the rustc before it actually builds anything. The exposed function can be either in the same module as the trait implementations, or in a submodule, as long as it is either public or the function is (which, in a way, bypasses module visibility). If the function is either private, or marked but in a private module, the compiler does not crash. The "exposed function" part of the crash does not apply to all exposed items: replacing the function with e.g. does not trigger a crash. If a second declaration is in the implementation of another trait (here demonstrated with ) then the crash does not happen anymore. Having it only in the impl does not trigger the crash either. It behaves like there is a cache of some sort on these 'extern crate' declarations, and having a cache miss inside of the trait impl referenced by that crate causes the crash. Hope this helps! :slightlysmiling_face:
I remember this, it is an old issue -
If returns and finishes , then this issue should be fixed as well. Narrator: eddyb never returned.
Ah, right, that got lost in the chaos of Rust 2018 + all the changes. Fingers crossed that code hasn't gotten crazier since.
A different reproducer (one above will stop working soon; probably).
Finally found some time for this, some notes: had been superseded by work, seems to be correct, so there's not really anything to do by trying to rebase that PR is what never happened, and should be relatively simple by comparison right now we prioritize over "Rust 2018 paths to " (whether in or elsewhere), as the "source of ", but I'm not sure the latter ends up being used with -introduced names, so I'm hoping flipping that priority direction is enough to get better results
Also, I don't recall seeing - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see

<ins> // edition:2018 // aux-crate:issue_87932_a=issue-87932-a.rs pub struct A {} impl issue_87932_a::Deserialize for A { fn deserialize() { extern crate issue_87932_a as _a; } } fn main() { A::deserialize(); //~^ ERROR no function or associated item named `deserialize` found for struct `A` } </ins>


Question:
I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack": To reproduce: out the branch the patch listed below (uncomment a single line) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --Backtrace N/A.
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See for explanation) <details<summarystable</summary</details<details<summarynightly</summary</details
This is causing the overflow: Trying to get rid of serde ~and bisecting~ right now. Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. This is a edition2018 specific bug, because there's no need for anymore. If I add that to the outer scope, the overflow will go away. For reference, here's a code that a user would write, therefore I think this should be P-High The workaround is to move the to the outer scope.
Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however!
note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the the compiler fails earlier in the pipeline. reduced testcase also runs on the if needed, btw!
cc
For reference: The small error went away with , which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I believe I managed to hit this specific crash while working on ( is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete , here's the gist of it (in ) : This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single dependency. The points for reproducing the issue in a project are the following: As pointed out by the title of this issue, there needs to be an declaration inside of a trait implementation, which references the same crate the trait is coming from. There also needs an exposed function referencing a type from that same crate, i.e. either returning it, or receiving it as a parameter (either directly, or through a reference or pointer). The exposed function can be either a function, or a private function marked with the attribute (the attribute is how I encountered the crash at first). The common denominator with Serde here is the in "hack" to make proc macros as hygienic as possible, first suggested in , which I discovered through the explanation in . I had just tried to use this same trick, as we've had , and that's when the compiler crashed with the stack overflow: And here's my : I know nothing about 's internals, but here are a few additional observations I made while making this test case: Unlike what's described in the first message, both Rust-LV2 and my test project only reproduce the crash by actually building the project using (in either debug or release mode). Using on those projects did not crash. This is also corroborated by the fact that introducing a type error in the exposed function does not result in a crash either — the type error stops the rustc before it actually builds anything. The exposed function can be either in the same module as the trait implementations, or in a submodule, as long as it is either public or the function is (which, in a way, bypasses module visibility). If the function is either private, or marked but in a private module, the compiler does not crash. The "exposed function" part of the crash does not apply to all exposed items: replacing the function with e.g. does not trigger a crash. If a second declaration is in the implementation of another trait (here demonstrated with ) then the crash does not happen anymore. Having it only in the impl does not trigger the crash either. It behaves like there is a cache of some sort on these 'extern crate' declarations, and having a cache miss inside of the trait impl referenced by that crate causes the crash. Hope this helps! :slightlysmiling_face:
I remember this, it is an old issue -
If returns and finishes , then this issue should be fixed as well. Narrator: eddyb never returned.
Ah, right, that got lost in the chaos of Rust 2018 + all the changes. Fingers crossed that code hasn't gotten crazier since.
A different reproducer (one above will stop working soon; probably).
Finally found some time for this, some notes: had been superseded by work, seems to be correct, so there's not really anything to do by trying to rebase that PR is what never happened, and should be relatively simple by comparison right now we prioritize over "Rust 2018 paths to " (whether in or elsewhere), as the "source of ", but I'm not sure the latter ends up being used with -introduced names, so I'm hoping flipping that priority direction is enough to get better results
Also, I don't recall seeing - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see

<ins> error[E0599]: no function or associated item named `deserialize` found for struct `A` in the current scope --> $DIR/issue-87932.rs:13:8 | LL | pub struct A {} | ------------ function or associated item `deserialize` not found for this ... LL |     A::deserialize(); |        ^^^^^^^^^^^ function or associated item not found in `A` | = help: items from traits can only be used if the trait is in scope help: the following trait is implemented but not in scope; perhaps add a `use` for it: | LL | use <crate::A as issue_87932_a::Deserialize>::deserialize::_a::Deserialize; | error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>


Question:
More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .

// of a macro that is not vendored by Rust and included in the toolchain. // See https://github.com/rust-analyzer/rust-analyzer/issues/6038. <ins> // On certain platforms right now the "main modules" modules that are // documented don't compile (missing things in `libc` which is empty), // so just omit them with an empty module and add the "unstable" attribute. // Unix, linux, wasi and windows are handled a bit differently. </ins> #[cfg(all( doc, <del> not(any( </del> <ins> any( </ins> all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") <del> )) </del> <ins> ) </ins> ))] <del> #[path = "."] mod doc { // When documenting std we want to show the `unix`, `windows`, `linux` and `wasi` // modules as these are the "main modules" that are used across platforms, // so these modules are enabled when `cfg(doc)` is set. // This should help show platform-specific functionality in a hopefully cross-platform // way in the documentation. pub mod unix; pub mod linux; pub mod wasi; pub mod windows; } </del> <ins> #[unstable(issue = "none", feature = "std_internals")] pub mod unix {} </ins> #[cfg(all( doc, any(


Question:
More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .

all(target_vendor = "fortanix", target_env = "sgx") ) ))] <del> mod doc { // On certain platforms right now the "main modules" modules that are // documented don't compile (missing things in `libc` which is empty), // so just omit them with an empty module. #[unstable(issue = "none", feature = "std_internals")] pub mod unix {} #[unstable(issue = "none", feature = "std_internals")] pub mod linux {} #[unstable(issue = "none", feature = "std_internals")] pub mod wasi {} #[unstable(issue = "none", feature = "std_internals")] pub mod windows {} } #[cfg(doc)] #[stable(feature = "os", since = "1.0.0")] pub use doc::*; #[cfg(not(doc))] #[path = "."] mod imp { // If we're not documenting std then we only expose modules appropriate for the // current platform. #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] pub mod fortanix_sgx; #[cfg(target_os = "hermit")] #[path = "hermit/mod.rs"] pub mod unix; </del> <ins> #[unstable(issue = "none", feature = "std_internals")] pub mod linux {} #[cfg(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) ))] #[unstable(issue = "none", feature = "std_internals")] pub mod wasi {} #[cfg(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) ))] #[unstable(issue = "none", feature = "std_internals")] pub mod windows {} </ins> <del> #[cfg(target_os = "android")] pub mod android; #[cfg(target_os = "dragonfly")] pub mod dragonfly; #[cfg(target_os = "emscripten")] pub mod emscripten; #[cfg(target_os = "espidf")] pub mod espidf; #[cfg(target_os = "freebsd")] pub mod freebsd; #[cfg(target_os = "fuchsia")] pub mod fuchsia; #[cfg(target_os = "haiku")] pub mod haiku; #[cfg(target_os = "illumos")] pub mod illumos; #[cfg(target_os = "ios")] pub mod ios; #[cfg(target_os = "l4re")] pub mod linux; #[cfg(target_os = "linux")] pub mod linux; #[cfg(target_os = "macos")] pub mod macos; #[cfg(target_os = "netbsd")] pub mod netbsd; #[cfg(target_os = "openbsd")] pub mod openbsd; #[cfg(target_os = "redox")] pub mod redox; #[cfg(target_os = "solaris")] pub mod solaris; #[cfg(unix)] pub mod unix; </del> <ins> // unix #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(target_os = "hermit")] #[path = "hermit/mod.rs"] pub mod unix; #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(all(not(target_os = "hermit"), any(unix, doc)))] pub mod unix; </ins> <del> #[cfg(target_os = "vxworks")] pub mod vxworks; </del> <ins> // linux #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(target_os = "linux", target_os = "l4re", doc))] pub mod linux; </ins> <del> #[cfg(target_os = "wasi")] pub mod wasi; </del> <ins> // wasi #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(target_os = "wasi", doc))] pub mod wasi; </ins> <del> #[cfg(windows)] pub mod windows; } #[cfg(not(doc))] #[stable(feature = "os", since = "1.0.0")] pub use imp::*; </del> <ins> // windows #[cfg(not(all( doc, any( all(target_arch = "wasm32", not(target_os = "wasi")), all(target_vendor = "fortanix", target_env = "sgx") ) )))] #[cfg(any(windows, doc))] pub mod windows; // Others. #[cfg(target_os = "android")] pub mod android; #[cfg(target_os = "dragonfly")] pub mod dragonfly; #[cfg(target_os = "emscripten")] pub mod emscripten; #[cfg(target_os = "espidf")] pub mod espidf; #[cfg(all(target_vendor = "fortanix", target_env = "sgx"))] pub mod fortanix_sgx; #[cfg(target_os = "freebsd")] pub mod freebsd; #[cfg(target_os = "fuchsia")] pub mod fuchsia; #[cfg(target_os = "haiku")] pub mod haiku; #[cfg(target_os = "illumos")] pub mod illumos; #[cfg(target_os = "ios")] pub mod ios; #[cfg(target_os = "macos")] pub mod macos; #[cfg(target_os = "netbsd")] pub mod netbsd; #[cfg(target_os = "openbsd")] pub mod openbsd; #[cfg(target_os = "redox")] pub mod redox; #[cfg(target_os = "solaris")] pub mod solaris; #[cfg(target_os = "vxworks")] pub mod vxworks; </ins> #[cfg(any(unix, target_os = "wasi", doc))] mod fd;


Question:
More information on
To be clear, I'm not actually sure that's a private link, I didn't look at it in detail. It might just be doc(hidden) or something.
I didn't either. Just that most of weird things happening are in .

pub const PATH_BUF_AS_PATH: [&str; 4] = ["std", "path", "PathBuf", "as_path"]; pub const PATH_TO_PATH_BUF: [&str; 4] = ["std", "path", "Path", "to_path_buf"]; pub const PERMISSIONS: [&str; 3] = ["std", "fs", "Permissions"]; <del> pub const PERMISSIONS_FROM_MODE: [&str; 7] = ["std", "os", "imp", "unix", "fs", "PermissionsExt", "from_mode"]; </del> <ins> pub const PERMISSIONS_FROM_MODE: [&str; 6] = ["std", "os", "unix", "fs", "PermissionsExt", "from_mode"]; </ins> pub const POLL: [&str; 4] = ["core", "task", "poll", "Poll"]; pub const POLL_PENDING: [&str; 5] = ["core", "task", "poll", "Poll", "Pending"]; pub const POLL_READY: [&str; 5] = ["core", "task", "poll", "Poll", "Ready"];


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

//! normal visitor, which just walks the entire body in one shot, the //! `ExprUseVisitor` determines how expressions are being used. <ins> use hir::def::DefKind; </ins> // Export these here so that Clippy can use them. pub use rustc_middle::hir::place::{Place, PlaceBase, PlaceWithHirId, Projection};


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

use rustc_infer::infer::InferCtxt; use rustc_middle::hir::place::ProjectionKind; use rustc_middle::mir::FakeReadCause; <del> use rustc_middle::ty::{self, adjustment, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, adjustment, Ty, TyCtxt}; </ins> use rustc_target::abi::VariantIdx; use std::iter;


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

needs_to_be_read = true; } } <del> PatKind::TupleStruct(..) | PatKind::Path(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // If the PatKind is a TupleStruct, Path, Struct or Tuple then we want to check // whether the Variant is a MultiVariant or a SingleVariant. We only want // to borrow discr if it is a MultiVariant. // If it is a SingleVariant and creates a binding we will handle that when // this callback gets called again. // Get the type of the Place after all projections have been applied let place_ty = place.place.ty(); if let ty::Adt(def, _) = place_ty.kind() { if def.variants.len() > 1 { </del> <ins> PatKind::Path(qpath) => { // A `Path` pattern is just a name like `Foo`. This is either a // named constant or else it refers to an ADT variant let res = self.mc.typeck_results.qpath_res(qpath, pat.hir_id); match res { Res::Def(DefKind::Const, _) | Res::Def(DefKind::AssocConst, _) => { // Named constants have to be equated with the value // being matched, so that's a read of the value being matched. // // FIXME: We don't actually  reads for ZSTs. </ins> needs_to_be_read = true; } <del> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </del> <ins> _ => { // Otherwise, this is a struct/enum variant, and so it's // only a read if we need to read the discriminant. needs_to_be_read |= is_multivariant_adt(place.place.ty()); } </ins> } } <ins> PatKind::TupleStruct(..) | PatKind::Struct(..) | PatKind::Tuple(..) => { // For `Foo(..)`, `Foo { ... }` and `(...)` patterns, check if we are matching // against a multivariant enum or struct. In that case, we have to read // the discriminant. Otherwise this kind of pattern doesn't actually // read anything (we'll get invoked for the `...`, which may indeed // perform some reads). let place_ty = place.place.ty(); needs_to_be_read |= is_multivariant_adt(place_ty); } </ins> PatKind::Lit(_) | PatKind::Range(..) => { // If the PatKind is a Lit or a Range then we want // to borrow discr.


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

} } } <ins> fn is_multivariant_adt(ty: Ty<'tcx>) -> bool { if let ty::Adt(def, _) = ty.kind() { def.variants.len() > 1 } else { false } } </ins>


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

<ins> // edition:2021 #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode(pub u8); impl Opcode { pub const OP1: Opcode = Opcode(0x1); } pub fn example1(msg_type: Opcode) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered Opcode::OP1 => unimplemented!(), } } #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode2(Opcode); impl Opcode2 { pub const OP2: Opcode2 = Opcode2(Opcode(0x1)); } pub fn example2(msg_type: Opcode2) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered Opcode2::OP2=> unimplemented!(), } } fn main() {} </ins>


Question:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim

<ins> error[E0004]: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered --> $DIR/issue-88331.rs:11:20 | LL | pub struct Opcode(pub u8); | -------------------------- `Opcode` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode` error[E0004]: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered --> $DIR/issue-88331.rs:27:20 | LL | pub struct Opcode2(Opcode); | --------------------------- `Opcode2` defined here ... LL |     move |i| match msg_type { |                    ^^^^^^^^ patterns `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered | = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `Opcode2` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0004`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier/fixed/-1.rs <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

use rustc_middle::mir::visit::{MutatingUseContext, NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::*; use rustc_middle::ty::cast::CastTy; <del> use rustc_middle::ty::subst::GenericArgKind; </del> <ins> use rustc_middle::ty::subst::{GenericArgKind, InternalSubsts}; </ins> use rustc_middle::ty::{self, adjustment::PointerCast, Instance, InstanceDef, Ty, TyCtxt}; use rustc_middle::ty::{Binder, TraitPredicate, TraitRef}; use rustc_span::{sym, Span, Symbol};


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier/fixed/-1.rs <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

let fn_ty = func.ty(body, tcx); <del> let (mut callee, substs) = match *fn_ty.kind() { </del> <ins> let (mut callee, mut substs) = match *fn_ty.kind() { </ins> ty::FnDef(def_id, substs) => (def_id, substs), ty::FnPtr(_) => {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier/fixed/-1.rs <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

.iter() .find(|did| tcx.item_name(**did) == callee_name) { <ins> // using internal substs is ok here, since this is only // used for the `resolve` call below substs = InternalSubsts::identity_for_item(tcx, did); </ins> callee = did; } } <del> _ => { if !tcx.is_const_fn_raw(callee) { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; } </del> <ins> _ if !tcx.is_const_fn_raw(callee) => { // At this point, it is only legal when the caller is marked with // #[default_method_body_is_const], and the callee is in the same // trait. let callee_trait = tcx.trait_of_item(callee); if callee_trait.is_some() { if tcx.has_attr(caller, sym::default_method_body_is_const) { if tcx.trait_of_item(caller) == callee_trait { nonconst_call_permission = true; </ins> } } <ins> } </ins> <del> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; } </del> <ins> if !nonconst_call_permission { self.check_op(ops::FnCallNonConst); return; </ins> } } <ins> _ => {} </ins> } // Resolve a trait method call to its concrete implementation, which may be in a


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --code from glacier/fixed/-1.rs <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.

<ins> // build-pass #![feature(const_trait_impl)] trait Func<T> { type Output; fn call_once(self, arg: T) -> Self::Output; } struct Closure; impl const Func<&usize> for Closure { type Output = usize; fn call_once(self, arg: &usize) -> Self::Output { *arg } } enum Bug<T = [(); Closure.call_once(&0) ]> { V(T), } fn main() {} </ins>


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

<del> Subproject commit 7a2f1cadcd5120c44eda3596053de767cd8173a2 </del> <ins> Subproject commit 035933186957cf81c488261fb48a98bf523e8006 </ins>


Question:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

//! Enforces the Rust effect system. Currently there is just one effect, /// `unsafe`. <del> use middle::ty::{ty_bare_fn, ty_closure, ty_ptr}; </del> use middle::ty; use middle::typeck::method_map; use util::ppaux; <del> use syntax::ast::{UnDeref, ExprCall, ExprInlineAsm, ExprMethodCall}; use syntax::ast::{ExprUnary, unsafe_fn, ExprPath}; </del> use syntax::ast; use syntax::codemap::Span; <del> use syntax::visit::{fk_item_fn, fk_method}; </del> use syntax::visit; <del> use syntax::visit::{Visitor,fn_kind}; use syntax::ast::{fn_decl,Block,NodeId,Expr}; </del> <ins> use syntax::visit::Visitor; </ins> #[deriving(Eq)] enum UnsafeContext {


Question:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

UnsafeBlock(ast::NodeId), } <del> struct Context { /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, } </del> fn type_is_unsafe_function(ty: ty::t) -> bool { match ty::get(ty).sty { <del> ty_bare_fn(ref f) => f.purity == unsafe_fn, ty_closure(ref f) => f.purity == unsafe_fn, </del> <ins> ty::ty_bare_fn(ref f) => f.purity == ast::unsafe_fn, ty::ty_closure(ref f) => f.purity == ast::unsafe_fn, </ins> _ => false, } } struct EffectCheckVisitor { tcx: ty::ctxt, <del> context: @mut Context, </del> <ins> /// The method map. method_map: method_map, /// Whether we're in an unsafe context. unsafe_context: UnsafeContext, </ins> } impl EffectCheckVisitor { fn require_unsafe(&mut self, span: Span, description: &str) { <del> match self.context.unsafe_context { </del> <ins> match self.unsafe_context { </ins> SafeContext => { // Report an error. self.tcx.sess.span_err(span,


Question:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

UnsafeFn => {} } } <ins> fn check_str_index(&mut self, e: @ast::Expr) { let base_type = match e.node { ast::ExprIndex(_, base, _) => ty::node_id_to_type(self.tcx, base.id), _ => return }; debug2!("effect: checking index with base type {}", ppaux::ty_to_str(self.tcx, base_type)); match ty::get(base_type).sty { ty::ty_estr(*) => { self.tcx.sess.span_err(e.span, "modification of string types is not allowed"); } _ => {} } } </ins> } impl Visitor<()> for EffectCheckVisitor { <del> fn visit_fn(&mut self, fn_kind:&fn_kind, fn_decl:&fn_decl, block:&Block, span:Span, node_id:NodeId, _:()) { let (is_item_fn, is_unsafe_fn) = match *fn_kind { fk_item_fn(_, _, purity, _) => (true, purity == unsafe_fn), fk_method(_, _, method) => (true, method.purity == unsafe_fn), _ => (false, false), }; let old_unsafe_context = self.context.unsafe_context; if is_unsafe_fn { self.context.unsafe_context = UnsafeFn } else if is_item_fn { self.context.unsafe_context = SafeContext } </del> <ins> fn visit_fn(&mut self, fn_kind: &visit::fn_kind, fn_decl: &ast::fn_decl, block: &ast::Block, span: Span, node_id: ast::NodeId, _:()) { let (is_item_fn, is_unsafe_fn) = match *fn_kind { visit::fk_item_fn(_, _, purity, _) => (true, purity == ast::unsafe_fn), visit::fk_method(_, _, method) => (true, method.purity == ast::unsafe_fn), _ => (false, false), }; let old_unsafe_context = self.unsafe_context; if is_unsafe_fn { self.unsafe_context = UnsafeFn } else if is_item_fn { self.unsafe_context = SafeContext } </ins> <del> visit::walk_fn(self, fn_kind, fn_decl, block, span, node_id, ()); </del> <ins> visit::walk_fn(self, fn_kind, fn_decl, block, span, node_id, ()); </ins> <del> self.context.unsafe_context = old_unsafe_context </del> <ins> self.unsafe_context = old_unsafe_context </ins> } <del> fn visit_block(&mut self, block:&Block, _:()) { let old_unsafe_context = self.context.unsafe_context; let is_unsafe = match block.rules { ast::UnsafeBlock(*) => true, ast::DefaultBlock => false }; if is_unsafe && self.context.unsafe_context == SafeContext { self.context.unsafe_context = UnsafeBlock(block.id) } </del> <ins> fn visit_block(&mut self, block: &ast::Block, _:()) { let old_unsafe_context = self.unsafe_context; let is_unsafe = match block.rules { ast::UnsafeBlock(*) => true, ast::DefaultBlock => false }; if is_unsafe && self.unsafe_context == SafeContext { self.unsafe_context = UnsafeBlock(block.id) } </ins> <del> visit::walk_block(self, block, ()); </del> <ins> visit::walk_block(self, block, ()); </ins> <del> self.context.unsafe_context = old_unsafe_context </del> <ins> self.unsafe_context = old_unsafe_context </ins> } <del> fn visit_expr(&mut self, expr:@Expr, _:()) { match expr.node { ExprMethodCall(callee_id, _, _, _, _, _) => { let base_type = ty::node_id_to_type(self.tcx, callee_id); debug2!("effect: method call case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); if type_is_unsafe_function(base_type) { self.require_unsafe(expr.span, "invocation of unsafe method") } </del> <ins> fn visit_expr(&mut self, expr: @ast::Expr, _:()) { match expr.node { ast::ExprMethodCall(callee_id, _, _, _, _, _) => { let base_type = ty::node_id_to_type(self.tcx, callee_id); debug2!("effect: method call case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); if type_is_unsafe_function(base_type) { self.require_unsafe(expr.span, "invocation of unsafe method") </ins> } <del> ExprCall(base, _, _) => { let base_type = ty::node_id_to_type(self.tcx, base.id); debug2!("effect: call case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); if type_is_unsafe_function(base_type) { self.require_unsafe(expr.span, "call to unsafe function") } </del> <ins> } ast::ExprCall(base, _, _) => { let base_type = ty::node_id_to_type(self.tcx, base.id); debug2!("effect: call case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); if type_is_unsafe_function(base_type) { self.require_unsafe(expr.span, "call to unsafe function") </ins> } <del> ExprUnary(_, UnDeref, base) => { let base_type = ty::node_id_to_type(self.tcx, base.id); debug2!("effect: unary case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); match ty::get(base_type).sty { ty_ptr(_) => { self.require_unsafe(expr.span, "dereference of unsafe pointer") } _ => {} </del> <ins> } ast::ExprUnary(_, ast::UnDeref, base) => { let base_type = ty::node_id_to_type(self.tcx, base.id); debug2!("effect: unary case, base type is {}", ppaux::ty_to_str(self.tcx, base_type)); match ty::get(base_type).sty { ty::ty_ptr(_) => { self.require_unsafe(expr.span, "dereference of unsafe pointer") </ins> } <ins> _ => {} </ins> } <del> ExprInlineAsm(*) => { self.require_unsafe(expr.span, "use of inline assembly") } ExprPath(*) => { match ty::resolve_expr(self.tcx, expr) { ast::DefStatic(_, true) => { self.require_unsafe(expr.span, "use of mutable static") } _ => {} </del> <ins> } ast::ExprAssign(base, _) | ast::ExprAssignOp(_, _, base, _) => { self.check_str_index(base); } ast::ExprAddrOf(ast::MutMutable, base) => { self.check_str_index(base); } ast::ExprInlineAsm(*) => { self.require_unsafe(expr.span, "use of inline assembly") } ast::ExprPath(*) => { match ty::resolve_expr(self.tcx, expr) { ast::DefStatic(_, true) => { self.require_unsafe(expr.span, "use of mutable static") </ins> } <ins> _ => {} </ins> } <del> _ => {} </del> } <ins> _ => {} } </ins> <del> visit::walk_expr(self, expr, ()); </del> <ins> visit::walk_expr(self, expr, ()); </ins> } } pub fn check_crate(tcx: ty::ctxt, method_map: method_map, crate: &ast::Crate) { <del> let context = @mut Context { method_map: method_map, unsafe_context: SafeContext, }; </del> let mut visitor = EffectCheckVisitor { tcx: tcx, <del> context: context, </del> <ins> method_map: method_map, unsafe_context: SafeContext, </ins> }; visit::walk_crate(&mut visitor, crate, ());


Question:
As far as I understand, the str types have a pretty strong assumption that they contain valid UTF-8. Any method/function that could break this (such as ) is marked as unsafe. However, it is possible to assign random bytes in the middle of a ~str, breaking the UTF-8 invariant: I think that such assignments should only be allowed in unsafe code. Update: should also be unsafe, IMO.
I had no idea str even allowed index-assign.
forbidding it entirely could also fix the issue, but might be overkill.
Hmm... This could be tricker than just forbidding assignment because this code compiles as well
I suppose we could also forbid (in safe code) to borrow mutable references to individual bytes in a string. Similarly, I believe that should be unsafe (but does not need to be.)
I think we should just forbid index-assign and borrowing mutable references. It can still be done through unsafe methods, but doesn't need to be in the language as a feature. The only language feature we have is raw pointer dereferencing so it's nice to keep it simple.
Nominating for the backwards compatible milestone.
doesn't need to be unsafe because it passes you a raw pointer, which is unusable without
Accepted for well-defined. (Also: document what "unsafe" means, which is a separate issue.)

<ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut s = ~"test"; s[0] = 3; //~ ERROR: not allowed s[0] += 3; //~ ERROR: not allowed { let _a = &mut s[0]; //~ ERROR: not allowed } } </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

<del> // check-fail // edition:2021 // known-bug: #88908 // This should pass, but seems to run into a TAIT bug. #![feature(type_alias_impl_trait)] use std::future::Future; trait Stream { type Item; } struct Empty<T>(T); impl<T> Stream for Empty<T> { type Item = (); } fn empty<T>() -> Empty<T> { todo!() } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a,Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a,Repr>(&'a self) -> Self::LineStreamFut<'a,Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>> ; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async {empty()} } } fn main() {} </del>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

<del> error[E0271]: type mismatch resolving `<Empty<_> as Stream>::Item == Repr` --> $DIR/issue-89008.rs:38:43 | LL |     fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { |                        ----               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type mismatch resolving `<Empty<_> as Stream>::Item == Repr` |                        | |                        this type parameter | note: expected this to be `()` --> $DIR/issue-89008.rs:17:17 | LL |     type Item = (); |                 ^^ = note:   expected unit type `()` found type parameter `Repr` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </del>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Playing around with (the not yet stable) and features I stumbled over the below problem, where type parameters to nested TAIT/GAT with lifetime parameters cause a "this type parameter needs to be std::marker::Sized" compiler error. The following code fails to compile with below compiler error (): In contrast, the following code, without lifetime type parameters compiles without any error. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This gives a different error. Minimized:
GATs issue triage: not blocking. Seems like a TAITs bug; not sure there's anything for GATs to change here.
Compiles just fine now.
I guess this issue can just be closed if there's a test already?
I think test needs to be moved to correct place?
Hello, first time contributing to rust. I was trying to resolve this issue and after looking at the test I am a little confused. To me it looks like the test code is failing correctly and I can't understand where the TAIT bug is. has a concrete type whereas the function is generic over . So to me it looks like the raised error is correct. Changing the implementation to makes the code compile. I am sorry if I am missing something here. If the test is correct then would moving the test to resolve this issue? I also don't think relates to this test.
Yeah, I messed up my minimization. The test should just use the original MCVE in the OP. And that is indeed fixed.
For clarity: this can be closed when the current known-bug test is moved to the main directory for GAT tests and changed to use the OP MCVE.

<ins> // check-pass // edition:2021 #![feature(type_alias_impl_trait)] use std::future::Future; use std::marker::PhantomData; trait Stream { type Item; } struct Empty<T> { _phantom: PhantomData<T>, } impl<T> Stream for Empty<T> { type Item = T; } trait X { type LineStream<'a, Repr>: Stream<Item = Repr> where Self: 'a; type LineStreamFut<'a, Repr>: Future<Output = Self::LineStream<'a, Repr>> where Self: 'a; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr>; } struct Y; impl X for Y { type LineStream<'a, Repr> = impl Stream<Item = Repr>; type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>>; fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> { async { Empty { _phantom: PhantomData } } } } fn main() {} </ins>


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

} else if nanos >= MAX_NANOS_F64 { Err(FromSecsError { kind: FromSecsErrorKind::Overflow }) } else if nanos < 0.0 { <del> Err(FromSecsError { kind: FromSecsErrorKind::Underflow }) </del> <ins> Err(FromSecsError { kind: FromSecsErrorKind::Negative }) </ins> } else { let nanos = nanos as u128; Ok(Duration {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

} else if nanos >= MAX_NANOS_F32 { Err(FromSecsError { kind: FromSecsErrorKind::Overflow }) } else if nanos < 0.0 { <del> Err(FromSecsError { kind: FromSecsErrorKind::Underflow }) </del> <ins> Err(FromSecsError { kind: FromSecsErrorKind::Negative }) </ins> } else { let nanos = nanos as u128; Ok(Duration {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

impl FromSecsError { const fn description(&self) -> &'static str { match self.kind { <del> FromSecsErrorKind::NonFinite => { "got non-finite value when converting float to duration" } </del> <ins> FromSecsErrorKind::NonFinite => "non-finite value when converting float to duration", </ins> FromSecsErrorKind::Overflow => "overflow when converting float to duration", <del> FromSecsErrorKind::Underflow => "underflow when converting float to duration", </del> <ins> FromSecsErrorKind::Negative => "negative value when converting float to duration", </ins> } } }


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

#[derive(Debug, Clone, PartialEq, Eq)] enum FromSecsErrorKind { <del> // Value is not a finite value (either infinity or NaN). </del> <ins> // Value is not a finite value (either + or - infinity or NaN). </ins> NonFinite, // Value is too large to store in a `Duration`. Overflow, <del> // Value is less than `0.0`. Underflow, </del> <ins> // Value is negative. Negative, </ins> }


Question:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics

} } <ins> /// Converts inline const patterns. fn lower_inline_const( &mut self, anon_const: &'tcx hir::AnonConst, id: hir::HirId, span: Span, ) -> PatKind<'tcx> { let anon_const_def_id = self.tcx.hir().local_def_id(anon_const.hir_id); let value = ty::Const::from_inline_const(self.tcx, anon_const_def_id); // Evaluate early like we do in `lower_path`. let value = value.eval(self.tcx, self.param_env); match value.val { ConstKind::Param(_) => { self.errors.push(PatternError::ConstParamInPattern(span)); return PatKind::Wild; } ConstKind::Unevaluated(_) => { // If we land here it means the const can't be evaluated because it's `TooGeneric`. self.tcx.sess.span_err(span, "constant pattern depends on a generic parameter"); return PatKind::Wild; } _ => (), } *self.const_to_pat(value, id, span, false).kind } </ins> /// Converts literals, paths and negation of literals to patterns. /// The special case for negation exists to allow things like `-128_i8` /// which would overflow if we tried to evaluate `128_i8` and then negate /// afterwards. fn lower_lit(&mut self, expr: &'tcx hir::Expr<'tcx>) -> PatKind<'tcx> { <del> if let hir::ExprKind::Path(ref qpath) = expr.kind { *self.lower_path(qpath, expr.hir_id, expr.span).kind } else { let (lit, neg) = match expr.kind { hir::ExprKind::ConstBlock(ref anon_const) => { let anon_const_def_id = self.tcx.hir().local_def_id(anon_const.hir_id); let value = ty::Const::from_inline_const(self.tcx, anon_const_def_id); if matches!(value.val, ConstKind::Param(_)) { let span = self.tcx.hir().span(anon_const.hir_id); self.errors.push(PatternError::ConstParamInPattern(span)); return PatKind::Wild; } return *self.const_to_pat(value, expr.hir_id, expr.span, false).kind; } hir::ExprKind::Lit(ref lit) => (lit, false), hir::ExprKind::Unary(hir::UnOp::Neg, ref expr) => { let lit = match expr.kind { hir::ExprKind::Lit(ref lit) => lit, _ => span_bug!(expr.span, "not a literal: {:?}", expr), }; (lit, true) } _ => span_bug!(expr.span, "not a literal: {:?}", expr), }; let lit_input = LitToConstInput { lit: &lit.node, ty: self.typeck_results.expr_ty(expr), neg }; match self.tcx.at(expr.span).lit_to_const(lit_input) { Ok(val) => *self.const_to_pat(val, expr.hir_id, lit.span, false).kind, Err(LitToConstError::Reported) => PatKind::Wild, Err(LitToConstError::TypeError) => bug!("lower_lit: had type error"), </del> <ins> let (lit, neg) = match expr.kind { hir::ExprKind::Path(ref qpath) => { return *self.lower_path(qpath, expr.hir_id, expr.span).kind; } hir::ExprKind::ConstBlock(ref anon_const) => { return self.lower_inline_const(anon_const, expr.hir_id, expr.span); } hir::ExprKind::Lit(ref lit) => (lit, false), hir::ExprKind::Unary(hir::UnOp::Neg, ref expr) => { let lit = match expr.kind { hir::ExprKind::Lit(ref lit) => lit, _ => span_bug!(expr.span, "not a literal: {:?}", expr), }; (lit, true) </ins> } <ins> _ => span_bug!(expr.span, "not a literal: {:?}", expr), }; let lit_input = LitToConstInput { lit: &lit.node, ty: self.typeck_results.expr_ty(expr), neg }; match self.tcx.at(expr.span).lit_to_const(lit_input) { Ok(val) => *self.const_to_pat(val, expr.hir_id, lit.span, false).kind, Err(LitToConstError::Reported) => PatKind::Wild, Err(LitToConstError::TypeError) => bug!("lower_lit: had type error"), </ins> } } }


Question:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics

#![allow(incomplete_features)] #![feature(inline_const_pat)] <ins> #![feature(generic_const_exprs)] </ins> // rust-lang/rust#82518: ICE with inline-const in match referencing const-generic parameter fn foo<const V: usize>() { <del> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } </del> <ins> match 0 { const { V } => {}, //~^ ERROR const parameters cannot be referenced in patterns [E0158] _ => {}, } } const fn f(x: usize) -> usize { x + 1 } fn bar<const V: usize>() where [(); f(V)]: { match 0 { const { f(V) } => {}, //~^ ERROR constant pattern depends on a generic parameter //~| ERROR constant pattern depends on a generic parameter _ => {}, } </ins> } fn main() { foo::<1>(); <ins> bar::<1>(); </ins> }


Question:
Using a const parameter in an inline const pattern causes an ICE, but only when you don't directly use the parameter. This seems to be the same problem as , although under different circumstances. Using instead of gives Disappointing, but undoubtedly the intended behavior. The above example wouldn't be easy to come across naturally, but if the const parameter was (for example) an array and you tried to index it, the compiler would tell you to use a to do that. This code causes the same ICE: I should note that this issue is only present with the feature and the feature. : <details<summary<strongBacktrace</strong</summary<p</p</details
label +A-const-generics

error[E0158]: const parameters cannot be referenced in patterns <del> --> $DIR/const-match-pat-generic.rs:8:11 </del> <ins> --> $DIR/const-match-pat-generic.rs:9:9 </ins> | <del> LL |     const { V } => {}, |           ^^^^^ </del> <ins> LL |         const { V } => {}, |         ^^^^^^^^^^^ </ins> <del> error: aborting due to previous error </del> <ins> error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: constant pattern depends on a generic parameter --> $DIR/const-match-pat-generic.rs:21:9 | LL |         const { f(V) } => {}, |         ^^^^^^^^^^^^^^ error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0158`.


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

drop(linker); save_temp_bitcode(cgcx, &module, "lto.input"); <del> // Fat LTO also suffers from the invalid DWARF issue similar to Thin LTO. // Here we rewrite all `DICompileUnit` pointers if there is only one `DICompileUnit`. // This only works around the problem when codegen-units = 1. // Refer to the comments in the `optimize_thin_module` function for more details. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); unsafe { llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2) }; if !cu2.is_null() { let _timer = cgcx.prof.generic_activity_with_arg("LLVM_fat_lto_patch_debuginfo", &*module.name); unsafe { llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1) }; save_temp_bitcode(cgcx, &module, "fat-lto-after-patch"); } </del> // Internalize everything below threshold to help strip out more modules and such. unsafe { let ptr = symbols_below_threshold.as_ptr();


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

// an error. let mut cu1 = ptr::null_mut(); let mut cu2 = ptr::null_mut(); <del> llvm::LLVMRustLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </del> <ins> llvm::LLVMRustThinLTOGetDICompileUnit(llmod, &mut cu1, &mut cu2); </ins> if !cu2.is_null() { let msg = "multiple source DICompileUnits found"; return Err(write::llvm_err(&diag_handler, msg));


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

let _timer = cgcx .prof .generic_activity_with_arg("LLVM_thin_lto_patch_debuginfo", thin_module.name()); <del> llvm::LLVMRustLTOPatchDICompileUnit(llmod, cu1); </del> <ins> llvm::LLVMRustThinLTOPatchDICompileUnit(llmod, cu1); </ins> save_temp_bitcode(cgcx, &module, "thin-lto-after-patch"); }


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

len: usize, out_len: &mut usize, ) -> *const u8; <del> pub fn LLVMRustLTOGetDICompileUnit(M: &Module, CU1: &mut *mut c_void, CU2: &mut *mut c_void); pub fn LLVMRustLTOPatchDICompileUnit(M: &Module, CU: *mut c_void); </del> <ins> pub fn LLVMRustThinLTOGetDICompileUnit( M: &Module, CU1: &mut *mut c_void, CU2: &mut *mut c_void, ); pub fn LLVMRustThinLTOPatchDICompileUnit(M: &Module, CU: *mut c_void); </ins> pub fn LLVMRustLinkerNew(M: &Module) -> &mut Linker<'_>; pub fn LLVMRustLinkerAdd(


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See // the comment in `back/lto.rs` for why this exists. extern "C" void <del> LLVMRustLTOGetDICompileUnit(LLVMModuleRef Mod, </del> <ins> LLVMRustThinLTOGetDICompileUnit(LLVMModuleRef Mod, </ins> DICompileUnit **A, DICompileUnit **B) { Module *M = unwrap(Mod);


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See // the comment in `back/lto.rs` for why this exists. extern "C" void <del> LLVMRustLTOPatchDICompileUnit(LLVMModuleRef Mod, DICompileUnit *Unit) { </del> <ins> LLVMRustThinLTOPatchDICompileUnit(LLVMModuleRef Mod, DICompileUnit *Unit) { </ins> Module *M = unwrap(Mod); // If the original source module didn't have a `DICompileUnit` then try to


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

<ins> // Caveat - gdb doesn't know about UTF-32 character encoding and will print a // rust char as only its numerical value. // min-lldb-version: 310 // min-gdb-version: 8.0 // no-prefer-dynamic // compile-flags:-g -C lto // gdb-command:run // gdbg-command:print 'basic_types_globals::B' // gdbr-command:print B // gdb-check:$1 = false // gdbg-command:print 'basic_types_globals::I' // gdbr-command:print I // gdb-check:$2 = -1 // gdbg-command:print 'basic_types_globals::C' // gdbr-command:print C // gdbg-check:$3 = 97 // gdbr-check:$3 = 97 // gdbg-command:print/d 'basic_types_globals::I8' // gdbr-command:print I8 // gdb-check:$4 = 68 // gdbg-command:print 'basic_types_globals::I16' // gdbr-command:print I16 // gdb-check:$5 = -16 // gdbg-command:print 'basic_types_globals::I32' // gdbr-command:print I32 // gdb-check:$6 = -32 // gdbg-command:print 'basic_types_globals::I64' // gdbr-command:print I64 // gdb-check:$7 = -64 // gdbg-command:print 'basic_types_globals::U' // gdbr-command:print U // gdb-check:$8 = 1 // gdbg-command:print/d 'basic_types_globals::U8' // gdbr-command:print U8 // gdb-check:$9 = 100 // gdbg-command:print 'basic_types_globals::U16' // gdbr-command:print U16 // gdb-check:$10 = 16 // gdbg-command:print 'basic_types_globals::U32' // gdbr-command:print U32 // gdb-check:$11 = 32 // gdbg-command:print 'basic_types_globals::U64' // gdbr-command:print U64 // gdb-check:$12 = 64 // gdbg-command:print 'basic_types_globals::F32' // gdbr-command:print F32 // gdb-check:$13 = 2.5 // gdbg-command:print 'basic_types_globals::F64' // gdbr-command:print F64 // gdb-check:$14 = 3.5 // gdb-command:continue #![allow(unused_variables)] #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section] // N.B. These are `mut` only so they don't constant fold away. static mut B: bool = false; static mut I: isize = -1; static mut C: char = 'a'; static mut I8: i8 = 68; static mut I16: i16 = -16; static mut I32: i32 = -32; static mut I64: i64 = -64; static mut U: usize = 1; static mut U8: u8 = 100; static mut U16: u16 = 16; static mut U32: u32 = 32; static mut U64: u64 = 64; static mut F32: f32 = 2.5; static mut F64: f64 = 3.5; fn main() { _zzz(); // #break let a = unsafe { (B, I, C, I8, I16, I32, I64, U, U8, U16, U32, U64, F32, F64) }; } fn _zzz() {()} </ins>


Question:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?

<del> // Caveats - gdb prints any 8-bit value (meaning rust I8 and u8 values) // as its numerical value along with its associated ASCII char, there // doesn't seem to be any way around this. Also, gdb doesn't know // about UTF-32 character encoding and will print a rust char as only // its numerical value. </del> <ins> // Caveat - gdb doesn't know about UTF-32 character encoding and will print a // rust char as only its numerical value. </ins> // min-lldb-version: 310 <del> // ignore-gdb // Test temporarily ignored due to debuginfo tests being disabled, see PR 47155 </del> <ins> // min-gdb-version: 8.0 </ins> // compile-flags:-g // gdb-command:run