jiebi/CodeConvo huggingface dataset:
Change:
<ins> //@ run-rustfix #[allow(dead_code)] fn main() { struct S<'a>(&'a ()); fn f1(s: S<'_>) -> S<'_> { //~^ ERROR the placeholder `_` is not allowed s } fn f2(s: S<'_>) -> S<'_> { //~^ ERROR the placeholder `_` is not allowed let x = true; if x { s } else { s } } fn f3(s: S<'_>) -> S<'_> { //~^ ERROR the placeholder `_` is not allowed return s; } fn f4(s: S<'_>) -> S<'_> { //~^ ERROR the placeholder `_` is not allowed let _x = 1; return s; } } </ins>

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
pub fn nonzeroing_move_hints(&self) -> bool { self.opts.debugging_opts.enable_nonzeroing_move_hints } <ins> pub fn overflow_checks(&self) -> bool { self.opts.cg.overflow_checks .or(self.opts.debugging_opts.force_overflow_checks) .unwrap_or(self.opts.debug_assertions) } </ins> pub fn must_not_eliminate_frame_pointers(&self) -> bool { self.opts.debuginfo != DebugInfoLevel::NoDebugInfo ||

Discussion:
Tracking issue for
FWIW this should be a relatively easy bug to knock out! The option is and we'd just want to add a new flag to the (we'll delete the flag once everyone's migrated). There's a few uses throughout the codebase which I believe will need an update:    After that we'd just need to add a test which validates this behavior, likely a addition with a annotation at the top. Likewise the Cargo support should be relatively easy:
I'd like to tackle this!
OK, so this is pretty straightforward. Couple questions after actually implementing this: The RFC says the option is , but comments on the RFC suggest that people expect this to be , so one could have (I guess) . Which variant should be supported? It seems better to make the value in the single source of truth to be used throughout the compiler by setting it based on the value of or ; this makes the uses easier to read and also makes any future removal of straightforward. How should interact with ? Should we just consider any explicit setting of to "win" and only consult if the option was not explicitly provided? I guess that would mean that we'd almost have to implement the variant above?
I think it's fine to just reuse the existing  which accepts a "standard variety" of boolean options. Makes sense to me to have a single source of truth! Right now I don't think we have a lot of precedent for modifying after creation so this may not be easy. Perhaps a helper method on though? That's what a . Yeah let's just have trump . The precise semantics likely don't matter too much anyway as we'll quickly phase out the version anyway.
Change:
_ => false, } } <del> crate fn as_assoc_kind(&self) -> Option<AssocKind> { match *self { ItemKind::AssocConstItem(..) => Some(AssocKind::Const), ItemKind::AssocTypeItem(..) => Some(AssocKind::Type), ItemKind::TyMethodItem(..) | ItemKind::MethodItem(..) => Some(AssocKind::Fn), _ => None, } } </del> } #[derive(Clone, Debug)]

Discussion:
: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Nearly 100% of that time is spent in . ! Is this even required for intra-doc links? AFAIK this is only for and , which don't have associated items.
... why is taking a quarter of the time?
I think this could be sped up quite a bit by only considering traits that have an associated item of the right name. Then rustdoc wouldn't have to go through the trait system at all, just look at it long enough to see it wouldn't work even if it did apply to the type.
Relevant code: We could change to take a parameter, that wouldn't be too invasive I think.
It probably also doesn't help that simplifies the type to an extent where all generic args are erased and then iterates on all trait implementations of it: If you have gazillions of then that's a problem :) Reducing the number of traits this (rather expensive) search is done is a good idea!
I think the strategy similar to would be helpful here too, but I guess the lower hanging fruit (checking whether the trait contains the name in the first place) should be tried before.
Discussed in Discord with , I'll be trying my hand at this one :rocket: claim
Change:
self.tcx.check_stability(field.did, Some(expr.hir_id), expr.span, None); return field_ty; } <del> private_candidate = Some((adjustments, base_def.did(), field_ty)); </del> <ins> private_candidate = Some((adjustments, base_def.did())); </ins> } } ty::Tuple(tys) => {

Discussion:
The code below yields two errors: field is private error in if expression because type is instead of This means a user can observe the type of a private field of a dependency in their error messages. It doesn't mean they can actually use that information, but it seems weird at least. Is this actually an issue? If you don't consider it one, feel free to close this. - - (originally seen )
I won't close the ticket as this deserves a conversation to be had, but I personally don't consider it to be a big problem. Parsing x.len as when we suggest that would be nice, but in this case it would lead to confusing errors if we don't annotate the compiler state with something along the lines of
Hi Do any of you have opinions on this matter? I lean towards closing as "wontfix" because I feel the current behavior is acceptable.
I agree, like you mentioned , there are some improvements we could make, but I think the current behaviour is fine.
Change:
use crate::intrinsics; use crate::mem::SizedTypeProperties; <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> use crate::slice::sort::shared::find_existing_run; <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> use crate::slice::sort::shared::smallsort::insertion_sort_shift_left; pub(crate) mod heapsort;

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
Change:
<ins> // build-pass // // compile-flags: -g --emit=llvm-ir -Zunstable-options -Csplit-debuginfo=unpacked // // Make sure that we don't explode with an error if we don't actually end up emitting any `dwo`s, // as would be the case if we don't actually codegen anything. #![crate_type="rlib"] </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. --glacier <!-- 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. --: Note: you need a build with rustc debug assertions enabled! <!-- 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
Change:
} /// Parses the parameter list of a function, including the `(` and `)` delimiters. <del> fn parse_fn_params(&mut self, req_name: ReqName) -> PResult<'a, Vec<Param>> { </del> <ins> pub(super) fn parse_fn_params(&mut self, req_name: ReqName) -> PResult<'a, Vec<Param>> { </ins> let mut first_param = true; // Parse the arguments, starting out with `self` being allowed... let (mut params, _) = self.parse_paren_comma_seq(|p| {

Discussion:
The following code: currently produces a heap of semi-helpful diagnostics: <details<summary<bstderr (7 errors)</b</summary</detailswhen instead we could special-case this and emit a single (or at least fewer) diagnostic that suggests the following: If the bound in not inside , like in: we currently emit the following: which is less verbose for sure but still, we should provide the same suggestion I propose above. Related issue: . label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing ping command in failed: ...'stbot ping' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I'd like to take a look. claim
I'm wondering if taking an approach that suggests using higher-rank trait bounds () for an Fn-family trait with a lifetime parameter. Is it appropriate? I'm concerned that it may not a comprehensive solution because HRTB can be used outside of the Fn-family traits (as I understand). Or is it okay only for the Fn-family traits for now?
I am not sure I fully understand what you mean. As you probably know, none of , , take a lifetime parameter and probably never will. Of course, you could define such a trait with unstable features but there is no way to use them, so it's not relevant: Yes, I'd say so. I wouldn't look for names however (like , , …) but just look for an opening parenthesis after a generic parameter list. This way, we can emit the same suggestion for the following case (where the name is ):
Ah, definitely. Thank you!
Change:
// @has doc_cfg/unix_only/trait.ArmOnly.html  //  '//*[@id="main"]/*[@class="stability"]/*[@class="stab portability"]'  //  'This is supported on Unix and ARM only.' <del> // @count - '//*[@class="stab portability"]' 2 </del> <ins> // @count - '//*[@class="stab portability"]' 1 </ins> #[doc(cfg(target_arch = "arm"))] pub trait ArmOnly { fn unix_and_arm_only_function(); } <ins> #[doc(cfg(target_arch = "arm"))] </ins> impl ArmOnly for super::Portable { fn unix_and_arm_only_function() {} }

Discussion:
I tried this code: I expected to see this happen: both impls being highlighted as needing the feature. Instead, this happened: only the impl got the message: ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: +T-rustdoc
claim
Change:
extern crate consts; use consts::CustomEq; <ins> struct Defaulted; impl consts::AssocConst for Defaulted {} </ins> fn main() { <ins> let _ = Defaulted; </ins> match Some(CustomEq) { consts::NONE => panic!(), _ => {} } <ins> match Some(CustomEq) { <Defaulted as consts::AssocConst>::NONE  => panic!(), _ => {} } </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. --I don't have a reasonable sized reproducer yet. <!-- 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. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
<ins> // check-pass // Use of global static variables in literal values should be allowed for // promotion. // This test is to demonstrate the issue raised in // https://github.com/rust-lang/rust/issues/70584 // Literal values were previously promoted into local static values when // other global static variables are used. struct A<T: 'static>(&'static T); struct B<T: 'static + ?Sized> { x: &'static T, } static STR: &'static [u8] = b"hi"; static C: A<B<B<[u8]>>> = { A(&B { x: &B { x: STR }, }) }; pub struct Slice(&'static [i32]); static CONTENT: i32 = 42; pub static CONTENT_MAP: Slice = Slice(&[CONTENT]); pub static FOO: (i32, i32) = (42, 43); pub static CONTENT_MAP2: Slice = Slice(&[FOO.0]); fn main() { assert_eq!(b"hi", C.0.x.x); assert_eq!(&[42], CONTENT_MAP.0); assert_eq!(&[42], CONTENT_MAP2.0); } </ins>

Discussion:
The below code compiles in 1.40.0 but not in 1.42.0 (stable). (minimized example from rust-phf) When built in 1.42.0, it produces the following error: The same error occurs using nightly. There's an issue from January mentioning this build error on the rust-phf repo (seems to occur in 1.41.0+), but no followup discussion/work that I could find.
Notes: the same error occurs if is a struct instead of an enum the error does not occur if is removed and the is stored directly on
Minimized: must be a for this to happen, with a it doesn't happen.
This happens on both 1.41.0 and 1.41.1, so it's not fallout from (which fixed in that release). There's no entry in the release notes or blog post for 1.41.0 that indicates that this is expected fallout. cc anyways re: borrowck
regressed nightly: nightly-2019-11-24 searched commits: from to regressed commit: modify labels to -E-needs-bisection
Nice, thanks Looks like is the cause then.
assign
This issue was . Tagging as and unnominating.
So... the bug is fairly simple, albeit not easy to fix. The problem is that any use of a static anywhere like becomes This has various positive effects on rustc, making many implementation things easier, but it also means that it broke promoting reading from statics within other statics, because we will never ever support promoting &*STATICREFtmpSTATICREF`, so this is the special case we're allowed to deref.
Change:
| = note: `FnMut` closures only have access to their captured variables while they are executing... = note: ...therefore, they cannot allow references to captured variables to escape <ins> help: consider adding 'move' keyword before the nested closure | LL |                move || { |                ++++ </ins> error[E0503]: cannot use `f.x` because it was mutably borrowed --> $DIR/borrowck-describe-lvalue.rs:37:9

Discussion:
Given the following code: The current output is: The actually needed fix here is the following, which should ideally be recommended <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly more minimal:
claim
I came up with a solution of printing an extra line of to give user a recommendation of fixing the error by adding 'move' keyword before the closure parameter of map(). The following is the output for the first testing code. Is this good enough? This is the output from the second testing code ():
Refined the fix with a verbose suggestion of where to add keyword. The output of the first test case is: The output of the second test case is: In addition, the fix will also add the suggestion for nested closure block like this test case: The output of the above test case is:
Change:
); } } else { <del> // Encountered a real ambiguity, so abort the lookup. If `ty` is not // an `Err`, report the right "type annotations needed" error pointing // to it. </del> <ins> // Ended up encountering a type variable when doing autoderef, // but it may not be a type variable after processing obligations // in our local `FnCtxt`, so don't call `structurally_resolved_type`. </ins> let ty = &bad_ty.ty; let ty = self .probe_instantiate_query_response(span, &orig_values, ty) .unwrap_or_else(|_| span_bug!(span, "instantiating {:?} failed?", ty)); <del> let ty = self.structurally_resolved_type(span, ty.value); assert!(matches!(ty.kind(), ty::Error(_))); </del> <ins> let ty = self.resolve_vars_if_possible(ty.value); let guar = match *ty.kind() { ty::Infer(ty::TyVar(_)) => self .err_ctxt() .emit_inference_failure_err(self.body_id, span, ty.into(), E0282, true) .emit(), ty::Error(guar) => guar, _ => bug!("unexpected bad final type in method autoderef"), }; self.demand_eqtype(span, ty, self.tcx.ty_error(guar)); </ins> return Err(MethodError::NoMatch(NoMatchData { static_candidates: Vec::new(), unsatisfied_predicates: Vec::new(),

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. --It seems this is a particularly tricky interaction of , coercion and these two ; take away any one, and the compiler spits out a type annotation error as seen below. The compiler is also happy if is annotated as but I don't quite understand why this needs to be specified, given the inner casts on both branches. <!-- 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
reduced a bit
Regression in nightly-2020-06-24
This is minimized in the sense that spurious errors are avoided: The problem here is that the autoderef of a method is interacting strangely with the obligation registered by the line. This actually guides inference in such a way that an assertion in the compiler is not upheld -- that assertion is kinda nonsense though, so I'm just gonna rework it.
I've tried bisecting to a narrower point but didn't get far: commit[0] 2020-06-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[1] 2020-06-22: Auto merge of - Aaron1011:revert/move-fn-self-msg, r=Manishearth commit[2] 2020-06-23: Auto merge of - yoshuawuyts:socketaddr-from-string-u16, r=sfackler commit[3] 2020-06-23: Auto merge of - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC commit[4] 2020-06-23: Auto merge of - Manishearth:rollup-68dr8fz, r=Manishearth commit[5] 2020-06-23: Auto merge of - ollie27:rustdocaliasfilter, r=GuillaumeGomez So I guess one , or WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
lib::llvm::RelocPIC, OptLevel, true, <del> use_softfp </del> <ins> use_softfp, no_fp_elim </ins> ) }) })

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
Compatibility notes ------------------- <ins> - [Ignore derived `Clone` and `Debug` implementations during dead code analysis.][85200] This will break some builds that set `#![deny(dead_code)]`. </ins> Internal changes ---------------- These changes provide no direct user facing benefits, but represent significant

Discussion:
landed in 1.57, causing derived and implementations to be ignored during dead code analysis. The for 1.57 don't mention this change anywhere. There's discussion in the original PR about including it in the release notes, but looks like nobody got around to it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this is also worth a mention in the compatibility notes for 1.57, given that it can break builds where is set.
label +D-incorrect +D-invalid-suggestion
label -D-incorrect -D-invalid-suggestion
My bad there, had two different issues open.
I'd be happy to approve a PR adding a line to the release notes about this.
claim
Change:
} impl<'a> StringReader<'a> { <del> pub fn new( </del> <ins> crate fn new( </ins> sess: &'a ParseSess, source_file: Lrc<rustc_span::SourceFile>, override_span: Option<Span>,

Discussion:
In , we would like to tweak the structure of the tokens rustc uses. One of the components which heavily depends on the current structure is ( and module use ). I think, for this issue and in general, it makes sense to switch over to , which produces lower-level guaranteed lossless tokens, which look like a better fit for the task of syntax highlighting. I plan to do this refactor myself, but I want to check with if this is a good idea. EDIT: cc
sgtm
I'm fine with it as well. :)
BTW, is there some chat room for rustdoc team on zulip on discord? I'd like to ask some questions :)
There is one on discord (simply called "rustdoc").
It's linked at (which is I agree pretty hard to find). Also the text there is wrong and mentions , we should probably fix that.
Change:
<ins> // Copyright 2016 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. trait A<T>: std::ops::Add<Self> + Sized {} trait B<T>: A<T> {} trait C<T>: A<B<T, Output=usize>> {} //~^ ERROR the trait `B` cannot be made into an object fn main() {} </ins>

Discussion:
the following generates a compiler error on all current versions: RUST_BACKTRACE hangs for me, but emits: error: internal compiler error: Unexpected type in full type resolver: FreshTy(0) This is greatly cut down from a real world example, and a blocking issue for me
This is a regression of the release (over ) of rust.
triage: P-medium Pretty old regression, barely qualifies. =) However, says he has a fix.
Oh sorry, disregary my comment above, the issue is reproducible on 1.3.0 as well as on stable 1.0.0. Its not a regression, at least not one from a stable rust release.