jiebi/CodeConvo huggingface dataset:
Change:
#![feature(partition_point)] #![feature(once_cell)] #![feature(unsafe_block_in_unsafe_fn)] <del> #![feature(int_bits_const)] </del> #![feature(nonzero_leading_trailing_zeros)] #![feature(const_option)] #![feature(integer_atomics)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? 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] [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.
: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.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
self.cx.normalize_and_prove_instantiated_predicates( def_id, instantiated_predicates, <del> location.to_locations(), </del> <ins> locations, </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. 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 ( , regressed in the past week) output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --The desired result can be achieved by swapping the order of the two statements and . <!-- 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 --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-07 to nightly-2022-06-08 regressed nightly: nightly-2022-06-08 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details are you working on this? I'll probably be investigating this due to it being related to the recent removal of the borrowck migration mode.
I've been working on it a bit, but please feel free to take over this issue!
This actually looks like a particularly difficult issue. I think it's either a bug in , or something weird with the that is convincing us that the correct source for this region error is through the on line 12 of the example. It may also be notable that we end up going thru a when emitting this error. This issue seems to be out of my area of expertise, so I won't claim it. if you can't find a solution then it may be best to hand off to someone with mir-borrowck expertise.
Actually, what I said was totally wrong.

This is definitely because we're passing in the wrong when . I think I have a fix for this, though I probably want to eliminate other dummy locations we're passing around mir borrowck... cc sorry for all the pings, but don't keep wasting time on this unless you've made significant progress :stuckout_tongue: claim
Change:
impl<'tcx> Term<'tcx> { #[inline] pub fn unpack(self) -> TermKind<'tcx> { <del> let ptr = self.ptr.get(); </del> <ins> let ptr = unsafe { self.ptr.map_addr(|addr| NonZeroUsize::new_unchecked(addr.get() & !TAG_MASK)) }; </ins> // SAFETY: use of `Interned::new_unchecked` here is ok because these // pointers were originally created from `Interned` types in `pack()`, // and this is just going in the other direction. unsafe { <del> match ptr & TAG_MASK { </del> <ins> match self.ptr.addr().get() & TAG_MASK { </ins> TYPE_TAG => TermKind::Ty(Ty(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::TyKind<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::TyKind<'tcx>>>().as_ref(), </ins> ))), CONST_TAG => TermKind::Const(ty::Const(Interned::new_unchecked( <del> &*((ptr & !TAG_MASK) as *const WithCachedTypeInfo<ty::ConstData<'tcx>>), </del> <ins> ptr.cast::<WithCachedTypeInfo<ty::ConstData<'tcx>>>().as_ref(), </ins> ))), _ => core::intrinsics::unreachable(), }

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)
Change:
} } <ins> /// The resolution of a path or export. </ins> #[derive(Clone, Copy, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug)] #[derive(HashStable_Generic)] pub enum Res<Id = hir::HirId> {

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
println!("x: {}, y: {}", variable.x, variable.y); ``` <del> For more information see The Rust Book: https://doc.rust-lang.org/book/ </del> <ins> For more information about primitives and structs, take a look at The Book: https://doc.rust-lang.org/book/first-edition/primitive-types.html https://doc.rust-lang.org/book/first-edition/structs.html </ins> "##, E0611: r##"

Discussion:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker
Change:
} pub fn is_simple_path(&self) -> Option<Symbol> { <del> if let TyKind::Path(None, Path { segments, .. }) = &self && segments.len() == 1 { Some(segments[0].ident.name) </del> <ins> if let TyKind::Path(None, Path { segments, .. }) = &self && let [segment] = &segments[..] && segment.args.is_none() { Some(segment.ident.name) </ins> } else { None }

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
= note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error[E0741]: `&'static (dyn A + 'static)` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter --> $DIR/issue-63322-forbid-dyn.rs:9:18 | LL | fn test<const T: &'static dyn A>() { |                  ^^^^^^^^^^^^^^ `&'static (dyn A + 'static)` doesn't derive both `PartialEq` and `Eq` error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> For more information about this error, try `rustc --explain E0741`. </del>

Discussion:
Given the following code (): Rust gives a diagnostic suggesting deriving : However, adding leads the compiler to still give an error about not supporting this. A non-nightly compiler should not give the second error at all; it should only give the first, saying that the only supported types are integers, and . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assigning this to project-const-generics, getting worked on in https://rust-
claim
To fix this issue, you can do the following steps: grep for "forbidden as the type of a const generic parameter" look at that function for a bit change it so that the second error isn't emitted on stable (probably actually change the control flow to start by branching on In case you are interested but need more help to fix this, feel free to reach out to me on
claim
Change:
// anything else, this will combine them for us. let attrs = Attributes::from_ast(ast_attrs); if let Some(doc) = attrs.opt_doc_value() { <del> // Use the outermost invocation, so that doctest names come from where the docs were written. let span = ast_attrs .iter() .find(|attr| attr.doc_str().is_some()) .map(|attr| attr.span.ctxt().outer_expn().expansion_cause().unwrap_or(attr.span)) .unwrap_or(DUMMY_SP); </del> <ins> let span = span_of_fragments(&attrs.doc_strings).unwrap_or(sp); </ins> self.collector.position = span; markdown::find_testable_code( &doc, &mut self.collector, self.codes, self.enable_per_target_ignores, <del> Some(&crate::html::markdown::ExtraInfo::new( self.tcx, def_id, span_of_fragments(&attrs.doc_strings).unwrap_or(sp), )), </del> <ins> Some(&crate::html::markdown::ExtraInfo::new(self.tcx, def_id, span)), </ins> ); }

Discussion:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.
Change:
let mut blessed_issues_txt = fs::File::create(&blessed_issues_path).unwrap(); blessed_issues_txt.write(issues_txt_header.as_bytes()).unwrap(); // If we changed paths to use the OS separator, reassert Unix chauvinism for blessing. <del> for filename in allowed_issue_names .difference(&remaining_issue_names) .map(|s| s.replace(std::path::MAIN_SEPARATOR_STR, "/")) { write!(blessed_issues_txt, ""{filename}",n").unwrap(); </del> <ins> for filename in allowed_issue_names.difference(&remaining_issue_names) { writeln!(blessed_issues_txt, "{filename}").unwrap(); </ins> } <del> write!(blessed_issues_txt, "]n").unwrap(); </del> let old_issues_path = tidy_src.join("issues.txt"); fs::rename(blessed_issues_path, old_issues_path).unwrap(); } else {

Discussion:
1) modify some code of 2) run =for the first ~6 seconds, tidy is being built in parallel, but for the remaining ~1 minute and 9 seconds llvm is doing some sequential work. I'm not sure what takes so long, there must be one epic cgu that it is processing or something?
I wanted to check the problem but couldn't reproduce it locally.
! :thinking:
aha lol! it boils down to , an array of ~4K static &strs which is being inlined into the code it seems. When I cut the file down to just a handful of items, compilation time reduces to 7 seconds :upsidedownface: cc I guess?
Can you check if reduces this slowness?
It does indeed.
Ah, but if people give the tests meaningful names, it will reduce the build time. :relieved:
Change:
debug!("is_useful_expand_first_col: pcx={:#?}, expanding {:#?}", pcx, v[0]); if let Some(constructors) = pat_constructors(cx, v[0], pcx) { <del> let is_declared_nonexhaustive = cx.is_non_exhaustive_variant(v[0]) && !cx.is_local(pcx.ty); debug!("is_useful - expanding constructors: {:#?}, is_declared_nonexhaustive: {:?}", constructors, is_declared_nonexhaustive); if is_declared_nonexhaustive { Useful } else { split_grouped_constructors( cx.tcx, cx.param_env, constructors, matrix, pcx.ty, pcx.span, Some(hir_id), ).into_iter().map(|c| is_useful_specialized(cx, matrix, v, c, pcx.ty, witness, hir_id) ).find(|result| result.is_useful()).unwrap_or(NotUseful) } </del> <ins> debug!("is_useful - expanding constructors: {:#?}", constructors); split_grouped_constructors( cx.tcx, cx.param_env, constructors, matrix, pcx.ty, pcx.span, Some(hir_id), ).into_iter().map(|c| is_useful_specialized(cx, matrix, v, c, pcx.ty, witness, hir_id) ).find(|result| result.is_useful()).unwrap_or(NotUseful) </ins> } else { debug!("is_useful - expanding wildcard");

Discussion:
Say I have the following enum in crate : And I match on it in crate : The second branch is not detected to be unreachable. This is on current nightly; .
The reason for this behaviour is straightforward: reports tuple variants with non-exhaustive fields as always useful. This line was introduced in commit . I'm not quite sure what the intended semantics are so I wouldn't know how to fix it.
Please wait for to be merged before fixing this; I'm dreading having to rebase on top of the fix
cc
Change:
use std::str; use std::uint; use syntax::ast::*; <del> use syntax::codemap::Span; </del> <ins> use syntax::codemap::{BytePos, original_sp, Span}; </ins> use syntax::parse::token::special_idents; use syntax::parse::token; use syntax::print::pprust::{expr_to_str, block_to_str};

Discussion:
Code: Compilation attempt: It should be pointing at the semi-colon on the next line, not the comma on this line.
The note message was introduced in . It doesn't seem to handle this situation properly.
Change:
LL | |         }> | |__________^ required by this bound in `is_maybe_transmutable` <del> error: aborting due to 5 previous errors </del> <ins> error: aborting due to 7 previous errors </ins> Some errors have detailed explanations: E0080, E0277. For more information about an error, try `rustc --explain E0080`.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
self.def_path_hash_map.def_path_hash_to_def_index(&hash) } <del> fn expn_hash_to_expn_id(&self, index_guess: u32, hash: ExpnHash) -> ExpnId { </del> <ins> fn expn_hash_to_expn_id(&self, sess: &Session, index_guess: u32, hash: ExpnHash) -> ExpnId { </ins> debug_assert_eq!(ExpnId::from_hash(hash), None); let index_guess = ExpnIndex::from_u32(index_guess); let old_hash = self.root.expn_hashes.get(self, index_guess).map(|lazy| lazy.decode(self));

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. --Assuming that you copied to . <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I reproduced this ICE locally. On my end I did it by copying the git checkout of into , because I wasn't able to figure out the right invocation to get it setup with files in (Oh, whoops, I think I was accidentally passing instead of . Of course that wasn't going to work.) well, not 100%, my query stack was a little different: but it seemed like a similar bug, nonetheless.
modify labels: +I-prioritize
Assigning as discussed as part of the and removing .
Now happens for when retrying the repro. (with replaced with as it was changed in rustc) <details<summarybacktrace</summary</detailsIt also gives an unstable fingerprint ICE for when compiling : <details<summarybacktrace</summary</details
The compilation now fails when accessing session in : It looks that decodes which in turn decodes which in turn requires access to a session, but by the time of call, the session in no longer threaded through. cc
I can confirm it works now. Pushed to re-enable incremental compilation for compiling the sysroot.
Change:
///    } /// } /// ``` <ins> /// /// # Underlying System calls /// Currently, the following system calls are being used to get the current time using `now()`: /// /// |  Platform |               System call                                            | /// |:---------:|:--------------------------------------------------------------------:| /// | Cloud ABI | [clock_time_get (Realtime Clock)]                                    | /// | SGX       | [`insecure_time` usercall]. More information on [timekeeping in SGX] | /// | UNIX      | [clock_gettime (Realtime Clock)]                                     | /// | DARWIN    | [gettimeofday]                                                       | /// | VXWorks   | [clock_gettime (Realtime Clock)]                                     | /// | WASI      | [__wasi_clock_time_get (Realtime Clock)]                             | /// | Windows   | [GetSystemTimeAsFileTime]                                            | /// /// [clock_time_get (Realtime Clock)]: https://github.com/NuxiNL/cloudabi/blob/master/cloudabi.txt /// [gettimeofday]: http://man7.org/linux/man-pages/man2/gettimeofday.2.html /// [clock_gettime (Realtime Clock)]: https://linux.die.net/man/3/clock_gettime /// [__wasi_clock_time_get (Realtime Clock)]: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md#clock_time_get /// [GetSystemTimeAsFileTime]: https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimeasfiletime /// /// **Disclaimer:** These system calls might change over time. /// </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] #[stable(feature = "time2", since = "1.8.0")] pub struct SystemTime(time::SystemTime);

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[macro_export] #[cfg(dox)] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
<ins> error[E0275]: overflow evaluating the requirement `T: Trait<_>` | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_45814`) note: required because of the requirements on the impl of `Trait<_>` for `T` --> $DIR/issue-45814.rs:8:20 | LL | default impl<T, U> Trait<T> for U {} |                    ^^^^^^^^     ^ = note: 128 redundant requirements hidden = note: required because of the requirements on the impl of `Trait<_>` for `T` error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable