jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Copyright 2017 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. // #29924 #![feature(const_fn, associated_consts)] trait Trait { const N: usize; } impl Trait { //~^ ERROR the trait `Trait` cannot be made into an object [E0038] const fn n() -> usize { Self::N } } fn main() {} </ins>

Related discussion:
text: I was in the middle of making a big changes to some code when this panic occurred. I was expecting a lot of compiler errors but got a compiler panic instead! :fearful: I ran the build with and the panic still occurred. Run to get this. Here's the full output with : Since I was in the middle of editing, there's no commit to point to, so I just attached my source code as is so you have something to debug. When you download it and run , the compiler should panic. The repo is called . I don't know how to narrow this issue down, or else I would try to find a smaller example for you. Hope this is good enough.
Some context for the change that caused this: Before this error happened, I changed the file . I split into two structs, and . I was relying on the compiler to find all the places where that change would effect things, and it seems that something went wrong in the compiler while trying to do that.
Once I fix that, everything works again. No more compiler panic. So it seems to have something to do with when I split up that struct. All the messed up pattern matches caused a panic. (Actually just fixing 2 broken pattern matches fixed the problem.)
I've just encountered this myself. I managed to reduce it down: It looks like this happens when a closure's body is a single (non-block) expression, and a tuple struct pattern is used somewhere in the expression. A simple workaround (if anyone needs one for some reason), then, is to just make the closure body a block:
Code change:
<ins> // Copyright 2017 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. // #29924 #![feature(const_fn, associated_consts)] trait Trait { const N: usize; } impl Trait { //~^ ERROR the trait `Trait` cannot be made into an object [E0038] const fn n() -> usize { Self::N } } fn main() {} </ins>

Related discussion:
text: Related code: Compiler panic: Note that everything is fine if I annotate the lifetimes: I am running , the MSVC x64 version.
I just ran into this. Managed to reduce the crash to Explicit lifetimes indeed fix it:
don't know if this helps, but I came up with minimal test case
Code change:
<ins> // Copyright 2017 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. // #29924 #![feature(const_fn, associated_consts)] trait Trait { const N: usize; } impl Trait { //~^ ERROR the trait `Trait` cannot be made into an object [E0038] const fn n() -> usize { Self::N } } fn main() {} </ins>

Related discussion:
text: Playground Output: Other example (possibly different bug): Output:
I just got the same ICE on linux with both the and builds. My case is essentially the same. You create an iterator of references to sub-elements of some thing which has been passed in by reference. The compiler should figure out that the iterator can only live as long as the original object, but ICEs instead. ()
Code change:
<ins> // Copyright 2017 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. // #29924 #![feature(const_fn, associated_consts)] trait Trait { const N: usize; } impl Trait { //~^ ERROR the trait `Trait` cannot be made into an object [E0038] const fn n() -> usize { Self::N } } fn main() {} </ins>

Related discussion:
text: Spawned off of There are still some cases where referencing an inaccessible item can cause the compiler to ICE. Here is one crafted example () but if 's module structure is revised then that example may fail to compile without ICE'ing for other reasons, so take care in understanding the issue: the change introduced by is skipping the requirement for stability attributes is slightly too narrow, in that it uses a local notion of pub/non-pub instead of overall accessibility. One simple solution to this may be to just follow the suggestion here and just remove the assertion entirely. (I did not want to adopt that solution for a PR to be backported to beta, but I think it is worth considering doing in nightly alone to resolve this low priority issue.)
Keywords: for better search
Code change:
return; } <ins> // We may fail to resolve higher-ranked ty/const vars that are mentioned by APIT. // AST-based resolution does not care for impl-trait desugaring, which are the // responsibility of lowering. This may create a mismatch between the resolution // AST found (`param_def_id`) which points to HRTB, and what HIR allows. // ``` // fn foo(x: impl for<T> Trait<Assoc = impl Trait2<T>>) {} // ``` // // In such case, walk back the binders to diagnose it properly. let mut scope = self.scope; loop { match *scope { Scope::Binder { where_bound_origin: Some(hir::PredicateOrigin::ImplTrait), .. } => { let guar = self.tcx.sess.emit_err(match self.tcx.def_kind(param_def_id) { DefKind::TyParam => errors::LateBoundInApit::Type { span: self.tcx.hir().span(hir_id), param_span: self.tcx.def_span(param_def_id), }, DefKind::ConstParam => errors::LateBoundInApit::Const { span: self.tcx.hir().span(hir_id), param_span: self.tcx.def_span(param_def_id), }, kind => { bug!("unexpected def-kind: {}", kind.descr(param_def_id.to_def_id())) } }); self.map.defs.insert(hir_id, ResolvedArg::Error(guar)); return; } Scope::Root { .. } => break, Scope::Binder { s, .. } | Scope::Body { s, .. } | Scope::Elision { s, .. } | Scope::ObjectLifetimeDefault { s, .. } | Scope::Supertrait { s, .. } | Scope::TraitRefBoundary { s, .. } | Scope::AnonConstBoundary { s } => { scope = s; } } } </ins> self.tcx.sess.delay_span_bug( self.tcx.hir().span(hir_id), format!("could not resolve {param_def_id:?}"),

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimized
Bisected to :sweatsmile:
Code change:
set -e mkdir -p $HOME/rustsrc $BUILD_SOURCESDIRECTORY/src/ci/init_repo.sh . $HOME/rustsrc <del> condition: and(succeeded(), ne(variables['Agent.OS'], 'Windows_NT')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), ne(variables['Agent.OS'], 'Windows_NT')) </ins> displayName: Check out submodules (Unix) - script: | if not exist D:cacherustsrcNUL mkdir D:cacherustsrc sh src/ci/init_repo.sh . /d/cache/rustsrc <del> condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) </del> <ins> condition: and(succeeded(), not(variables.SKIP_JOB), eq(variables['Agent.OS'], 'Windows_NT')) </ins> displayName: Check out submodules (Windows) # Ensure the `aws` CLI is installed so we can deploy later on, cache docker

Related discussion:
text: This issue is meant to track where on Travis we currently whenever the commit message looks like it updates a submodule. We should enable something similar for Azure Pipelines where whenever a PR is detected as updating a submodule (either via actually looking at the git history or at the git commit message) then we schedule the builder on the PR. The purpose of this PR build is to help weed out errors even sooner than before where we're just running a smoke tests on Linux on each PR.
Code change:
item_segment.args(), item_segment.infer_args, None, <del> ) .0 </del> <ins> ); let assoc_bindings = self.create_assoc_bindings_for_generic_args(item_segment.args()); if let Some(b) = assoc_bindings.first() { Self::prohibit_assoc_ty_binding(self.tcx(), b.span); } args </ins> } /// Instantiates the path for the given trait reference, assuming that it's

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
version = "0.0.0" dependencies = [ "alloc 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "cc 1.0.35 (registry+https://github.com/rust-lang/crates.io-index)", "compiler_builtins 0.1.15 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0",

Related discussion:
text: Every since a recent nightly update, both distributed nightlies and locally built produce backtraces where every level of the stack is represented only by their memory address and the label : Sadly I don't have a more specific repro case, but I can consistently reproduce locally. Older distributed nightlies do not present this behavior.
This happens consistently for me as well (also macOS).
I've been seeing this on Linux too, though it's been at least a week. (It also may have been fixed in a rustc newer than the one servo uses)
We should have tests for backtraces, so they don't regress again in the future.
this is certainly happening on master, and it's been happening for a while, but I assumed it was my env.
It just occurred to me that this might be related to the new symbol mangling (although I doubt it).
I've been experiencing this for about a week now (also on macOS). It definitely started prior to being merged. I also have the following in my :
has absolutely no changes if you don't use the flag, so it's not from there.
It's definitely , I tried before and after. It works if you enable the "coresymbolication" feature, though that's obviously not an option for distribution. I tried the latest master of , but it didn't help.
To confirm, is everyone only experiencing problems on OSX for rustc itself? Are there problems with other projects on OSX? can you please confirm or deny your experience from Linux? Throwing in a new platform here changes this quite a lot
Ok I believe I've found the issue for OSX, but if other platforms are still an issue that would be good to know
I've only experienced this with rustc itself on OSX. Things it builds seem ok, and linux/windows seem to be ok.
No, it's still happening on Linux as of yesterday (I can try again today). I also assumed it was my env.
I think the Linux issue is separate since it's been happening much longer than the OSX one
Hey, this seems to an issue on nightly for Windows (msvc) as well: This uses backtrace via :
if that's only using the crate and not using libstd, can you open an issue on the repository? The OSX issue should be fixed in , which I'd like to finish testing and then I'll send an update to libstd.
Code change:
version = "0.0.0" dependencies = [ "alloc 0.0.0", <del> "backtrace 0.3.25 (registry+https://github.com/rust-lang/crates.io-index)", </del> <ins> "backtrace 0.3.29 (registry+https://github.com/rust-lang/crates.io-index)", </ins> "cc 1.0.35 (registry+https://github.com/rust-lang/crates.io-index)", "compiler_builtins 0.1.15 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0",

Related discussion:
text: That could affect Linux as well but I doubt it, so if there are persisting Linux/Windows issues please feel free to let me know. If you can create an isolated problem which uses the crate rather than libstd that's even better!
Done: rust-lang/backtrace-rs
Code change:
<ins> // Copyright 2015 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. // Make sure the type inference for the new range expression work as // good as the old one. Check out issue #21672, #21595 and #21649 for // more details. fn main() { let xs = (0..8).map(|i| i == 1u64).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs = (0..8).map(|i| 1u64 == i).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs: Vec<u8> = (0..10).collect(); assert_eq!(xs.len(), 10); for x in 0..10 { x % 2; } for x in 0..100 { x as f32; } let array = [true, false]; for i in 0..1 { array[i]; } } </ins>

Related discussion:
text: However, it doesn't have to be this way, but it'd take some work to massage the trait matching infrastructure, since impl selection doesn't presently have access to output binding information, that'd have to be propagated inward. It might be interesting to try and address this in a more wholistic way (i.e., something that accounts for the full set of facts that are registered). particular, the important constraint that we MUST maintain is that, during trans, given the input types, we can derive the output type. But it's permissible for us to use the output type to derive the input type during type checking, since once inference is done, we then have the input types to supply during trans so that we can rederive the output.
The fix is very simple then. Thanks for helping diagnose the problem and pointing to the right direction.
Code change:
<ins> // Copyright 2015 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. // Make sure the type inference for the new range expression work as // good as the old one. Check out issue #21672, #21595 and #21649 for // more details. fn main() { let xs = (0..8).map(|i| i == 1u64).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs = (0..8).map(|i| 1u64 == i).collect::<Vec<_>>(); assert_eq!(xs[1], true); let xs: Vec<u8> = (0..10).collect(); assert_eq!(xs.len(), 10); for x in 0..10 { x % 2; } for x in 0..100 { x as f32; } let array = [true, false]; for i in 0..1 { array[i]; } } </ins>

Related discussion:
text: This code compiled fine before 1.0.0-nightly ( 2015-01-23 16:08:14 +0000): But with that version, it now gives this error:
changing to should work, I stumbled upon the same thing and the doc seems to be updated: (see at the very bottom) EDIT: Maybe worth noting that these work:
That's just a workaround to a bug (not sure if that was implied). should fall back to being as per the existence of the integer fallback.
I don't necessarily expect this to work. Fallback comes late in the process, once all constraints are known, but (like method dispatch) requires the type being cast to be known immediately.
It's plausible we could make it work since we know that the type is integral (I imagine that's how it ever worked, not sure what would have changed that, though it might have been something I did). It occurs to me though that this is somewhat forward-hostile to the idea of integer literals ever being used for anything other than plain ints (but enabling such a feature may well wind up requiring opt-in anyway).
(Though really it's sort of silly that requires the type to be known immediately, so I guess fixing that would be another way to ease the forward compat fears.)
I thought this was a feature because it's saying that it doesn't know if it's or for example. Would it assume it's signed only if it contains negative numbers in the range? EDIT3: what said makes sense: EDIT2: ignore the following, my bad But I might be missing something because this doesn't output anything from : EDIT: just realized -1u32 is too big so the following makes sense: There's no output from , unless using
Code change:
<del> Subproject commit 2b9c52f66815bb8d6ea74a4b26df3410602be9b0 </del> <ins> Subproject commit 585a6eb3ebf7c40fd7c1b23e3ece557b3cc2aa36 </ins>

Related discussion:
text: Hi, Building in release mode with a freshly updated nightly fails with a SIGSEGV (or STATUSACCESSVIOLATION on Windows). This doesn't occur on or , or when building with any profile that has . I stumbled upon this while trying to measure the performance impact of , which branches from at and suffers from the same issue. I don't know why, but the problem only appears on (that I'm aware of): fails, while any other crate within the same repo works (provided they don't depend on )? : The same issue arises with the same version of nightly on Windows. <details<summaryBacktrace</summary<p</p</details
Could you check which nightly and PR caused this regression with ?
Additionally, are you able to get a backtrace with a debugger?
Sure, I'll run the bisect tomorrow morning (CET). I'll try, but if the builds don't already have debug symbols, I'm not sure how to have x.py spit them out. No need to reply if they're already in there, but if they aren't, instructions would be appreciated :)
We do ship debug symbols, they may be in a rustup component instead of shipped by default. rustc-dev, I believe?
Thanks, I'll check that out in roughly 8 hours :)
We do always ship symbols in the same binary, but we never ship debuginfo.
Preliminary reduction for :
Minimized:
Upstream fix:
Thank you so much for taking the issue, I did try bisecting, but you had located the issue by the time I made any progress :)
Code change:
None } } <ins> Target::AssocConst => { let parent_hir_id = self.tcx.hir().get_parent_item(hir_id); let containing_item = self.tcx.hir().expect_item(parent_hir_id); // We can't link to trait impl's consts. let err = "associated constant in trait implementation block"; match containing_item.kind { ItemKind::Impl { of_trait: Some(_), .. } => Some(err), _ => None, } } </ins> _ => None, } { self.tcx .sess .struct_span_err( meta.span(), <del> &format!("`#[doc(alias = "...")]` isn't allowed on {}", err,), </del> <ins> &format!("`#[doc(alias = "...")]` isn't allowed on {}", err), </ins> ) .emit(); }

Related discussion:
text: Now that has been merged, only a few checks remain to be in order to stabilize this feature. First, we need to actually perform those checks in the compiler directly instead of rustdoc. You mentioned other checks too ? This issue is part of .
We should reject on items that don't actually appear in the search index such as blocks and s.
Ok, makes sense! Last question: I remember you telling that you'd prefer this check in rustc directly instead of rustdoc. I can move things there, just wanted to check one last time before doing it.
Yeah, rustc validates some attributes in and it might make sense to validate the attribute there as well.
Since has been merged, we can close this issue.
We're still not rejecting on associated s in trait impls like:
Ok! Putting on hold then!
Code change:
let mut llvm_args = Vec::with_capacity(n_args + 1); llvm::LLVMRustInstallFatalErrorHandler(); <ins> // On Windows, an LLVM assertion will open an Abort/Retry/Ignore dialog // box for the purpose of launching a debugger. However, on CI this will // cause it to hang until it times out, which can take several hours. if std::env::var_os("CI").is_some() { llvm::LLVMRustDisableSystemDialogsOnCrash(); } </ins> fn llvm_arg_to_arg_name(full_arg: &str) -> &str { full_arg.trim().split(|c: char| c == '=' || c.is_whitespace()).next().unwrap_or("")

Related discussion:
text: The Windows CI build with LLVM assertions enabled recently hung without an error message. It turned out to be an LLVM assertion failure resulting in a dialog which needed to be acknowledged, see According to the such a dialog is always displayed, but that is not the whole truth. Apparently can be used to customize assertion failure handling. We should definitely make assertions failures exit with error after printing failure information to stderr instead of displaying a dialog and hanging. label O-windows
Could this be part of why we're getting so many hangs in the CI?
That was responsible for four stuck builds recently. I don't think it was responsible for many timed out builds before that.
Posted with a possible solution.