jiebi/CodeConvo huggingface dataset:
Change:
violations } <del> fn supertraits_reference_self(self, trait_def_id: DefId) -> bool { </del> <ins> fn predicates_reference_self( self, trait_def_id: DefId, supertraits_only: bool) -> bool { </ins> let trait_ref = ty::Binder(ty::TraitRef { def_id: trait_def_id, substs: Substs::identity_for_item(self, trait_def_id) }); <del> let predicates = self.item_super_predicates(trait_def_id); </del> <ins> let predicates = if supertraits_only { self.item_super_predicates(trait_def_id) } else { self.item_predicates(trait_def_id) }; </ins> predicates .predicates .into_iter()

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.
Change:
NO_DEBUG_ASSERTIONS=1 os: osx osx_image: xcode7.3 <del> if: branch = disabled </del> <ins> if: branch = auto </ins> # Linux builders, remaining docker images - env: IMAGE=arm-android

Discussion:
Happened for these PRs so far:
Thanks for the report. This is a Travis CI issue, currently tracked in travis-ci/travis-ci. A temporary workaround that disables all Xcode 7.3 () is currently testing.
Change:
// ignore-tidy-linelength // ignore-wasm32-bare compiled with panic=abort by default <ins> // compile-flags: -Z mir-opt-level=3 </ins> #![feature(box_syntax)] fn main() {

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Note that a similar issue () was recently closed. The fix for that ( it seems) apparently does not prevent this crash. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It seems the ICE has been fixed in latest nightly.
Bisected, I think it has been fixed by . Adding regression test is reasonable so marked as E-needstest.

When the associated constant of an impl trait is referenced it creates an ICE: This panics on stable and nightly. Tested on , macOS and in Docker: : rustc 1.38.0 ( 2019-09-23) binary: rustc commit-hash: commit-date: 2019-09-23 host: x86_64-unknown-linux-gnu release: 1.38.0 LLVM version: 9.0 The panic originates from the same assertion as in : <details<summaryBacktrace:</summary</details
cc
triage: P-medium. Removing nomination label.
The ICE seems to disappear on latest nightly, could someone confirm it?
Fixed by , but I believe it could do with a compile test
Change:
display: none; } <del> /* It doesn't render well on mobile because of the layout, so better only have the transition on desktop. */ .rustdoc.source .sidebar { transition: width .5s; } </del> .source .sidebar.expanded { width: 300px; }

Discussion:
Load Open files panel on the left. Refresh page. You'll notice everytime you load the page, the file list slides again. So we now have to wait 1s for it to stop sliding before starting to read the file we clicked on. Btw, I'd rather this never slides at all. This is time loss anyway. Could there be an option to disable this?
So there are two different things here apparently: removing the animation Don't remember the file sidebar state Did I get it right?
Yes absolutely A single simple solution to both "things" could be to completely remove the animation. I don't know of any IDE that does this - probably because it isn't optimal with regards to ergonomics. The fact the new panel now slides the code so we can read the code and have the panel open at the same time is still an improvement over the previous panel, even if we revert the animation part.
I think the idea behind the animation is to allow the reader to see that it's not hovering the code. As for the setting, not sure. What do you think
I agree with we should remove the animation. It bothers me as well, I just haven't found the time to file an issue / PR about it. :-) I don't think we should add a setting.
Ok, I'll remove the animation then. Will send a PR tomorrow. For the setting, it's that we keep the current save the state of the sidebar. Should I remove it as well?
My idea of new setting was rather "should there be an animation or should it be static", if we didn't want to remove the animation completely, for those of us that don't think the animation is worth the wait (so no need for a such new setting if we just remove the animation completely :) ) With regards to the other setting idea you seem to be talking about, it seems reasonable to me to always keep the current state of the sidebar, as we currently do, and not add an extra setting for that either :)
Oh ok. Well, that cleared things up. I'll just remove the animation then.
Change:
<ins> // check-pass trait T {} fn wrap(x: impl T) -> impl T { //~^ WARN function cannot return without recursing wrap(wrap(x)) } fn main() {} </ins>

Discussion:
Valid according to stable (1.64.0), but ICEs beta (1.65.0-beta.4) and : Reduced from a mutation of Two ICEs: <details<summary<strongFull output with both backtraces</strong</summary<p</p</details: Bisected with <a href=''cargo-bisect-rustc</aon x8664-apple-darwin: searched nightlies: from nightly-2022-08-23 to nightly-2022-10-26 regressed nightly: nightly-2022-08-31 searched commit range: regressed commit: (rollup) Among the commits in the rollup, my guess is (CC It the function (frame 19 on the first stack). It with some similarities: an unconditionally recursive function with in return position. label +regression-from-stable-to-beta +A-impl-trait
yup, ez fix incoming
Change:
start.to(end) } <ins> /// Reports a resolution failure diagnostic. /// /// Ideally we can report the diagnostic with the actual span in the source where the link failure /// occurred. However, there's a mismatch between the span in the source code and the span in the /// markdown, so we have to do a bit of work to figure out the correspondence. /// /// It's not too hard to find the span for sugared doc comments (`///` and `/**`), because the /// source will match the markdown exactly, excluding the comment markers. However, it's much more /// difficult to calculate the spans for unsugared docs, because we have to deal with escaping and /// other source features. So, we attempt to find the exact source span of the resolution failure /// in sugared docs, but use the span of the documentation attributes themselves for unsugared /// docs. Because this span might be overly large, we display the markdown line containing the /// failure as a note. </ins> fn resolution_failure( cx: &DocContext, attrs: &Attributes,

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
} .content a.primitive { color: #39a7bf; } <del> .content span.mod, .content a.mod, block a.current.mod { color: #4d76ae; } </del> <ins> .content span.externcrate, span.mod, .content a.mod, block a.current.mod { color: #4d76ae; } </ins> .content span.fn, .content a.fn, .block a.current.fn, .content span.method, .content a.method, .block a.current.method, .content span.tymethod, .content a.tymethod, .block a.current.tymethod,

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
if [ "$ALLOW_PR" = "" ] && [ "$TRAVIS_BRANCH" != "auto" ]; then echo skipping, not a full build; elif [ "$TRAVIS_OS_NAME" = "osx" ]; then <del> travis_retry sh -c 'git submodule deinit -f . && git submodule update --init' && src/ci/run.sh; </del> <ins> travis_retry stamp sh -c 'git submodule deinit -f . && git submodule update --init' && stamp src/ci/run.sh; </ins> else <del> travis_retry sh -c 'git submodule deinit -f . && git submodule update --init' && src/ci/docker/run.sh $IMAGE; </del> <ins> travis_retry stamp sh -c 'git submodule deinit -f . && git submodule update --init' && stamp src/ci/docker/run.sh $IMAGE; </ins> fi after_success:

Discussion:
Often when debugging travis logs it's difficult to see how long everything is taking as we only time some steps, not all. Additionally there's not a lot of information to see how long it takes between steps. It'd be awesome if we had a tool where we basically wrapped the entire build () in a process that simply prepended all stdout/stderr messages with a relative timestamp. AppVeyor does this by default (has a timestamp for each log line message) but unfortunately Travis doesn't. Apparently which ends up looking like https://travis- which is basically exactly what we'd want.
You probably just want to use from moreutils for this. (This is what Julia does.)
Change:
<ins> // Copyright 2012 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. //compile-flags: -Z borrowck=mir #![feature(slice_patterns)] fn mut_head_tail<'a, A>(v: &'a mut [A]) -> Option<(&'a mut A, &'a mut [A])> { match *v { [ref mut head, ref mut tail..] => { Some((head, tail)) } [] => None } } fn main() { let mut v = [1,2,3,4]; match mut_head_tail(&mut v) { None => {}, Some((h,t)) => { *h = 1000; t.reverse(); } } } </ins>

Discussion:
I believe the following should work, since and are disjoint, and is just taking a slice into (this would mean that is inaccessible while the result of is kept around): Changing it to (and removing the ):
Generally, multiple in a vector pattern should be allowable:
cc me
An interesting subquestion is whether we also want this to be allowed: In other words, whether the borrow checker should know about and attempt to reason about the disjointness of borrows into a vec beyond the scope of an individual pattern match.
Depending on how we do the implementation, it's likely that both patterns would "just work".
Triage: Nothing has changed here, at least as it pertains to , would be pretty cool if it worked.
This limitation doesn't have anything to do with slice patterns. It is even well-documented as .
I don't think it is the same, e.g. for the first example in the issue, an binding in a slice pattern is actually binding by reference (it has type or , not ), and the second one is completely unrelated.
Updated code: See also:
should be closed after MIR borrowck will be by default
Change:
#![feature(bool_to_option)] #![feature(crate_visibility_modifier)] #![feature(nll)] <ins> #![feature(or_patterns)] </ins> #![recursion_limit = "256"] pub use rustc_hir::def::{Namespace, PerNS};

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on nightly but not on beta or stable.
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
looks like the probable culprit. cc
Will fix.
Was already looking at this hehe, I have a fix for you in
Change:
/// two `Step` objects. #[unstable(feature = "step_trait", reason = "likely to be replaced by finer-grained traits")] <del> pub trait Step: Ord { </del> <ins> pub trait Step: PartialOrd { </ins> /// Steps `self` if possible. fn step(&self, by: &Self) -> Option<Self>;

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?
Change:
<ins> #![crate_name = "realcore"] #![feature(staged_api)] #![unstable(feature = "extremely_unstable", issue = "none")] #[unstable(feature = "extremely_unstable_foo", issue = "none")] pub struct Foo {} #[unstable(feature = "extremely_unstable_foo", issue = "none")] pub trait Join {} #[unstable(feature = "extremely_unstable_foo", issue = "none")] impl Join for Foo {} #[stable(feature = "faked_deref", since = "1.47.0")] pub trait Deref {} </ins>

Discussion:
Missing Implementors for [][1] trait. Current output: ! While rustdoc displays [][2] trait implementors. Expected: Display Implementors for Join trait: : 1.47.0-nightly ( 2020-08-15) [1]: [2]: modify labels: T-rustdoc
This is a regression from stable-to-nightly: and beta one has Implementors section. cc
It has made it way to beta. Pattern trait is also affected: modify labels: I-prioritize
(Btw I think you can use as a shorthand)
The Borrow trait still has , I am not sure if this bug affect crates in ecosystem.
So I think this bug shouldn't affect stable traits, just most unstable traits I saw are affected.
There is high change that causing the regression, but I cannot prove that.
This is more likely to be than the refactor I think.
Yeah, I suspect that given it might make sense to revert anyway, since it doesn't actually accomplish the goal. Or someone more experienced with rustdoc may be able to suggest/implement a better patch.
New discovery: So far only trait exported to std affected. For example with Join trait, in alloc it is normal:
Oh right, I have MCVE, it needs two dummy crates. <details<summarydummy crate "unstabled"</summary</detailsCrate to run : modify labels: -E-needs-mcve
searched nightlies: from nightly-2020-06-04 to nightly-2020-07-17 regressed nightly: nightly-2020-07-17 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
That rollup includes both and ; of the two I think is the more likely culprit.
Marking as P-high .

appears on the current nightly's, even though it's not part of the (public) standard libraries. This appears to be , so maybe related to , cc Noticed by (assuming they use the same handle here and discord, if not, sorry :flushed:)
Relevant PRs (backtrace isn't really to blame here): ,
Maybe this should also skip the impl if there is no 'stability' attribute? ,
This is the default for everything not in the standard library. So it seems like the standard library needs special casing here. Maybe as simple as ?
Doesn't gimli get everything marked as unstable behind the rustc_private feature gate through a rustc flag?
MCVE: It doesn't require any external deps, just dummy crates included. The outermost crate is a fake std, realcore is fake core, gimli is fake gimli.
Change:
.tcx .infer_ctxt() .build() <del> .type_implements_trait(iter_trait, [ty], param_env) </del> <ins> .type_implements_trait(iter_trait, [ty], cx.param_env) </ins> .must_apply_modulo_regions() { return;

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. --This appears to be an issue in the lint, possibly it assuming can be normalized, when due to the bound and the lack of implementation , the type is effectively <!-- 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. --: locally <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Still crashes with , although the Ice is a bit different.
I would appreciate if you opened a new issue for that, and shared the backtrace, etc there instead.
Change:
// Re-use parent metadata to determine dynamic field layout. // With custom DSTS, this *will* execute user-defined code, but the same // happens at run-time so that's okay. <del> let align = match self.size_and_align_of(&base.meta, &field_layout)? { Some((_, align)) => align, None if offset == Size::ZERO => { // An extern type at offset 0, we fall back to its static alignment. // FIXME: Once we have made decisions for how to handle size and alignment // of `extern type`, this should be adapted.  It is just a temporary hack // to get some code to work that probably ought to work. field_layout.align.abi </del> <ins> match self.size_and_align_of(&base.meta, &field_layout)? { Some((_, align)) => (base.meta, offset.align_to(align)), None => { // For unsized types with an extern type tail we perform no adjustments. // NOTE: keep this in sync with `PlaceRef::project_field` in the codegen backend. assert!(matches!(base.meta, MemPlaceMeta::None)); (base.meta, offset) </ins> } <del> None => span_bug!( self.cur_span(), "cannot compute offset for extern type field at non-0 offset" ), }; (base.meta, offset.align_to(align)) </del> <ins> } </ins> } else { // base.meta could be present; we might be accessing a sized field of an unsized // struct.

Discussion:
A slightly different reproducer that doesn't rely on constant propagation pass, and so should be more robust: label +A-const-eval +F-extern_types
Error: Malformed in master branch. missing field for key at line 156 column 1 Please let know if you're having trouble with this bot.
Change:
have_turbofish, } = args; let generics = tcx.generics_of(generics_def_id); <del> if let Some(argument_index) = generics </del> <ins> if let Some(mut argument_index) = generics </ins> .own_substs(substs) .iter() .position(|&arg| self.generic_arg_contains_target(arg)) { <ins> if generics.parent.is_none() && generics.has_self { argument_index += 1; } </ins> let substs = self.infcx.resolve_vars_if_possible(substs); let generic_args = &generics.own_substs_no_defaults(tcx, substs) [generics.own_counts().lifetimes..];

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. --: This was also tried on with on Rust Playground, with the same error. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsWithout the fully qualified path, see commented code, the error is . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized: Looking into this. claim label D-incorrect
Change:
let principal_a = data_a.principal().unwrap(); let target_trait_did = principal_def_id_b.unwrap(); let source_trait_ref = principal_a.with_self_ty(self.tcx(), source); <ins> if let Some((deref_output_ty, deref_output_trait_did)) = self .need_migrate_deref_output_trait_object( source, &obligation.cause, obligation.param_env, ) { if deref_output_trait_did == target_trait_did { self.tcx().struct_span_lint_hir( DEREF_INTO_DYN_SUPERTRAIT, obligation.cause.body_id, obligation.cause.span, |lint| { lint.build(&format!( "`{}` implements `Deref` with supertrait `{}` as output", source, deref_output_ty )).emit(); }, ); return; } } </ins> for (idx, upcast_trait_ref) in util::supertraits(self.tcx(), source_trait_ref).enumerate() {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!--<details<summaryBacktrace</summary<p</p</details--(not applicable) <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.