jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-coercion-from-never.rs:14:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
/// Parses an `else { ... }` expression (`else` token already eaten). fn parse_else_expr(&mut self) -> PResult<'a, P<Expr>> { <del> let ctx_span = self.prev_token.span; // `else` </del> <ins> let else_span = self.prev_token.span; // `else` </ins> let attrs = self.parse_outer_attributes()?.take_for_recovery(); // For recovery. let expr = if self.eat_keyword(kw::If) { self.parse_if_expr(AttrVec::new())? <ins> } else if self.check(&TokenKind::OpenDelim(Delimiter::Brace)) { self.parse_simple_block()? </ins> } else { <del> let blk = self.parse_block()?; self.mk_expr(blk.span, ExprKind::Block(blk, None), AttrVec::new()) </del> <ins> let snapshot = self.create_snapshot_for_diagnostic(); let first_tok = super::token_descr(&self.token); let first_tok_span = self.token.span; match self.parse_expr() { Ok(cond) // If it's not a free-standing expression, and is followed by a block, // then it's very likely the condition to an `else if`. if self.check(&TokenKind::OpenDelim(Delimiter::Brace)) && classify::expr_requires_semi_to_be_stmt(&cond) => { self.struct_span_err(first_tok_span, format!("expected `{{`, found {first_tok}")) .span_label(else_span, "expected an `if` or a block after this `else`") .span_suggestion( cond.span.shrink_to_lo(), "add an `if` if this is the condition to an chained `if` statement after the `else`", "if ".to_string(), Applicability::MaybeIncorrect, ).multipart_suggestion( "... otherwise, place this expression inside of a block if it is not an `if` condition", vec![ (cond.span.shrink_to_lo(), "{ ".to_string()), (cond.span.shrink_to_hi(), " }".to_string()), ], Applicability::MaybeIncorrect, ) .emit(); self.parse_if_after_cond(AttrVec::new(), cond.span.shrink_to_lo(), cond)? } Err(e) => { e.cancel(); self.restore_snapshot(snapshot); self.parse_simple_block()? }, Ok(_) => { self.restore_snapshot(snapshot); self.parse_simple_block()? }, } </ins> }; <del> self.error_on_if_block_attrs(ctx_span, true, expr.span, &attrs); </del> <ins> self.error_on_if_block_attrs(else_span, true, expr.span, &attrs); </ins> Ok(expr) }

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
.map(|infer_ok| self.register_infer_ok_obligations(infer_ok)) } <ins> pub fn eq_trace<T: Relate<TyCtxt<'tcx>>>( &self, cause: &ObligationCause<'tcx>, param_env: ty::ParamEnv<'tcx>, trace: TypeTrace<'tcx>, expected: T, actual: T, ) -> Result<(), TypeError<'tcx>> { self.infcx .at(cause, param_env) .eq_trace(DefineOpaqueTypes::Yes, trace, expected, actual) .map(|infer_ok| self.register_infer_ok_obligations(infer_ok)) } </ins> /// Checks whether `expected` is a subtype of `actual`: `expected <: actual`. pub fn sub<T: ToTrace<'tcx>>( &self,

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
use rustc_middle::mir::FakeReadCause; use rustc_middle::traits::ObligationCauseCode; use rustc_middle::ty::{ <del> self, ClosureSizeProfileData, Ty, TyCtxt, TypeckResults, UpvarArgs, UpvarCapture, </del> <ins> self, ClosureSizeProfileData, Ty, TyCtxt, TypeVisitableExt as _, TypeckResults, UpvarArgs, UpvarCapture, </ins> }; use rustc_session::lint; use rustc_span::sym;

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:
}) } <ins> fn lower_exprs(&mut self, exprs: &[AstP<Expr>]) -> HirVec<hir::Expr> { exprs.iter().map(|x| self.lower_expr(x)).collect() } </ins> fn lower_expr(&mut self, e: &Expr) -> hir::Expr { let kind = match e.node { ExprKind::Box(ref inner) => hir::ExprKind::Box(P(self.lower_expr(inner))), <del> ExprKind::Array(ref exprs) => { hir::ExprKind::Array(exprs.iter().map(|x| self.lower_expr(x)).collect()) } </del> <ins> ExprKind::Array(ref exprs) => hir::ExprKind::Array(self.lower_exprs(exprs)), </ins> ExprKind::Repeat(ref expr, ref count) => { let expr = P(self.lower_expr(expr)); let count = self.lower_anon_const(count); hir::ExprKind::Repeat(expr, count) } <del> ExprKind::Tup(ref elts) => { hir::ExprKind::Tup(elts.iter().map(|x| self.lower_expr(x)).collect()) } </del> <ins> ExprKind::Tup(ref elts) => hir::ExprKind::Tup(self.lower_exprs(elts)), </ins> ExprKind::Call(ref f, ref args) => { let f = P(self.lower_expr(f)); <del> hir::ExprKind::Call(f, args.iter().map(|x| self.lower_expr(x)).collect()) </del> <ins> hir::ExprKind::Call(f, self.lower_exprs(args)) </ins> } ExprKind::MethodCall(ref seg, ref args) => { let hir_seg = P(self.lower_path_segment(

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
pub rust_profile_use: Option<String>, pub rust_profile_generate: Option<String>, pub rust_lto: RustcLto, <ins> pub rust_validate_mir_opts: Option<u32>, </ins> pub llvm_profile_use: Option<String>, pub llvm_profile_generate: bool, pub llvm_libunwind_default: Option<LlvmLibunwind>,

Discussion:
Because currently it doesn't. has a handful of problems which are reported elsewhere, but discovering problems with MIR optimizations is often as simple as building the compiler with the optimization enabled and . So we should do that in CI. Note that all MIR opt levels are supposed to be sound, and known unsoundness is supposed to be gated behind , which I am not suggesting we test with. Currently attempting to build the standard library with these flags results in pages of this error: Which looks to me like <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
also mentioned to me that some opts are using as a minimum threshold, it may be helpful to test that as well (maybe in a separate builder). does not change the output of the compiler and should be ok to turn on unconditionally for libstd; we might want to be more selective about where we enable it for the compiler itself, though, since it's a lot slower. We should also have at least one builder where we enable for UI tests.
Mentoring instructions: new option to and This option should pass unconditionally for libstd. Test it works locally with , you should see the ICE posted above. that new option on all builders around here: You can test that works by opening a PR (please put in the description) and making sure it shows the same ICE. that works, we can figure out whether we want to enable this for rustc as well on some builders; maybe we should have separate and configs? And for turning it on in compiletest?
claim
Reproduced it on the PR.
Change:
LL |     println!("x: {}", x); |                       ^ not found in this scope <ins> error[E0425]: cannot find value `let_some_variable` in this scope --> $DIR/suggest-let-for-assignment.rs:10:5 | LL |     let_some_variable = 6; |     ^^^^^^^^^^^^^^^^^ | help: you might have meant to introduce a new binding | LL |     let some_variable = 6; |     ~~~~~~~~~~~~~~~~~ error[E0425]: cannot find value `some_variable` in this scope --> $DIR/suggest-let-for-assignment.rs:11:35 | LL |     println!("some_variable: {}", some_variable); |                                   ^^^^^^^^^^^^^ not found in this scope error[E0425]: cannot find value `letother_variable` in this scope --> $DIR/suggest-let-for-assignment.rs:13:5 | LL |     letother_variable = 6; |     ^^^^^^^^^^^^^^^^^ | help: you might have meant to introduce a new binding | LL |     let other_variable = 6; |     ~~~~~~~~~~~~~~~~~~ error[E0425]: cannot find value `other_variable` in this scope --> $DIR/suggest-let-for-assignment.rs:14:36 | LL |     println!("other_variable: {}", other_variable); |                                    ^^^^^^^^^^^^^^ not found in this scope </ins> error[E0425]: cannot find value `x` in this scope <del> --> $DIR/suggest-let-for-assignment.rs:10:8 </del> <ins> --> $DIR/suggest-let-for-assignment.rs:16:8 </ins> | LL |     if x == "x" { |        ^ not found in this scope error[E0425]: cannot find value `y` in this scope <del> --> $DIR/suggest-let-for-assignment.rs:15:5 </del> <ins> --> $DIR/suggest-let-for-assignment.rs:21:5 </ins> | LL |     y = 1 + 2; |     ^

Discussion:
I accidentally typoed an underscore instead of a space between and the name of the new variable I was trying to declare. If a binding isn't found, and it starts with (or frankly , if you forget/miss the space completely), it seems like it would be more likely to suggest ( plus a space) rather than the current suggestion of an additional . No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
interesting, I'd like to have a try. but might not solve it quicklly casuze I am new to rustc
sounds good! feel free to ask for help if you need it, but the implementation should be fairly simple. assign
Change:
<ins> // build-pass #![feature(adt_const_params)] #![allow(incomplete_features)] pub fn function_with_bytes<const BYTES: &'static [u8; 4]>() -> &'static [u8] { BYTES } pub fn main() { assert_eq!(function_with_bytes::<b"AAAA">(), &[0x41, 0x41, 0x41, 0x41]); assert_eq!(function_with_bytes::<{ &[0x41, 0x41, 0x41, 0x41] }>(), b"AAAA"); } </ins>

Discussion:
Const generics causes monomorphization to compare constants by identity instead of structurally. This means that two different references to equal data will compare as unequal. The root problem is in which puts the of a function into a . Since the 's s contain constants, hashing these constants will cause structurally equal constants to have different hashes. For this has been solved by hashing the actual data and not things like pointers. For comparison we have which does a more appropriate version of comparison. I tried this code: I expected to see this happen: successful compilation just as if the type were Instead, this happened: cc cc It's a footgun that and especially can be compared for equality. Technically a is value/structurally equal to any other . We may need that impl for query return value hashing though, not sure.
There's two ways that I see that we can use to go forward: from and everything that depends on it. This requires some wrapper helpers (forwarding to ) around the return values of queries as query return types need impls I think. implement to use and . This may cause some things to become slow, as more work is done. We could benchmark this as a first try.
isn't relevant here, you should have fully normalized constants by the time of the monomorphization collector (i.e. no ), anything else is a bug. Keep in mind types have the same problem with and .
Ok, but even ignoring any other than , the only place that correctly compares is , so we can pull that out as a common function for comparing . That'll still have to have access to a in order to be able to fetch the that a const pointer points to.
You shouldn't need to compare fully normalized monomorphic things, interning should deduplicate everything by-typesystem-semantic-value.
Oh, as a side mention, if you need to validate that the typesystem doesn't contain any non-deduplicatable constants (e.g. references), we can do it in WF checking, post-.
I don't think we can run into issues with here, so not marking it as blocking.
this is now fixed by valtrees: needs test though:
Change:
# except according to those terms. import os <ins> import subprocess </ins> import sys import functools STATUS = 0 def error_unless_permitted(env_var, message): global STATUS if not os.getenv(env_var): sys.stderr.write(message) STATUS = 1 def only_on(platforms): def decorator(func): @functools.wraps(func)

Discussion:
The failure happens in when the output of the command used in the test contains cyrillic letters. Changing the system locale to English (USA) or replacing with something like makes this error go away. cc
Hm interesting! This probably isn't so much connected to locales so much that something in the environment/output isn't valid UTF-8. Could you get a backtrace of this failure? I would be surprised if this was coming from , but the test looks pretty innocuous, so it may very well be coming from std!
The problem may actually reside in compiletest, it captures the output of the test and then can interpret it incorrectly. If the test is run as a standalone program outside of the test suite then no panic happens and the test works as expected. I'm still investigating. Here's the backtrace, but it's not very helpful:
Aha! It looks like . I suspect it would be fine for to just use
Change:
There are a number of other ways to contribute to Rust that don't deal with this repository. <del> Answer questions in [#rust][pound-rust], or on [users.rust-lang.org][users], </del> <ins> Answer questions in the _Get Help!_ channels from the [Rust Discord server][rust-discord], on [users.rust-lang.org][users], </ins> or on [StackOverflow][so]. Participate in the [RFC process](https://github.com/rust-lang/rfcs).

Discussion:
There are still of IRC in the repo. Removing them is not a priority but it will avoid confusion for newcomers.
Should these places be replaced with references to the rust discord server, or just be removed outright?
Probably replaced. Gonna update title.
Opened to address this.
This is horrible. Replacing IRC with Discord.. :/
If you haven't read about it yet, is the post from April.
Yeah I read already. I'd remove the mention of any particular discussion channel, instead of putting Discord in. I can't wait for Matrix to become more mature so the Rust project can use it. Falling back to Discord is quite bad for a FOSS project.
IMO we should just mirror subreddit solution and point to Discord.
Change:
/// /// [`clear`]: ../ffi/struct.OsString.html#method.clear /// [`OsString`]: ../ffi/struct.OsString.html <del> #[unstable(feature = "path_buf_capacity", issue = "58234")] </del> <ins> #[stable(feature = "path_buf_capacity", since = "1.44.0")] </ins> pub fn clear(&mut self) { self.inner.clear() }

Discussion:
, should probably not be stabilized before , see
Happy to take this on as a first contribution to rust.
Great! I'd be happy to help you get started, just let me know if you want mentoring/instructions at any level!
are you able to define a list of the methods that need to be implemented as part of this PR?
I think all of these will essentially call the underlying functions on . [ ] [ ] [ ] [ ] [ ] [ ] [ ] -- this one is more of a maybe, since it's unstable on OsString. We can reuse the same tracking issue for this. We'll probably want to add all of these under the same feature gate.
thanks for that. I have the implementation drafted locally. I'm having some difficulty however in running the tests for stdlib - even a is producing errors not related to my changes. Is there any documentation I've missed for best practices on compiling / working on stdlib?
You'll want to use x.py; for your scenario I believe and/or are the commands you want. I'm not sure where the most current documentation is.
describes how to use .
Triage: since has been merged, can this be closed?
No, this is now the tracking issue for the stabilization of those APIs.
Reviewing this since then, I think it may be worth removing these APIs and replacing them with something like and . These aren't really commonly used so hiding them as such seems reasonable and is less heavy.
I'd love to see these stabilized. I have a tool that manipulates lots of paths, so I'd like to avoid needless reallocations. I generate lots of temporary paths in a loop. would work nicely to reuse the buffer. I need to concatenate several components. I know their length, so I could use I want to store lots of paths for later. is a bit smaller than , but if I can't reserve exact capacity, will reallocate.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See for info about what commands tagged team members can give me.
reviewed assuming we're only stabilizing capacity + withcapacity + clear + reserve + reserveexact + shrinktofit;&ensp;and shrink_to is being moved to instead.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I've posted a stabilization PR in .
Change:
<ins> pub fn bar() { println!("bar {}", foo::FOO); foo::foo(); } </ins>

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. --I tried this code: I expected to see this happen: generate Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</details
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .
Change:
<ins> error[E0596]: cannot borrow `c` as mutable, as it is not declared as mutable --> $DIR/issue-82438-mut-without-upvar.rs:27:27 | LL |     let c = |a, b, c, d| {}; |         - help: consider changing this to be mutable: `mut c` LL | LL |     A.f(participant_name, &mut c); |                           ^^^^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This regressed in 1.51 according to the playground
searched nightlies: from nightly-2020-12-15 to nightly-2021-02-01 regressed nightly: nightly-2021-01-30 searched commits: from to regressed commit: Regressed in
Most likely due to , cc
Assigning and removing as in the prioritization working group.