jiebi/CodeConvo huggingface dataset:
Change:
} TerminatorKind::SwitchInt {..} | <del> TerminatorKind::DropAndReplace { .. } | </del> TerminatorKind::Resume | TerminatorKind::Abort | TerminatorKind::GeneratorDrop |

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
<ins> error[E0277]: the trait bound `(): Impossible` is not satisfied --> $DIR/dont-ice-when-body-tainted-by-errors.rs:19:23 | LL |         trait_error::<()>(); |                       ^^ the trait `Impossible` is not implemented for `()` | help: this trait has no implementations, consider adding one --> $DIR/dont-ice-when-body-tainted-by-errors.rs:7:1 | LL | trait Impossible {} | ^^^^^^^^^^^^^^^^ note: required by a bound in `trait_error` --> $DIR/dont-ice-when-body-tainted-by-errors.rs:8:19 | LL | fn trait_error<T: Impossible>() {} |                   ^^^^^^^^^^ required by this bound in `trait_error` error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'we captured CapturedPlace {'', 'thread 'rustc' panicked at 'we captured CapturedPlace {'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
probably also caused by ?
yep ill put up a fix in a few
Change:
/// Unix-specific extensions to `std::process::ExitStatus` #[stable(feature = "rust1", since = "1.0.0")] pub trait ExitStatusExt { <ins> /// Creates a new `ExitStatus` from the raw underlying `i32` return value of /// a process. #[unstable(feature = "exit_status_from", issue = "32713")] fn from_raw(raw: i32) -> Self; </ins> /// If the process was terminated by a signal, returns that signal. #[stable(feature = "rust1", since = "1.0.0")] fn signal(&self) -> Option<i32>;

Discussion:
Because has a private field it is impossible to create one in user code, one must actually execute a process. This prevents testing/mocking. My use case is that I have some function which runs a process and generates data, however, for testing I want to mock the test run and just return a success exit status and some data. I can't do that because I can't create my own objects. At the least there should be a way to create a success . Preferably, there would be a way to create various fail statuses too.
Should the constructor just take an ?
I've also wanted a basically "raw constructor" in the past. I'd be fine adding some extensions which allow construction from a or ( and )
+1 I’d like to extend , but I cannot reuse for return value because I can’t construct . :(
I've opened a PR for this over at
Great, thanks! :+1:
This would help n00bs like me who start out by copying the example code and tweaking it: This example is a special case that only happens to work if the contains a or something else that immediately exits. Otherwise you need to create your own struct to return which is currently impossible.
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.
Change:
ref prior_arms, opt_suggest_box_span, scrut_span, <ins> scrut_hir_id, </ins> .. }) => match source { hir::MatchSource::TryDesugar(scrut_hir_id) => {

Discussion:
I tried this code (): I expected to see this happen: A compiler error about missing between and Instead, this happened: This is very confusing, because I "know" that return type is which is coercible to anything else (or whatever is the technical explanation for "we can really ignore the return type of "), so it should not ever be present in error messages about mistyping stuff. <!-- 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 issue is also present in 1.34.2 (from a year ago), and in two-week-old nightly (rustc 1.45.0-nightly ( 2020-05-11)) p.s.: When deminimizing the issue, i realized that it's even more confusing when match is the last statement in a for loop (as it was in my real code), i.e.: gives the same error message about incompatible match arms.
The s coerces to because the whole needs to evaluate as a statement, not an expression because its return value is ignored. Adding a trailing "fixes" the code.
As far as I can tell, didn't fix this issue (you didn't add a test for it either), and the two UI tests that the PR did touch, the suggestion didn't do anything useful -- it only fires when one of the arms is actually evaluated to be type , rather than being constrained to due to (lack of) semicolon.
Actually, we do suggest using a semicolon, but not via . I'm just gonna revert that, and add this as a test.
Change:
<ins> // Regression test for #69307 // // Having a `async { .. foo.await .. }` block appear inside of a `+=` // expression was causing an ICE due to a failure to save/restore // state in the AST numbering pass when entering a nested body. // // check-pass // edition:2018 fn block_on<F>(_: F) -> usize { 0 } fn main() {} async fn bar() { let mut sum = 0; sum += block_on(async { baz().await; }); } async fn baz() {} </ins>

Discussion:
<!-- 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. --: Same issue still exists in : and also in : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
T-compiler triage: P-high. Leaving nomination label in place, since I don't want to disrupt WG-async-await workflow.
This does already ICE on 1.39.0
I could further simplify the code as:
However, this code does not cause ICE:
If you can reproduce this without depending on tokio that would be great.
How abot this?
Minimized:
in T-compiler meeting. Keeping as P-high but removing nomination.
OK so I've been investigating this a bit. I am not quite able to write-up mentoring instructions yet because I don't really understand what's going on, but I can leave a few notes. First off, the ICE occurs in the code that is attempting to approximate what values may be live across an . It occurs specifically when you have a structure. The nested async blocks etc are not really needed. For example, this also fails in the same way; The ICE occurs in this match arm: It appears to be related to some logic that is attempting to figure out a "worst case" execution order for instructions: I confess I don't quite follow this logic anymore, but the problem has to do with entering a distinct async block. This code for example does not trigger the failure:
Ah, I think maybe I see the problem here actually -- I suspect the problem is that we need to clear (and then restore) the flag when we recurse into a closure body.
Change:
} }) <ins> autoCollapseAllImpls(); </ins> function createToggleWrapper() { var span = document.createElement('span'); span.className = 'toggle-label';

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
self.log_capture_analysis_first_pass(closure_def_id, &delegate.capture_information, span); let (capture_information, closure_kind, origin) = self <del> .process_collected_capture_information(capture_clause, delegate.capture_information); </del> <ins> .process_collected_capture_information(capture_clause, &delegate.capture_information); </ins> self.compute_min_captures(closure_def_id, capture_information, span);

Discussion:
Rustc panicked when I attempted to use async in poll. I wanted to compose an async task inside my custom future :
I believe this is a duplicate of , which I have a local branch to fix but which needs a bit of cleanup first.

<!-- 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. --I tried this code (minimized): I expected to see this happen: Compiles Instead, this happened (): Instead, this happened (latest nightly): ICE Related: Mentioning :wink: Best guess: <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-nightly-to-nightly -regression-untriaged Thanks for investigating! -
Nightly-only features aren't typically regression triaged. I'll look into it soon.
Change:
pub tv_usec: c_long, } <ins> #[repr(C)] #[derive(Copy, Clone)] pub struct CONSOLE_READCONSOLE_CONTROL { pub nLength: ULONG, pub nInitialChars: ULONG, pub dwCtrlWakeupMask: ULONG, pub dwControlKeyState: ULONG, } pub type PCONSOLE_READCONSOLE_CONTROL = *mut CONSOLE_READCONSOLE_CONTROL; </ins> // Desktop specific functions & types cfg_if::cfg_if! { if #[cfg(not(target_vendor = "uwp"))] {

Discussion:
<!-- 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. --Building std library (-Zbuild-std) with nightly for uwp-windows-msvc targets has been failing with compile errors since around after 17/10/22 I expected to see this happen: Last successeful build on 16/10: Instead, this happened: Lastest failed build: It most recently worked on: rustc 1.66.0-nightly ( 2022-10-14) : <!-- 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 --
Hey, is anyone looking into this because ALXR ci (uwp) builds are failing for over a week. Should this issue be posted in another repo?
This is the right repo, but it fell through the cracks for whatever reason. I can get to it this weekend.
Thank you :)
Oh, sorry I missed this! Since 10.0. console functions are available on UWP (see ). So I think the thing to do here is to simply stop making the function conditionally imported.
Change:
use rustc_middle::mir::visit::{MutatingUseContext, NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::*; use rustc_middle::traits::BuiltinImplSource; <ins> use rustc_middle::ty::GenericArgs; </ins> use rustc_middle::ty::{self, adjustment::PointerCoercion, Instance, InstanceDef, Ty, TyCtxt}; <del> use rustc_middle::ty::{GenericArgKind, GenericArgs}; </del> use rustc_middle::ty::{TraitRef, TypeVisitableExt}; use rustc_mir_dataflow::{self, Analysis}; use rustc_span::{sym, Span, Symbol}; use rustc_trait_selection::traits::error_reporting::TypeErrCtxtExt as _; use rustc_trait_selection::traits::{self, ObligationCauseCode, ObligationCtxt, SelectionContext}; <ins> use rustc_type_ir::visit::{TypeSuperVisitable, TypeVisitor}; </ins> use std::mem; <del> use std::ops::Deref; </del> <ins> use std::ops::{ControlFlow, Deref}; </ins> use super::ops::{self, NonConstOp, Status}; use super::qualifs::{self, CustomEq, HasMutInterior, NeedsDrop};

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
<ins> error[E0435]: attempt to use a non-constant value in a constant --> $DIR/referencing_local_variables.rs:2:13 | LL | const fn test_me<T>(a: usize) -> usize { |                     - this would need to be a `const` LL |     const { a } |             ^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0435`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-genericconstexprs
Huhu, the master artifacts -v is super confusing since the nightly date is incorrect I don't think cargo-bisect-rustc would work on that. Anyway it's ofc, nothing much else has landed since the nightly was cut. label -F-genericconstexprs +F-inline_const
ah, I would just look at the commit hash given by rustc :sweat_smile:
Change:
use rustc_hir as hir; use rustc_hir::def::Res; use rustc_hir::def_id::DefId; <del> use rustc_infer::traits::ObligationCauseCode; </del> <ins> use rustc_infer::{infer::type_variable::TypeVariableOriginKind, traits::ObligationCauseCode}; </ins> use rustc_middle::ty::{self, Ty, TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitor}; use rustc_span::{self, symbol::kw, Span}; use rustc_trait_selection::traits;

Discussion:
<!-- 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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
self.report_similar_impl_candidates( impl_candidates, trait_ref, <ins> obligation.cause.body_id, </ins> &mut err, ); }

Discussion:
<!-- 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. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
[`String::retain`]: https://doc.rust-lang.org/std/string/struct.String.html#method.retain [cargo/5041]: https://github.com/rust-lang/cargo/pull/5041 [cargo/5083]: https://github.com/rust-lang/cargo/pull/5083 <del> [cargo/5093]: https://github.com/rust-lang/cargo/pull/5093 </del> Version 1.25.0 (2018-03-29)

Discussion:
The release notes for 1.26 mention but that is a nightly-only unstable feature. Was that intentional?
cc
Yes this seems unintentional, which is odd since it was marked relnotes and unstable features tend not to get that tag. cc would anyone be able to clarify ?
was initially intended for stable but through testing we ended up realizing it would be a breaking change and is not always desirable. Instead of stabilizing it was landed as a nightly feature, guarded by in the manifest
Change:
match self.kind(id) { EntryKind::Const(qualif, _) | EntryKind::AssocConst( <del> AssocContainer::ImplDefault | AssocContainer::ImplFinal, </del> <ins> AssocContainer::ImplDefault | AssocContainer::ImplFinal | AssocContainer::TraitWithDefault, </ins> qualif, _, ) => qualif, <del> _ => bug!(), </del> <ins> _ => bug!("mir_const_qualif: unexpected kind"), </ins> } }

Discussion:
<!-- 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 don't have a reasonable sized reproducer yet. <!-- 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. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
} macro_rules! tool_doc { <del> ($tool: ident, $should_run: literal, $path: literal, [$($krate: literal),+ $(,)?] $(, binary=$bin:expr)?) => { </del> <ins> ($tool: ident, $should_run: literal, $path: literal, [$($krate: literal),+ $(,)?], binary=$bin:expr) => { </ins> #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] pub struct $tool { stage: u32,

Discussion:
Compare to This is almost certainly caused by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> #![feature(rustc_private)] extern crate issue_76736_1; pub struct Bar; </ins>

Discussion:
This is a regression from stable to beta, although this issue will be P-low. The problem is ignored documenting unstable traits for non-local types, fixes some regressions caused by it but the regression in nightly-rustc / compiler docs still opens. For example: Compare and . The doc in 1.46.0 has impl, while on nightly it doesn't have. A way to fix this issue is ignoring this check when the compiling-crates are being passed flag or the crate/module has feature: : Version 1.48.0-nightly ( 2020-09-14)
Hey! I would like to check this out if that is okay
Is this actually a regression?
Dropping regression label. nightly-rustc docs are, well, not really important on non-nightly channels, as they cannot be used by normal consumers.
if you're still interested in working on this we'd love to have the help! If you have trouble, feel free to ask for help in or :)
Thanks! Yes, I am still interested, I have been busy that past few weeks. I will give it a shot this weekend and will reach out if I can't figure it out!
Since zulip is lag in my region at night, I post a respond here. You could use to check for flag passed during compilation.
I think I'll hop onto this if that's OK. I've always wanted to contribute :)
Go for it!
It doesn't seem to be fixed by I'll check the cause
Change:
name = "rustc-workspace-hack" version = "1.0.0" dependencies = [ <del> "byteorder", </del> "crossbeam-utils 0.6.5", "serde", "serde_json",

Discussion:
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! cc the PR reviewer, and -- nominating for prioritization.
triage: P-medium. Unnominating.