jiebi/CodeConvo huggingface dataset:
Code change:
.chain(indeterminate_imports.iter().map(|i| (true, i))) { let unresolved_import_error = self.finalize_import(*import); // If this import is unresolved then create a dummy import // resolution for it so that later resolve stages won't complain. self.import_dummy_binding(*import, is_indeterminate);

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no resolution for an import', 'error: internal compiler error: no resolution for an import' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
regression in cc
I believe the root cause of this issue stems from the changes I made, so claim
Code change:
<ins> // Documents that Rust currently does not permit the coercion &mut &mut T -> *mut *mut T // Making this compile was a feature request in rust-lang/rust#34117 but this is currently // "working as intended". Allowing "deep pointer coercion" seems footgun-prone, and would // require proceeding carefully. use std::ops::{Deref, DerefMut}; struct Foo(i32); struct SmartPtr<T>(*mut T); impl<T> SmartPtr<T> { fn get_addr(&mut self) -> &mut *mut T { &mut self.0 } } impl<T> Deref for SmartPtr<T> { type Target = T; fn deref(&self) -> &T { unsafe { &*self.0 } } } impl<T> DerefMut for SmartPtr<T> { fn deref_mut(&mut self) -> &mut T { unsafe { &mut *self.0 } } } /// Puts a Foo into the pointer provided by the caller fn make_foo(_: *mut *mut Foo) { unimplemented!() } fn main() { let mut result: SmartPtr<Foo> = SmartPtr(std::ptr::null_mut()); make_foo(&mut &mut *result); //~ mismatched types //~^ expected `*mut *mut Foo`, found `&mut &mut Foo` make_foo(out(&mut result)); // works, but makes one wonder why above coercion cannot happen } fn out<T>(ptr: &mut SmartPtr<T>) -> &mut *mut T { ptr.get_addr() } </ins>

Related discussion:
text: Legalizing this behavior with narrow cases seems permissible, but amounts to a new language feature design request. Transitive coercions, as part of the revised coercion rules, are . Accordingly, I think this should also be closed... but not before documenting the current behavior in the form of a regression test.
Code change:
// handled by the lint emitting logic above. } None => { <del> // This is an 'unmarked' API, which should not exist // in the standard library. if self.sess.features.borrow().unmarked_api { self.sess.struct_span_warn(span, "use of unmarked library feature") .span_note(span, "this is either a bug in the library you are  using or a bug in the compiler - please  report it in both places") .emit() } else { self.sess.struct_span_err(span, "use of unmarked library feature") .span_note(span, "this is either a bug in the library you are  using or a bug in the compiler - please  report it in both places") .span_note(span, "use #![feature(unmarked_api)] in the  crate attributes to override this") .emit() } </del> <ins> span_bug!(span, "encountered unmarked API"); </ins> } } }

Related discussion:
text: According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.
Code change:
<ins> error: unexpected `...` --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:4:13 | LL |     let Foo(...) = Foo(0); |             ^^^ |             | |             not a valid pattern |             help: for a rest pattern, use `..` instead of `...` error: unexpected `...` --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:5:13 | LL |     let [_, ..., _] = [0, 1]; |             ^^^ |             | |             not a valid pattern |             help: for a rest pattern, use `..` instead of `...` error[E0308]: mismatched types --> $DIR/issue-70388-recover-dotdotdot-rest-pat.rs:6:33 | LL |     let _recovery_witness: () = 0; |                            --   ^ expected `()`, found integer |                            | |                            expected due to this error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: ` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign
Code change:
#![feature(core_private_bignum)] #![feature(core_private_diy_float)] #![feature(dec2flt)] <del> #![feature(div_duration)] </del> #![feature(duration_abs_diff)] #![feature(duration_consts_float)] #![feature(duration_constants)]

Related discussion:
text: Rust PR: This feature adds the following methods to : -
Anything in particular holding up the stabilization here? The implementation is trivial and docs lgtm.
I would like to add methods that return an exact , but that can wait.
These methods are a little odd, but seem reasonable to me following the example given:
Given how straightforward these methods are, I don't think there's any problem stabilising them?
They're straightforward in implementation, but conceptually tricky at a glance. I think the docs will need some fleshing out before stabilizing but I don't have any other concerns if somebody wants to write a PR!
This needs more testing with various interesting values that could produce interesting floating point numbers, and should not be stabilized without such.
tests were in this PR
Code change:
let mut colon_span = None; let bounds = if self.eat(&token::Colon) { colon_span = Some(self.prev_token.span); <ins> // recover from `impl Trait` in type param bound if self.token.is_keyword(kw::Impl) { let impl_span = self.token.span; let snapshot = self.create_snapshot_for_diagnostic(); match self.parse_ty() { Ok(p) => { if let TyKind::ImplTrait(_, bounds) = &(*p).kind { let span = impl_span.to(self.token.span.shrink_to_lo()); let mut err = self.struct_span_err( span, "expected trait bound, found `impl Trait` type", ); err.span_label(span, "not a trait"); if let [bound, ..] = &bounds[..] { err.span_suggestion_verbose( impl_span.until(bound.span()), "use the trait bounds directly", String::new(), Applicability::MachineApplicable, ); } err.emit(); return Err(err); } } Err(err) => { err.cancel(); } } self.restore_snapshot(snapshot); } </ins> self.parse_generic_bounds(colon_span)? } else { Vec::new() }; let default = if self.eat(&token::Eq) { Some(self.parse_ty()?) } else { None }; Ok(GenericParam { ident, id: ast::DUMMY_NODE_ID,

Related discussion:
text: When writing the current error is "expected one of these tokens", without any attempt to recover the parse. It should instead be closer to: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
What do you expect the suggestion from this code? here is a valid identifier, "expected one of these tokens" comes when the second identifier comes.
I think this case should remain as is. in particular is a shame because it is a valid type for the parser, but not a valid trait, and newcomers might not yet have a mental model for the distinction. I would say, when parsing a trait, if it can't be parsed, then try to parse a type in a snapshot (like we do in other parts of the parser), and if successful, emit a targeted error (trait expected but found type).
claim
Code change:
<ins> error[E0433]: failed to resolve: use of undeclared crate or module `n` --> $DIR/issue-120856.rs:1:37 | LL | pub type Archived<T> = <m::Alias as n::Trait>::Archived; |                                     ^ |                                     | |                                     use of undeclared crate or module `n` |                                     help: a trait with a similar name exists: `Fn` error[E0433]: failed to resolve: use of undeclared crate or module `m` --> $DIR/issue-120856.rs:1:25 | LL | pub type Archived<T> = <m::Alias as n::Trait>::Archived; |                         ^ |                         | |                         use of undeclared crate or module `m` |                         help: a type parameter with a similar name exists: `T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'', 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'' 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: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
in 'ish ICEs, I am seeing ice now, im wondering if that also relates to somehow :thinking:
Quite likely, I'll take a look.
I can reproduce this. It's Saturday morning here, I might get to it today, if not I'll look on Monday morning.
Fixing this is really easy, I just need to adjust the assertion a tiny bit. The hard part is deciding where to put the test. is the obvious place, but then I get complaining that there are too many files in that directory. Suggestions?
just bump the limit by one like everybody else? :upsidedownface: :seenoevil:
I ended up putting the test in , because it happens during type checking.
Code change:
<ins> fn main() { let a_longer_variable_name = 1; println!("{}", a_variable_longer_name); //~ ERROR E0425 } </ins>

Related discussion:
text: On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim
Code change:
<ins> const CONST_STRING: String = String::new(); fn main() { let empty_str = String::from(""); if let CONST_STRING = empty_str {} //~^ ERROR to use a constant of type `Vec<u8>` in a pattern, `Vec<u8>` must be annotated with `#[derive(PartialEq, Eq)]` } </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. --: This bug was also reproduced in the stable version(1.72) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Hmm this was caused by cc
claim
Code change:
<ins> // Regression test of #86483. #![feature(generic_associated_types)] #![allow(incomplete_features)] pub trait IceIce<T> //~ ERROR: the parameter type `T` may not live long enough where for<'a> T: 'a, { type Ice<'v>: IntoIterator<Item = &'v T>; //~^ ERROR: the parameter type `T` may not live long enough //~| ERROR: the parameter type `T` may not live long enough } fn main() {} </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. --%5D%0D%0Apub%20trait%20IceIce%3CT%3E%0D%0Awhere%0D%0A%20%20%20%20for%3C'a%3E%20T%3A%20'a%2C%0D%0A%7B%0D%0A%20%20%20%20type%20Ice%3C'v%3E%3A%20IntoIterator%3CItem%20%3D%20%26'v%20T%3E%3B%0D%0A%7D%0D%0A%0D%0Afn%20main()%20%7B%7D%0D%0A) <!-- 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 ICE happens on , and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Maybe related to
Bisection: bash cargo bisect-rustc --regress ice --test-dir=foo `
Looks like
ICE happens on stable and also even without the line so no requires-nightly. label regression-from-stable-to-stable, A-traits
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Code change:
<ins> // compile-flags: -O // run-pass // Regression test for https://github.com/rust-lang/rust/issues/118328 #![allow(unused_assignments)] struct SizeOfConst<T>(std::marker::PhantomData<T>); impl<T> SizeOfConst<T> { const SIZE: usize = std::mem::size_of::<T>(); } fn size_of<T>() -> usize { let mut a = 0; a = SizeOfConst::<T>::SIZE; a } fn main() { assert_eq!(size_of::<u32>(), std::mem::size_of::<u32>()); } </ins>

Related discussion:
text: Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc
Code change:
// to accidentally sneak into our dependency graph, in order to ensure we keep our CI times // under control. "cargo", <del> "rustc-ap-rustc_ast", </del> ]; /// Dependency checks.

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.
Code change:
// to accidentally sneak into our dependency graph, in order to ensure we keep our CI times // under control. "cargo", <del> "rustc-ap-rustc_ast", </del> ]; /// Dependency checks.

Related discussion:
text: One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on
Code change:
F: FnOnce(Block<'blk, 'tcx>, ValueRef, Ty<'tcx>) -> Block<'blk, 'tcx>, { let _icx = push_ctxt("tvec::iter_vec_loop"); <del> let fcx = bcx.fcx; </del> <ins> if bcx.unreachable.get() { return bcx; } let fcx = bcx.fcx; </ins> let loop_bcx = fcx.new_temp_block("expr_repeat"); let next_bcx = fcx.new_temp_block("expr_repeat: next");

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:
<ins> error: struct `T9` is never constructed --> $DIR/unconstructible-pub-struct.rs:30:12 | LL | pub struct T9<X> { |            ^^ | note: the lint level is defined here --> $DIR/unconstructible-pub-struct.rs:2:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: aborting due to 1 previous error </ins>

Related discussion:
text: The struct is meant to not be constructible. Also the behavior is incoherent between tuple structs (correct behavior) and named structs (incorrect behavior). Also, this is a regression, this didn't use to be the case. No response No response
label +F-never_Type +D-inconsistent
We will also get such warnings for private structs with fields of never type (): The struct is never constructed although it is not constructible. This behavior is expected and is not a regression. Did you meet any cases using this way in real world? For the incoherent behavior, we also have: This because we only skip positional ZST (PhantomData and generics), this policy is also applied for never read fields:
Can you elaborate in which sense it is expected? I can understand that it is expected given the current implementation of Rust. It seems between stable and nightly a new lint was implemented. This lint is expected for inhabited types. However it has false positives on inhabited types, i.e. types that are only meant for type-level usage (for example to implement a trait). I agree we should probably categorize this issue as a false positive of a new lint rather than a regression (technically). Thanks, I can see the idea behind it. I'm not convinced about it though, but it doesn't bother me either. So let's just keep this issue focused on the false positive rather than the inconsistent behavior.
How do you think about private structs with fields of never type?
I would consider it the same as public structs, because they can still be "constructed" at the type-level. So they are dynamic dead--code but not dead-code since they are used statically. It would be dead-code though if the type is never used (both in dynamic code and static code, i.e. types).
Actually, thinking about this issue, I don't think this is a false positive only for the never type. I think the whole lint is wrong. The fact that the type is empty is just a proof that constructing it at term-level is not necessary for the type to be "alive" (aka usable). This could also be the case with non-empty types. A lot of people just use unit types for type-level usage only (instead of empty types).
Code change:
<ins> error: struct `T9` is never constructed --> $DIR/unconstructible-pub-struct.rs:30:12 | LL | pub struct T9<X> { |            ^^ | note: the lint level is defined here --> $DIR/unconstructible-pub-struct.rs:2:9 | LL | #![deny(dead_code)] |         ^^^^^^^^^ error: aborting due to 1 previous error </ins>

Related discussion:
text: So my conclusion would be that linting a type to be dead-code because it is never constructed is brittle as it can't be sure that the type is not meant to be constructed at term-level (and thus only used at type-level). Adding is not a solution because if the type is actually not used at all (including in types) then we actually want the warning. Here is an example: The same thing with a private struct: And now actual dead code:
I think a better way is: is usually used to do such things like just a proof. Maybe we can add a help for this case.
But I agree that we shouldn't emit warnings for pub structs with any fields of never type (and also unit type), this is an intentional behavior.
Oh yes good point. So all good to proceed with adding never type to the list of special types.
Thanks a lot for the quick fix! Once it hits nightly, I'll give it a try. I'm a bit afraid though that this won't fix the underlying problem of understanding which types are not meant to exist at runtime. For example, sometimes instead of using the never type, I also use empty enums such that I can give a name and separate identity to that type. Let's see if it's an issue. If yes, I guess ultimately there would be 2 options: Just use in those cases. Introduce a trait (or better name) for types that are not meant to exist at runtime like unit, never, and phantom types, but could be extended with user types like empty enums. I'll ping this thread again if I actually hit this issue.
I could test it (using nightly-2024-08-01) and . I just had to change a to in a crate where I didn't have already. Ultimately, is going to be a type alias for so maybe it's not worth supporting it. And thinking about empty enums, this should never be an issue for my particular usage, which is to build empty types. Because either the type takes no parameters in which case I use an empty enum directly. Or it takes parameters and I have to use a struct with fields, and to make the struct empty I also have to add a never field. So my concern in the previous message is not an issue for me.