jiebi/CodeConvo huggingface dataset:
Code change:
// see the extensive comment in projection_must_outlive let recursive_bound = { let mut components = smallvec![]; <del> compute_components_recursive(self.tcx, alias_ty_as_ty.into(), &mut components, visited); </del> <ins> compute_alias_components_recursive( self.tcx, alias_ty_as_ty.into(), &mut components, visited, ); </ins> self.bound_from_components(&components, visited) };

Related discussion:
text: Another regresssion of with a different failure path: It should be fixed by ignoring non-captured lifetimes in: cc label regression-from-stable-to-stable C-bug T-compiler T-types A-impl-trait
Note that fixing this issue is necessary for , but might not be sufficient. I'll investigate more...
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
// see the extensive comment in projection_must_outlive let recursive_bound = { let mut components = smallvec![]; <del> compute_components_recursive(self.tcx, alias_ty_as_ty.into(), &mut components, visited); </del> <ins> compute_alias_components_recursive( self.tcx, alias_ty_as_ty.into(), &mut components, visited, ); </ins> self.bound_from_components(&components, visited) };

Related discussion:
text: Some regressions of that I previously reported in , but they were missed: I guess the way to fix this is to ignore non-captured lifetimes of opaque types here cc label C-bug regression-from-stable-to-stable T-types T-compiler A-impl-trait
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
if let Some(old_binding) = resolution.shadowed_glob { assert!(old_binding.is_glob_import()); if glob_binding.res() != old_binding.res() { <del> resolution.shadowed_glob = Some(self.ambiguity( </del> <ins> resolution.shadowed_glob = Some(this.ambiguity( </ins> AmbiguityKind::GlobVsGlob, old_binding, glob_binding, )); <del> } else if !old_binding.vis.is_at_least(binding.vis, self.tcx) { </del> <ins> } else if !old_binding.vis.is_at_least(binding.vis, this.tcx) { </ins> resolution.shadowed_glob = Some(glob_binding); } } else {

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. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.
Code change:
<ins> // Checks that there is a suggestion for simple tuple index access expression (used where an // identifier is expected in a format arg) to use positional arg instead. // Issue: <https://github.com/rust-lang/rust/issues/122535>. //@ run-rustfix fn main() { let x = (1,); println!("{x.0}"); //~^ ERROR invalid format string } </ins>

Related discussion:
text: <!-- While learning rust from the book i tried printing the second(.1) value in a tuple, and it broke the format string and wouldn't compile --I tried this code: I expected to see this happen: printing of the value 1. Instead, this happened: it gave the following error: if you intended to print , you can escape it using rustc <!-- 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. --:
Only printing an identifer is supported, arbitrary expressions are not: https://rust-
There's more discussion about this in or in many other places, it's a thing that keeps coming up.
The error message could be nicer, so I'll convert it into a diagnostics issue.
Code change:
|     ^^^^^^^^ error[E0603]: enum `Bar` is private <del> --> $DIR/struct-variant-privacy.rs:9:14 </del> <ins> --> $DIR/struct-variant-privacy.rs:10:14 </ins> | LL |         foo::Bar::Baz { a: _a } => {} |              ^^^ private enum

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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.
Code change:
<ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] struct Bug<const S: &'static str>; fn main() { let b: Bug::<{ unsafe { // FIXME(const_generics): Decide on how to deal with invalid values as const params. std::mem::transmute::<&[u8], &str>(&[0xC0, 0xC1, 0xF5]) } }>; } </ins>

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
It looks like it's correctly complied on rustc 1.48.0-nightly:
I dont think this should compile at all. After all, we cause UB, the value of the const generic does not comply with the rules of .
A str being valid utf-8 is not a language invariant, so this should not be UB to my knowledge. cc I do expect this to be the correct behavior, so marking as
We do have to compare the s to check for equality though, which might cause library ub so :shrug:
I think you are free to decide on your own invariant here -- assuming that two are equal if and only if the underlying are equal, it's your call whether you want to allow non-UTF-8 in types or not. What is the plan for other library types? Like, imagine a user defined a newtype around that must be even. The compiler cannot even know that such an invariant exists so it cannot be enforced. Equality checking anyway happens by comparing the underlying bytes. So if we follow that analogy, the non-UTF-8 should be fine, but we have to make sure that we use the right notion of equality.
:+1: yeah, see for more details here I guess One concern is that we probably want to print s in and in encodings, so we need to either deal with invalid utf there or forbid it entirely :thinking: Will have to keep that in mind before stabilizing parameters.
Yeah, you could either use (so any special treatment of is confined to the printing code) or make a very special compiler-understood type even for the type system itself (and reject non-UTF-8 strings early). The former seems more principled to me but that is just a slight preference.
Code change:
<ins> // build-pass #![allow(incomplete_features)] #![feature(const_generics)] struct Bug<const S: &'static str>; fn main() { let b: Bug::<{ unsafe { // FIXME(const_generics): Decide on how to deal with invalid values as const params. std::mem::transmute::<&[u8], &str>(&[0xC0, 0xC1, 0xF5]) } }>; } </ins>

Related discussion:
text: won't work for symbol mangling, as otherwise two distinct types can have the same symbol: (current ICE is unrelated, as const generics is not yet fully supported there) Printing invalid utf8 as bytes might be simpler there :thinking: I guess cc about that
Oh, this is not just pretty-printing but needs to be injective? Then I guess some or so (for "invalid") would work.
Code change:
<del> error[E0658]: trait upcasting coercion is experimental </del> <ins> error[E0658]: cannot cast `dyn Bar` to `dyn Foo`, trait upcasting coercion is experimental </ins> --> $DIR/feature-gate-trait_upcasting.rs:11:25 | LL |     let foo: &dyn Foo = bar;

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --It should name the traits are attempted to be coerced, maybe tell me why that's not allowed (yet), etc. Right now it just highlights the entire line. The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed". Note that I understand why it's not allowed, I was just disappointed by the error message. I already talked to about this, and they also thought this output may be problematic. Even though the feature may be unstable, it's quite easy to arrive at a situation where you may get this error. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
driver_rlink_rustc_version_mismatch = .rlink file was produced by rustc version `{$rustc_version}`, but the current version is `{$current_version}` driver_rlink_no_a_file = rlink must be a file <ins> driver_unpretty_dump_fail = pretty-print failed to write `{$path}` due to error `{$err}` </ins>

Related discussion:
text: If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim
Code change:
#![feature(const_slice_split_at_mut)] #![feature(const_str_from_utf8_unchecked_mut)] #![feature(const_swap)] <del> #![feature(const_transmute_copy)] </del> #![feature(const_try)] #![feature(const_type_id)] #![feature(const_type_name)]

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for making the function . <!-- Include a short description of the feature. --<!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [ ] Final commenting period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
This got reverted again by , but hopefully we can re-land it soon.
Sorry, I misread, this feature gate is not affected (but some others are).
Any news on this?
Code change:
#![feature(const_slice_split_at_mut)] #![feature(const_str_from_utf8_unchecked_mut)] #![feature(const_swap)] <del> #![feature(const_transmute_copy)] </del> #![feature(const_try)] #![feature(const_type_id)] #![feature(const_type_name)]

Related discussion:
text: I don't see anything holding it back; especially now that transmute itself is const. EDIT: Never mind, I just saw
Since is const-stable nowadays, I think this can be stabilized as well. Feel free to open a PR. :) Cc
I didn't do this before, I am reading the docs for how to do this, and there's an rfcbot final commenting period thing. Should this be done? If yes, how? I probably don't have the rights to do it.
You just need to prepare a PR. I can help get the FCP process started in the PR.
Code change:
false } <del> fn let_binding_suggestion(&self, err: &mut Diagnostic, ident_span: Span) -> bool { // try to give a suggestion for this pattern: `name = 1`, which is common in other languages let mut added_suggestion = false; if let Some(Expr { kind: ExprKind::Assign(lhs, _rhs, _), .. }) = self.diagnostic_metadata.in_assignment && </del> <ins> // try to give a suggestion for this pattern: `name = blah`, which is common in other languages // suggest `let name = blah` to introduce a new binding fn let_binding_suggestion(&mut self, err: &mut Diagnostic, ident_span: Span) -> bool { if let Some(Expr { kind: ExprKind::Assign(lhs, .. ), .. }) = self.diagnostic_metadata.in_assignment && </ins> let ast::ExprKind::Path(None, _) = lhs.kind { <del> let sm = self.r.session.source_map(); let line_span = sm.span_extend_to_line(ident_span); let ident_name = sm.span_to_snippet(ident_span).unwrap(); // HACK(chenyukang): make sure ident_name is at the starting of the line to protect against macros if sm .span_to_snippet(line_span) .map_or(false, |s| s.trim().starts_with(&ident_name)) { </del> <ins> if !ident_span.from_expansion() { </ins> err.span_suggestion_verbose( ident_span.shrink_to_lo(), "you might have meant to introduce a new binding", "let ".to_string(), Applicability::MaybeIncorrect, ); <del> added_suggestion = true; </del> <ins> return true; </ins> } } <del> added_suggestion </del> <ins> false </ins> } fn find_module(&mut self, def_id: DefId) -> Option<(Module<'a>, ImportSuggestion)> {

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should first check the RHS, before suggest adding . It should also avoid suggesting when code is invalid. Thanks. Something like this should also not suggest adding : cc <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the second example should be something we need to fix, but the first example should be very easy to fix.
claim
Code change:
pub fn cargo_clippy_cmd(&self, run_compiler: Compiler) -> BootstrapCommand { if run_compiler.stage == 0 { <del> // `ensure(Clippy { stage: 0 })` *builds* clippy with stage0, it doesn't use the beta clippy. let cargo_clippy = self.build.config.download_clippy(); </del> <ins> let cargo_clippy = self .config .initial_cargo_clippy .clone() .unwrap_or_else(|| self.build.config.download_clippy()); </ins> let mut cmd = command(cargo_clippy); cmd.env("CARGO", &self.initial_cargo); return cmd;

Related discussion:
text: I'm pretty sure it is possible to set custom paths for , & in but not for clippy.
label +T-bootstrap
Code change:
<ins> error: `_x @` is not allowed in a tuple struct --> $DIR/issue-72574-2.rs:6:20 | LL |         Binder(_a, _x @ ..) => {} |                    ^^^^^^^ this is only allowed in slice patterns | = help: remove this and bind each tuple field independently help: if you don't need to use the contents of _x, discard the tuple's remaining fields | LL |         Binder(_a, ..) => {} |                    ^^ error: aborting due to previous error </ins>

Related discussion:
text: and I are working on diagnostics for the rest idiom in slice patterns () and came across this issue when an attempt is made to use it in tuples and tuple structs. IIUC, this is allowed: and this is not allowed (note the addition of ): The error messages for the tuple and tuple struct cases include the following incorrect information: This should state that the id binding to rest is not allowed. patterns are allowed. is only allowed in slice patterns, not in tuple or tuple struct patterns. This should state that the idiom is only allowed in slice patterns. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
appears to be the site of the check: This method is called:
Perhaps it's worth supporting "tuple slicing" pattern too in Rust:
that would implicitly create a tuple for (or a slice?). I don't think it'd be a good addition. We already support , which is much more useful in my eyes.
That syntax is meant to produce a shorter tuple xs with the omission of the first item of the tuple. lf you think it's an useless idea then let's ignore it :)
claim
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. // error-pattern:panic evaluated #[allow(unused_variables)] fn main() { let x = [panic!("panic evaluated"); 0]; } </ins>

Related discussion:
text: Currently, will panic, but will not, because the expression is not evaluated in that case.
Also, crashes the compiler. Maybe it's the same issue?
Thanks for the reminder, fixes that as well.
Code change:
#[proc_macro_attribute] pub fn expect_print_expr(attr: TokenStream, item: TokenStream) -> TokenStream { assert!(attr.to_string().is_empty()); <del> assert_eq!(item.to_string(), "println!("{}" , string)"); </del> <ins> assert_eq!(item.to_string(), "println!("{}", string)"); </ins> item }

Related discussion:
text: proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.
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. fn identity(a: &u32) -> &u32 { a } fn print_foo(f: &fn(&u32) -> &u32, x: &u32) { print!("{}", (*f)(x)); } fn main() { let x = &4; let f: fn(&u32) -> &u32 = identity; // Didn't print 4 on optimized builds print_foo(&f, x); } </ins>

Related discussion:
text: Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.