jiebi/CodeConvo huggingface dataset:
Change:
} } <del> fn is_non_exhaustive_variant<'p>(&self, pattern: &'p Pat<'tcx>) -> bool { match *pattern.kind { PatKind::Variant { adt_def, variant_index, .. } => { let ref variant = adt_def.variants[variant_index]; variant.is_field_list_non_exhaustive() } _ => false, } } </del> fn is_non_exhaustive_enum(&self, ty: Ty<'tcx>) -> bool { match ty.kind { ty::Adt(adt_def, ..) => adt_def.is_variant_list_non_exhaustive(),

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:
trait_pred: ty::PolyTraitPredicate<'tcx>, ); <ins> fn suggest_add_clone_to_arg( &self, obligation: &PredicateObligation<'tcx>, err: &mut Diagnostic, trait_pred: ty::PolyTraitPredicate<'tcx>, ) -> bool; </ins> fn suggest_add_reference_to_arg( &self, obligation: &PredicateObligation<'tcx>,

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
use self::Arch::*; #[allow(non_camel_case_types)] <ins> #[derive(Copy)] </ins> pub enum Arch { Armv7, Armv7s,

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
z-index: -1; border-bottom: 1px solid; } <ins> .collapse-toggle { left: -17px; } </ins> }

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

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
// This closure is a more robust way to check `Predicate` equality // than simple `==` checks (which were the previous implementation). <del> // It relies on `ty::relate` for `TraitPredicate` and `ProjectionPredicate` // (which implement the Relate trait), while delegating on simple equality // for the other `Predicate`. </del> <ins> // It relies on `ty::relate` for `TraitPredicate`, `ProjectionPredicate`, // `ConstEvaluatable` and `TypeOutlives` (which implement the Relate trait), // while delegating on simple equality for the other `Predicate`. </ins> // This implementation solves (Issue #59497) and (Issue #58311). // It is unclear to me at the moment whether the approach based on `relate` // could be extended easily also to the other `Predicate`.

Discussion:
This issue seems to be specific to the trait. : label A-const-generics F-constevaluatablechecked T-compiler
Also, is it expected that the where bounds need to be repeated in each of the type's trait impls?
Yes, bounds on type definitions need to be repeated in impls, at least until are introduced.
Is anyone aware of a way to work around this issue at the moment?
Change:
impl_span: Span, err: &mut Diag<'_, G>, ) { <del> if (overlap.trait_ref, overlap.self_ty).references_error() { err.downgrade_to_delayed_bug(); } </del> match tcx.span_of_impl(overlap.with_impl) { Ok(span) => { err.span_label(span, "first implementation here");

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'', 'thread 'rustc' panicked at 'downgradetodelayedbug: cannot downgrade Warning to DelayedBug: not an error'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
Regression in nightly-2023-03-22 commit[0] 2023-03-20: Auto merge of - euclio:windows-rs, r=ChrisDenton commit[1] 2023-03-20: Auto merge of - Zoxc:split-execute-job, r=cjgillot,michaelwoerister commit[2] 2023-03-21: Auto merge of - ChrisDenton:libntdll, r=Mark-Simulacrum commit[3] 2023-03-21: Auto merge of - TDecki:dec2flt-inline, r=thomcc commit[4] 2023-03-21: Auto merge of - saethlin:remove-vec-as-ptr-assume, r=thomcc commit[5] 2023-03-21: Auto merge of - Nilstrieb:rollup-seb5xsa, r=Nilstrieb commit[6] 2023-03-21: Auto merge of - ferrocene:pa-test-metrics, r=Mark-Simulacrum commit[7] 2023-03-21: Auto merge of - compiler-errors:local-key, r=cjgillot commit[8] 2023-03-21: Auto merge of - matthiaskrgr:rollup-odn02wu, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days
oh nevermind, still crashes with next-solver-coherence :cryingcatface:
Change:
<ins> // compile-fail pub const unsafe fn fake_type<T>() -> T { hint_unreachable() } pub const unsafe fn hint_unreachable() -> ! { fake_type() //~ ERROR any use of this value will cause an error } trait Const { const CONSTANT: i32 = unsafe { fake_type() }; } impl <T> Const for T {} pub fn main() -> () { dbg!(i32::CONSTANT); //~ ERROR erroneous constant used } </ins>

Discussion:
Probably one should never write this, and I wonder if it will be disallowed in the future. Happens on stable, beta and nightly, in all const-forms existing (includes const generics) <details<summaryBacktrace:</summary</details
Note: You could also write it the following way, in order to not need the attribute, as the previous code complains about recursion without that attribute.
Regression introduced in
cc due to Edit: I think I have a fix for this.
Change:
_ => "".to_string(), }; let m = MutableSpace(mutability); <ins> let amp = if f.alternate() { "&".to_string() } else { "&amp;".to_string() }; </ins> match **ty { clean::Slice(ref bt) => { // BorrowedRef{ ... Slice(T) } is &[T] match **bt { clean::Generic(_) => { if f.alternate() { primitive_link(f, PrimitiveType::Slice, <del> &format!("&{}{}[{:#}]", lt, m, **bt)) </del> <ins> &format!("{}{}{}[{:#}]", amp, lt, m, **bt)) </ins> } else { primitive_link(f, PrimitiveType::Slice, <del> &format!("&amp;{}{}[{}]", lt, m, **bt)) </del> <ins> &format!("{}{}{}[{}]", amp, lt, m, **bt)) </ins> } } _ => { <ins> primitive_link(f, PrimitiveType::Slice, &format!("{}{}{}[", amp, lt, m))?; </ins> if f.alternate() { <del> primitive_link(f, PrimitiveType::Slice, &format!("&{}{}[", lt, m))?; </del> write!(f, "{:#}", **bt)?; } else { <del> primitive_link(f, PrimitiveType::Slice, &format!("&amp;{}{}[", lt, m))?; </del> write!(f, "{}", **bt)?; } primitive_link(f, PrimitiveType::Slice, "]")

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
#![feature(hashmap_internals)] #![feature(try_find)] #![feature(is_sorted)] <del> #![feature(iter_once_with)] </del> #![feature(pattern)] #![feature(range_is_empty)] #![feature(raw)]

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: fcp 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] [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.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
use rustc_middle::mir::visit::{MutatingUseContext, NonMutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::*; use rustc_middle::ty::cast::CastTy; <del> use rustc_middle::ty::subst::GenericArgKind; </del> <ins> use rustc_middle::ty::subst::{GenericArgKind, InternalSubsts}; </ins> use rustc_middle::ty::{self, adjustment::PointerCast, Instance, InstanceDef, Ty, TyCtxt}; use rustc_middle::ty::{Binder, TraitPredicate, TraitRef}; use rustc_span::{sym, Span, Symbol};

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. --code from glacier/fixed/-1.rs <!-- 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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.
Change:
<ins> error[E0017]: references in statics may only refer to immutable values --> $DIR/static_mut_containing_mut_ref2.rs:5:46 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^ statics require immutable values error[E0019]: static contains unimplemented expression type --> $DIR/static_mut_containing_mut_ref2.rs:5:45 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors Some errors occurred: E0017, E0019. For more information about an error, try `rustc --explain E0017`. </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
self.create_def(expr.id, kw::Empty, DefKind::Closure, expr.span) } ExprKind::ConstBlock(ref constant) => { <ins> for attr in &expr.attrs { visit::walk_attribute(self, attr); } </ins> let def = self.create_def( constant.id, kw::Empty,

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
bisects to cc
That's a revert, the issue probably exists much longer
ah :+1: when I start the bisection at a later point, this goes down to Regression in nightly-2023-11-29 probably ?
Jup, that looks like it
Change:
error_code, pluralize, struct_span_err, Applicability, DiagnosticBuilder, Style, }; use rustc_hir as hir; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::DefId; use rustc_hir::intravisit::Visitor; use rustc_hir::Node;

Discussion:
The following code was working in nightly-2019-09-05, but no longer works in nightly-2019-10-15. The workaround is not quite intuitive. () Errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm also running into this error using Tide and a DB Pool from Diesel I've managed to get a slightly simpler/different version of the above code - I'd expect this to work because I'd expect the to be finished before the starts (I guess it's similar to how pre-NLL we'd expect function calls in arguments to work but sometimes they wouldn't because existing borrows?) I've managed to track it down to happening somewhere between these - but I'm not sure how to go about figuring this out any further (I've never built the compiler, let alone actually debugged it) This successfully buildsThis fails
This was an intentional change to match the drop order in synchronous code:
This was an intentional change but these errors also look like they are caused by "overapproximation" of the set of captured values. We are working to improve that; separately, we are also working on improving the diagnostics here.
Assigning to myself as this is a case I'd hope to tackle in . It isn't currently handled by that PR, as the current diagnostic improvements only work when the error originates from an , not . claim
I found a similar problem: Is this the same bug?
Unassigning myself since has landed.
adds a compiler message to suggest a workaround for this problem. Is it not possible to make the compiler smarter and not borrow unnecessary variables across ?
rustc is not that smarter yet, we already have an issue tracking this , along with were trying to lint users with "shorten" workaround(might be lifted once the analysis is improved) in these two "common" cases.
It's a matter of having consistent language semantics for async and non-async code. The lang team discussed this and decided the drop order should be consistent (i.e. we shouldn't drop temporaries until the end of the statement, even if the statement contains ).
Change:
<del> Subproject commit d4e4fe71e6a9568f5d081d99f1c621c5a4ddd7db </del> <ins> Subproject commit 8355437d5d0e747b7e7239cd0a2af8a3825bd912 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Miri fix:
triage: P-medium. Removing nomination label.
Change:
<ins> use std::ops::Deref; fn foo<P>(_value: <P as Deref>::Target) where P: Deref, <P as Deref>::Target: Sized, {} fn main() { foo::<Box<u32>>(2); } </ins>

Discussion:
does not build on the current nightly because the compiler is unable to infer that a type is . This is a regression in the latest nightly. The line that errors is . Error message: Relevant commits: cc rust-lang-nursery/futures-rs
Minimized example without and external dependencies: .
Possibly caused by cc
Enabling the feature fixes this, so this is being caused by the gate .
Perhaps do I need some normalization before doing deferred ness checking?
triage. This is now a stable-to-beta regression. P-high.
assigning to to either r+ PR , come up with a new fix, or delegate those options to someone else.
Change:
"associated type bindings are not allowed here"); } } <ins> fn check_type_argument_count(tcx: &ty::ctxt, span: Span, supplied: usize, required: usize, accepted: usize) { if supplied < required { let expected = if required < accepted { "expected at least" } else { "expected" }; span_err!(tcx.sess, span, E0243, "wrong number of type arguments: {} {}, found {}", expected, required, supplied); } else if supplied > accepted { let expected = if required < accepted { "expected at most" } else { "expected" }; span_err!(tcx.sess, span, E0244, "wrong number of type arguments: {} {}, found {}", expected, accepted, supplied); } } fn report_lifetime_number_error(tcx: &ty::ctxt, span: Span, number: usize, expected: usize) { span_err!(tcx.sess, span, E0107, "wrong number of lifetime parameters: expected {}, found {}", expected, number); } </ins>

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.
Change:
// Parse and strip the disambiguator from the link, if present. let (disambiguator, path_str, link_text) = match Disambiguator::from_str(link) { Ok(Some((d, path, link_text))) => (Some(d), path.trim(), link_text.trim()), <del> Ok(None) => (None, link.trim(), link.trim()), </del> <ins> Ok(None) => (None, link, link), </ins> Err((err_msg, relative_range)) => { // Only report error if we would not have ignored this link. See issue #83859. if !should_ignore_link_with_disambiguators(link) {

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. --: <details<summarycargo bisect-rustc points </summarysearched nightlies: from nightly-2023-01-30 to nightly-2023-02-13 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: </details label +regression-from-stable-to-nightly +T-rustdoc
cc as author of
Duplicate of
I have a similar problem. Steps to reproduce:
Same issue also reproduces when is documented directly, not as a dependency.
The link in looks like this , not the single backtick and also whitespace. Looks like a mismatch in preprocessing the stuff inside between rustc and rustdoc.
link , extra whitespace.
Oh, yes, this reproduces:
There's still something else going on since AFAICT there are no links in case of
link , extra newlines (?) after the doc strings are merged.
Oh, I was looking at the wrong macro, sorry. :man_facepalming:
I'll try to fix all this stuff tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Fixed in
Change:
<ins> error[E0277]: the trait bound `u8: Trait` is not satisfied --> $DIR/issue-95665.rs:14:17 | LL |     static VAR: Struct<u8>; |                 ^^^^^^^^^^ the trait `Trait` is not implemented for `u8` | note: required by a bound in `Struct` --> $DIR/issue-95665.rs:6:22 | LL | pub struct Struct<T: Trait> { |                      ^^^^^ required by this bound in `Struct` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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. --: Also reproduces on 1.58.0 and 1.59.0. <!-- 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