jiebi/CodeConvo huggingface dataset:
Change:
I have to use some sort of loop construct within a const function. does explain that loop constructs are at the moment not supported, but as I was trying out first and the compiler rejected it, it would have been helpful if the explanation would hint me towards working. I think the doc just needs a small update and I think the file to update is I tried this code: <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
, , and are also allowed, but is not.
if it helps, the reason is forbidden but the others work is that uses and traits in const functions are still unstable (search for 'for loops' on https://rust-).
yeah, that's understandable. The confusion on my side was simply that I didn't know I was allowed to user other control flow constructs until somebody mentioned it on IRC I actually could.

Discussion:
<del> A control-flow expression was used inside a const context. </del> <ins> An unsupported expression was used inside a const context. </ins> Erroneous code example:

}; ``` <del> At the moment, `if` and `match`, as well as the looping constructs `for`, `while`, and `loop`, are forbidden inside a `const`, `static`, or `const fn`. </del> <ins> At the moment, `for` loops, `.await`, and the `Try` operator (`?`) are forbidden inside a `const`, `static`, or `const fn`. </ins> <del> This will be allowed at some point in the future, but the implementation is not yet complete. See the tracking issue for [conditionals] or [loops] in a const context for the current status. </del> <ins> This may be allowed at some point in the future, but the implementation is not yet complete. See the tracking issues for [`async`] and [`?`] in `const fn`, and (to support `for` loops in `const fn`) the tracking issues for [`impl const Trait for Ty`] and [`&mut T`] in `const fn`. </ins> <del> [conditionals]: https://github.com/rust-lang/rust/issues/49146 [loops]: https://github.com/rust-lang/rust/issues/52000 </del> <ins> [`async`]: https://github.com/rust-lang/rust/issues/69431 [`?`]: https://github.com/rust-lang/rust/issues/74935 [`impl const Trait for Ty`]: https://github.com/rust-lang/rust/issues/67792 [`&mut T`]: https://github.com/rust-lang/rust/issues/57349 </ins>
Change:
Miri is in "test pass" state in https://rust-lang- since rust-lang/rust and rust-lang/rust has been closed. Also I didn't found , so I assume Miri should build from the branch of it. However, Miri in the latest nightly (, rust-lang/rust from . rust-lang/rust already contains rust-lang/rust. Actually Miri is missing since , and is still missing even rust-lang/rust has been merged. I can't find any additional information about Miri in the latest nightly. What's going on with it? Edit: I mentioned the wrong PR. It should be instead of .
Oh, I had not even noticed this, thanks! This looks like a rustc issue, so I'll move the issue there.
Cc any idea why Miri is missing from ?
The log at looks good in terms of tests, but one thing is strange: Notice the "test-fail" for "cargo-miri". However, I don't think anything actually cares about that test state, so I am not sure if this is actually a problem. I guess something is going wrong when doing the nightly release (Miri has special logic there to avoid shipping when tests fail), but I do not know how to access the logs for that.
Thanks for the report! This is a bug in our release process: Release process logs are not available publicly unfortunately :(
rust-lang/promote-release has been closed, but Miri is still not available due to . Maybe Miri will be available tomorrow and this can be closed then.

Discussion:
<del> Subproject commit df4109151b6870cdb6d170326d1c099746990ea8 </del> <ins> Subproject commit c8f51fc5a772a125f3b3ad7fe46609a4638ca509 </ins>
Change:
Upstream ticket: I tried this code: I expected to see this happen: explanation The code compiles on but fails to build on rustc master which I assumes makes this a regression: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: <!-- version --<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
cargo-bisect-rustc says the regression is caused by
Maybe ?
cc
I assume this is the cause of the error:
MCVE:
Could be .
Reverting fixes the regression. The regression also appears in the for , but it appears either it was overlooked or the decision was made to merge anyway? cc
Assigning as and removing .
we probably have to update something here:
label E-needs-bisection E-needs-mcve

Discussion:
let mut typeck_results = self.fcx.typeck_results.borrow_mut(); // All valid indexing looks like this; might encounter non-valid indexes at this point. <del> let base_ty = typeck_results.expr_ty_adjusted_opt(&base).map(|t| t.kind()); </del> <ins> let base_ty = typeck_results .expr_ty_adjusted_opt(&base) .map(|t| self.fcx.resolve_vars_if_possible(t).kind()); </ins> if base_ty.is_none() { // When encountering `return [0][0]` outside of a `fn` body we can encounter a base // that isn't in the type table. We assume more relevant errors have already been

<ins> // check-pass // Regression test for issue #79152 // // Tests that we can index an array in a const function const fn foo() { let mut array = [[0; 1]; 1]; array[0][0] = 1; } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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!
That PR was a rollup. Without having looked at any logs, Edit: Oh uh, nope, sorry, had a different change in mind. Will take a closer look. :)
Ah, the problem is The call to was changed from to try first. Returning null there would work fine, as it still falls back to . Edit: And the same for .

Discussion:
<del> Subproject commit df4109151b6870cdb6d170326d1c099746990ea8 </del> <ins> Subproject commit c8f51fc5a772a125f3b3ad7fe46609a4638ca509 </ins>
Change:
Running yields: This works in July 27 rustc nightly. It's broken in the Oct 6 rustc nightly, but possibly earlier.
It looks like is responsible; presumably the compat_fn! macro doesn't handle the attribute correctly.
I suspect
Verified that the 9/30 nightly works.
Assigning and removing as in the prioritization working group.

Discussion:
} } <ins> $(#[$meta])* </ins> pub use $symbol::call as $symbol; )*) }
Change:
<!-- 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. --I wanted to change to use the pattern in the code below (which changes variance w.r.t to ), but got an ICE. I managed to reduce it the code below. The same code with the current definition of works (same as ): <!-- 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<details<summary<stronglog with RUSTCLOG=rustctrait_selection::traits::specialize</strong</summary<p</p</details
This ICEs since modify labels: +regression-from-stable-to-stable
Assigning as discussed as part of the and removing .
No longer appears to ICE since

Discussion:
<ins> #![feature(min_specialization)] use std::fmt::{self, Display}; pub enum Cow<'a, B: ?Sized + 'a, O = <B as ToOwned>::Owned> where B: ToOwned, { Borrowed(&'a B), Owned(O), } impl ToString for Cow<'_, str> { fn to_string(&self) -> String { String::new() } } impl<B: ?Sized> Display for Cow<'_, B> { //~ ERROR: the trait bound `B: Clone` is not satisfied [E0277] fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { //~ ERROR: the trait bound `B: Clone` is not satisfied [E0277] write!(f, "foo") } } fn main() {} </ins>

<ins> error[E0277]: the trait bound `B: Clone` is not satisfied --> $DIR/issue-79224.rs:18:17 | LL | impl<B: ?Sized> Display for Cow<'_, B> { |                 ^^^^^^^ the trait `Clone` is not implemented for `B` | = note: required because of the requirements on the impl of `ToOwned` for `B` help: consider further restricting this bound | LL | impl<B: ?Sized + std::clone::Clone> Display for Cow<'_, B> { |                +++++++++++++++++++ error[E0277]: the trait bound `B: Clone` is not satisfied --> $DIR/issue-79224.rs:19:5 | LL | /     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { LL | |         write!(f, "foo") LL | |     } | |_____^ the trait `Clone` is not implemented for `B` | = note: required because of the requirements on the impl of `ToOwned` for `B` help: consider further restricting this bound | LL | impl<B: ?Sized + std::clone::Clone> Display for Cow<'_, B> { |                +++++++++++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Change:
This issue seems to be specific to the trait. : label A-const-generics F-constevaluatablechecked T-compiler
Also, is it expected that the where bounds need to be repeated in each of the type's trait impls?
Yes, bounds on type definitions need to be repeated in impls, at least until are introduced.
Is anyone aware of a way to work around this issue at the moment?

Discussion:
// This closure is a more robust way to check `Predicate` equality // than simple `==` checks (which were the previous implementation). <del> // It relies on `ty::relate` for `TraitPredicate` and `ProjectionPredicate` // (which implement the Relate trait), while delegating on simple equality // for the other `Predicate`. </del> <ins> // It relies on `ty::relate` for `TraitPredicate`, `ProjectionPredicate`, // `ConstEvaluatable` and `TypeOutlives` (which implement the Relate trait), // while delegating on simple equality for the other `Predicate`. </ins> // This implementation solves (Issue #59497) and (Issue #58311). // It is unclear to me at the moment whether the approach based on `relate` // could be extended easily also to the other `Predicate`.

(ty::PredicateKind::Projection(a), ty::PredicateKind::Projection(b)) => { relator.relate(predicate.rebind(a), p.rebind(b)).is_ok() } <ins> ( ty::PredicateKind::ConstEvaluatable(def_a, substs_a), ty::PredicateKind::ConstEvaluatable(def_b, substs_b), ) => tcx.try_unify_abstract_consts(((def_a, substs_a), (def_b, substs_b))), (ty::PredicateKind::TypeOutlives(a), ty::PredicateKind::TypeOutlives(b)) => { relator.relate(predicate.rebind(a.0), p.rebind(b.0)).is_ok() } </ins> _ => predicate == p, } };

<ins> //check-pass #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] struct Foo<const N: usize> where [(); N + 1]: ; impl<const N: usize> Drop for Foo<N> where [(); N + 1]: , { fn drop(&mut self) {} } fn main() {} </ins>
Change:
renders this as follows. Notice that the blue banner appears for Eq (I guess because the trait is empty) but not for PartialEq. I believe that it should consistently appear for neither Eq nor PartialEq, or both Eq and PartialEq. <img src="https://user-" width="300"<brExpanding the [+] next to impl PartialEq shows the other blue banner but this issue is about the default appearance on page load. <img src="https://user-" width="300"<brMentioning tracking issue . Mentioning
Ohh, the collapse settings are fun; I never noticed this in because I have which seems to imply not collapsing the trait implementations. Clearing that setting from local storage, or if it's set to does this; I think it should be possible to make it so that having this block there either ignores collapsing so it shows always, (though this may be inconsistent with how it works with functions), or make it default to uncollapsing the trait.
(Something else to check at the same time: what happens with JS disabled)
Nothing is collapsed when JS is disabled. :) I'll take a look tomorrow.
The toggle, and the items it toggles, are hidden when JS is disabled.
Hum... I suppose it's a new issue then. Something to add in .

Discussion:
var dontApplyBlockRule = toggle.parentNode.parentNode.id !== "main"; if (action === "show") { removeClass(relatedDoc, "fns-now-collapsed"); <del> removeClass(docblock, "hidden-by-usual-hider"); </del> <ins> // Stability information is never hidden. if (hasClass(docblock, "stability") === false) { removeClass(docblock, "hidden-by-usual-hider"); } </ins> onEachLazy(toggle.childNodes, adjustToggle(false, dontApplyBlockRule)); onEachLazy(relatedDoc.childNodes, implHider(false, dontApplyBlockRule)); } else if (action === "hide") { addClass(relatedDoc, "fns-now-collapsed"); <del> addClass(docblock, "hidden-by-usual-hider"); </del> <ins> // Stability information should be shown even when detailed info is hidden. if (hasClass(docblock, "stability") === false) { addClass(docblock, "hidden-by-usual-hider"); } </ins> onEachLazy(toggle.childNodes, adjustToggle(true, dontApplyBlockRule)); onEachLazy(relatedDoc.childNodes, implHider(true, dontApplyBlockRule)); }
Change:
<!-- 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 <!-- 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
MCVE: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than the other ICEs that are outside of rustdoc proper.
No longer crashing

Discussion:
<ins> pub fn f1<T>(x: T::A) {} //~^ ERROR //~^^ ERROR </ins>

<ins> error[E0220]: associated type `A` not found for `T` --> $DIR/issue-79465.rs:1:20 | LL | pub fn f1<T>(x: T::A) {} |                    ^ associated type `A` not found error[E0220]: associated type `A` not found for `T` --> $DIR/issue-79465.rs:1:20 | LL | pub fn f1<T>(x: T::A) {} |                    ^ associated type `A` not found error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0220`. </ins>
Change:
<!-- 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 <!-- 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
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `

Discussion:
<ins> fn g() where 'static: 'static, dyn 'static: 'static + Copy, //~ ERROR at least one trait is required for an object type { } fn main() {} </ins>

<ins> error[E0224]: at least one trait is required for an object type --> $DIR/issue-79467.rs:4:5 | LL |     dyn 'static: 'static + Copy, |     ^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0224`. </ins>
Change:
<!-- 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
I'm seeing this one as well. Host is a standard Github Actions container. Not sure if the below information is helpful but its additional to the above posted by HYG-YT.
I have to temporarily degrade the version of my nightly installation to 11-24 to make sure everything is functional (it's a discord bot made with twilight-rs)
Similarly, I'm attempting to knock my version back a couple of days as well-- yet to succeed but that's mostly me wrestling with my actions configuration.
I have the same on my Raspberry Pi 3 (Debian 10, Linux 4.19.66):
I can reproduce with on . searched toolchains through regression in Regressed in , cc
MCVE:
Assigning .
I updated to the latest nightly (2020-11-29) and it still fails.
Wait for next nightly. The current one doesn't contain the fix PR.
Got it!
you can also try the latest master using

Discussion:
self.visit_nested_impl_item(id); } <ins> fn visit_foreign_item_ref(&mut self, fi: &'hir ForeignItemRef<'hir>) { // Do not visit the duplicate information in ForeignItemRef. We want to // map the actual nodes, not the duplicate ones in the *Ref. let ForeignItemRef { id, ident: _, span: _, vis: _ } = *fi; self.visit_nested_foreign_item(id); } </ins> } struct HirItemLike<T> {

// different owner. } <ins> fn visit_foreign_item_ref(&mut self, _: &'hir hir::ForeignItemRef<'hir>) { // Explicitly do nothing here. ForeignItemRefs contain hir::Visibility // values that actually belong to an ForeignItem instead of the ItemKind::ForeignMod // we are currently in. So for those it's correct that they have a // different owner. } </ins> fn visit_generic_param(&mut self, param: &'hir hir::GenericParam<'hir>) { if let hir::GenericParamKind::Type { synthetic: Some(hir::SyntheticTyParamKind::ImplTrait),

<ins> // Test for #79487 // check-pass #![allow(dead_code)] mod sha2 { extern "C" { pub(super) fn GFp_sha512_block_data_order(); } } fn main() {} </ins>
Change:
<!-- 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 <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label -T-compiler +T-rustdoc
MCVE: I expect this is the same sort of issue as where rustdoc ignores errors that the compiler requires to be emitted. Assigning P-low by the same rationale as
I found a similar duplicate.
Triage: fixed by , marking as .

Discussion:
<ins> // only-x86_64-unknown-linux-gnu #![feature(const_transmute)] const ZST: &[u8] = unsafe { std::mem::transmute(1usize) }; //~ ERROR cannot transmute between types of different sizes, or dependently-sized types </ins>

<ins> error[E0512]: cannot transmute between types of different sizes, or dependently-sized types --> $DIR/issue-79494.rs:5:29 | LL | const ZST: &[u8] = unsafe { std::mem::transmute(1usize) }; |                             ^^^^^^^^^^^^^^^^^^^ | = note: source type: `usize` (64 bits) = note: target type: `&[u8]` (128 bits) error: aborting due to previous error For more information about this error, try `rustc --explain E0512`. </ins>
Change:
Building with leads to . <!-- 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. --: From bisecting previous nightlies, this is a regression between 2020-09-03 and 2020-09-04 . Within ..., it looks like is related. Cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is a workaround.
Minimal reproduction without Cargo: <details<summaryFull output</summary</details
I am also seeing this panic, though perhaps unrelated because I don't have those flags. I don't have a minimal example yet. Here's my trace. Let me know if I should make another bug.
I found a minimal example and opened a new issue, . Same error message, very different example. Seems unrelated.

Discussion:
let mut fuel = self.optimization_fuel.lock(); ret = fuel.remaining != 0; if fuel.remaining == 0 && !fuel.out_of_fuel { <del> self.warn(&format!("optimization-fuel-exhausted: {}", msg())); </del> <ins> if self.diagnostic().can_emit_warnings() { // We only call `msg` in case we can actually emit warnings. // Otherwise, this could cause a `delay_good_path_bug` to // trigger (issue #79546). self.warn(&format!("optimization-fuel-exhausted: {}", msg())); } </ins> fuel.out_of_fuel = true; } else if fuel.remaining > 0 { fuel.remaining -= 1;

<ins> // Regression test for the ICE described in #79546. // compile-flags: --cap-lints=allow -Zfuel=issue79546=0 // check-pass #![crate_name="issue79546"] struct S; fn main() {} </ins>
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Hello! I'm observing a compilation regression coming from 1.47 to 1.48. Just an with only a dependency segfaults when building it with: System logs: GDB backtrace: Versions and also have this issue. Without these RUSTFLAGS it builds fine, it also builds fine when I build in debug mode. No problems at all when building that project on version 1.47.0. My system info:
This looks like it might be a duplicate of but it's great to have a smaller testcase than rustc itself!
The backtrace looks really similar indeed!
Steps: Result: How to make it not segfault, do any of the below: replace step 4 with don't use use or (preview doesn't work for me in github: so if it looks bad I'll try to edit)
Looks like a side-effect of , which exposed an existing bug in loop vectorize
This
Can confirm that is gone after applying (but without the test case fix which doesn't yet exist in rust 1.48.0 on gentoo)

Discussion:
// FIXME(eddyb) producing readable type names for trait objects can result // in problematically distinct types due to HRTB and subtyping (see #47638). // ty::Dynamic(..) | <del> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str if !cx.sess().fewer_names() => { </del> <ins> ty::Adt(..) | ty::Closure(..) | ty::Foreign(..) | ty::Generator(..) | ty::Str => { </ins> let mut name = with_no_trimmed_paths(|| layout.ty.to_string()); if let (&ty::Adt(def, _), &Variants::Single { index }) = (layout.ty.kind(), &layout.variants)

} Some(name) } <del> ty::Adt(..) => { // If `Some` is returned then a named struct is created in LLVM. Name collisions are // avoided by LLVM (with increasing suffixes). If rustc doesn't generate names then that // can improve perf. Some(String::new()) } </del> _ => None, };

<del> // build-pass </del> <ins> // ignore-test // FIXME(const_generics): This test causes an ICE after reverting #76030. </ins> #![allow(incomplete_features)] #![feature(const_generics)]