jiebi/CodeConvo huggingface dataset:
Change:
<ins> // build-pass // issue: #115807 trait Chip: for<'a> TraitWithLifetime<'a> + SomeMarker { fn compute(&self); } trait SomeMarker {} trait TraitWithLifetime<'a>: SomeMarker {} trait Machine { fn run(); } struct BasicMachine; impl Machine for BasicMachine { fn run() { let chips: [&dyn Chip; 0] = []; let _ = chips.map(|chip| chip.compute()); } } fn main() { BasicMachine::run(); } </ins>

Discussion:
: The bug seems to be present in the latest nightly at well as stable. <details<summary<strongBacktrace</strong</summary<p</p</details
It seems like this has something to do with appearing multiple times, once in 's bound, then again in 's. Switching the order of the two bounds seems to avoid the error.
Regression in nightly-2021-07-25 commit[0] 2021-07-23: Auto merge of - JohnTitor:rollup-dht22jk, r=JohnTitor commit[1] 2021-07-23: Auto merge of - JohnTitor:get-by-key-enum-part-2, r=oli-obk commit[2] 2021-07-24: Auto merge of - SparrowLii:MaybeTrait, r=wesleywiser commit[3] 2021-07-24: Auto merge of - Mark-Simulacrum:bump-version, r=Mark-Simulacrum commit[4] 2021-07-24: Auto merge of - In-line:zircon-thread-name, r=JohnTitor commit[5] 2021-07-24: Auto merge of - crlf0710:rich_vtable, r=nikomatsakis commit[6] 2021-07-24: Auto merge of - Aaron1011:inert-warn, r=petrochenkov commit[7] 2021-07-24: Auto merge of - Manishearth:rollup-b09njin, r=Manishearth commit[8] 2021-07-24: Auto merge of - BoxyUwU:cgd-subst-ice, r=nikomatsakis
Change:
&self, buffer: &mut StyledBuffer, row_num: &mut usize, <del> highlight_parts: &Vec<SubstitutionHighlight>, </del> <ins> highlight_parts: &[SubstitutionHighlight], </ins> line_num: usize, line_to_add: &str, show_code_change: DisplaySuggestion,

Discussion:
The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"<!-- 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 on stable: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Change:
|                 | |                 &str <del> error[E0369]: cannot add `{integer}` to `&str` --> $DIR/issue-79040.rs:2:25 </del> <ins> error: missing type for `const` item --> $DIR/issue-79040.rs:2:11 </ins> | LL |     const FOO = "hello" + 1; <del> |                 ------- ^ - {integer} |                 | |                 &str </del> <ins> |           ^^^ help: provide a type for the item: `FOO: <type>` </ins> error: aborting due to 2 previous errors

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
/// ## Examples /// /// ``` <del> /// #![feature(vec_extend_from_within)] /// </del> /// let mut vec = vec![0, 1, 2, 3, 4]; /// /// vec.extend_from_within(2..);

Discussion:
Feature gate: This is a tracking issue for , which allows copying elements from a range to the end: <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] Final commenting period (FCP) [x] yet.
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.
Change:
closed: AtomicBool, } <del> unsafe impl Send for AcceptorInner {} </del> unsafe impl Sync for AcceptorInner {} impl TcpAcceptor {

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
use rustc_graphviz as dot; use rustc_hir::def_id::DefId; use rustc_middle::mir::*; <del> use rustc_middle::ty::TyCtxt; </del> <ins> use rustc_middle::ty::{self, TyCtxt}; </ins> use std::fmt::Debug; use std::io::{self, Write};

Discussion:
The working example in builds fine, but if I add it panics. Repro: It builds fine: Panics with : <details<summaryBacktrace</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the panic was by you. Could you say a few words on what the issue here? I'd be happy to investigate further and fix, but I have no idea where to start.
That's an oversight by me. In you instead need to do something similar to mir printing. That is, use instead of , but also create a second dump for by additionally using to show the graph of the ctfe version of the const fn
is somewhat related, as we should probably first fix that one and then deduplicate the mir selection logic between cfg printing and regular mir dumps.
has a smaller repro.
claim
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. // aux-build:empty-struct.rs extern crate empty_struct; fn main() { let empty_struct::XEmpty2 = (); //~ ERROR mismatched types let empty_struct::XEmpty6(..) = (); //~ ERROR mismatched types } </ins>

Discussion:
I was trying an pattern match for a nullary constructor like this: but the compiler choked on the pattern match in an unexpected way. The fact that it's qualified does not seem to matter. See minimal repro below. I tried this code: I expected to see this happen: An plain, ordinary, not-scary type error. Instead, this happened: : Backtrace:
Works fine on 1.11.
Affects beta as well. Requires the type on the lhs to come from an extern crate. This is fixed on ( still fails, ) I suspect this was fixed by (although I may be wrong).
Originally introduced between and () The most likely cause is , I think.
cc
This happens when gets struct constructor as an argument (as opposed to of the struct itself) + it's the first time this struct is decoded. doesn't fix this issue, only masks it, it still can be reproduced with tuple struct patterns. How to fix this: add something like this at the beginning of : I have no idea how and can be implemented, need to investigate how new metadata works.
Fix for beta is in
Nice job
Change:
E: 'a + OpaqueEncoder, { fn encode(&self, s: &mut CacheEncoder<'a, 'tcx, E>) -> Result<(), E::Error> { <del> if *self == DUMMY_SP { </del> <ins> let span_data = self.data(); if self.is_dummy() { </ins> TAG_PARTIAL_SPAN.encode(s)?; <del> return SyntaxContext::root().encode(s); </del> <ins> return span_data.ctxt.encode(s); </ins> } <del> let span_data = self.data(); </del> let pos = s.source_map.byte_pos_to_line_and_col(span_data.lo); let partial_span = match &pos { Some((file_lo, _, _)) => !file_lo.contains(span_data.hi),

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. --The code is my entire project, unfortunately. The ICE appears to be related to incremental compilation, so I'm not sure how to minimise it. (There was a large section here which is irrelevant now I have "steps to reproduce" and a repro on current nightly.) <!-- 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
modify labels +A-incr-comp +E-needs-mcve
Neither nor commit exists when I clone that repository.
Err, sorry. Not sure what happened there. Maybe I deleted the remote branch by mistake somehow. I have the commit locally so I have pushed it again. In case of other confusion I also retried my "steps to repro" and it still goes wrong as I described. Also I noticed that the commitids there have a spurious "ESC" at the end (!), the result of a git+less misbehaviour. I have deleted those from the summary above.
This will be fixed by
Change:
} var a = document.createElement('a'); <del> a.textContent = '⇱'; </del> a.setAttribute('class', 'test-arrow'); <ins> a.textContent = 'Run'; </ins> var code = el.previousElementSibling.textContent;

Discussion:
The linkable icon is difficult to . I'm playing with this currently. I'm toying with trying to change the icon from unicode into a svg because unicode has a weird box border shape that doesn't allow the icon to scale to the full box size. I'll put up a PR if I get it working. !
Change:
use rustc_middle::ty::adjustment::{AllowTwoPhase, AutoBorrow, AutoBorrowMutability}; use rustc_middle::ty::fold::TypeFoldable; use rustc_middle::ty::{ <del> self, GenericArgs, GenericArgsRef, GenericParamDefKind, Ty, TyCtxt, UserArgs, UserType, </del> <ins> self, GenericArgs, GenericArgsRef, GenericParamDefKind, Ty, TyCtxt, TypeVisitableExt, UserArgs, UserType, </ins> }; use rustc_middle::{bug, span_bug}; use rustc_span::{Span, DUMMY_SP};

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc
Change:
<ins> // run-pass trait EnumSetType { type Repr; } enum Enum8 { } impl EnumSetType for Enum8 { type Repr = u8; } #[derive(PartialEq, Eq)] struct EnumSet<T: EnumSetType> { __enumset_underlying: T::Repr, } const CONST_SET: EnumSet<Enum8> = EnumSet { __enumset_underlying: 3 }; fn main() { match CONST_SET { CONST_SET => { /* ok */ } _ => panic!("match fell through?"), } } </ins>

Discussion:
One of the tests in my enumset crate has started throwing an ICE on the latest nightly. The problem seems to be that I use an associated type as a field in a struct I'm structurally matching, and this has been broken on the latest nightly. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
cc looks like it's likely EDIT: oh 's type is fully concrete, so the field type () could be normalized and then it would be structurally matcheable. This is a reason why using a trait might be better, it wouldn't have edge cases like this (although it has other complications). At the very least we should normalize.
I also believe we are forgetting to normalize here, will look into it. claim
points a regression in which may confirm that is the culprit.
Assigning .
Change:
//~^ ERROR mismatched types } <del> fn qux(a: Option<u32>, b: Option<u32>) -> bool { if let Some(x) = a { true } else { false } && //~ ERROR expected expression if let Some(y) = a { true } else { false } } </del> fn moo(x: u32) -> bool { match x { _ => 1,

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
true } Node::MacroDef(def) if !glob => { <del> om.macros.push(self.visit_local_macro(def, renamed.map(|i| i.name))); </del> <ins> om.macros.push((def, renamed)); </ins> true } _ => false,

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
| LL | fn check_bound<T:Copy>(_: T) {} |                  ^^^^ required by this bound in `check_bound` <ins> help: consider removing this method call, as the receiver has type `&'static str` and `&'static str: Copy` trivially holds | LL -     check_bound("nocopy".to_string()); LL +     check_bound("nocopy"); | </ins> error: aborting due to 1 previous error

Discussion:
When calling in a fn that expects we currently emit: We should check whether and suggest the removal of the call. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
feel free to reach out either on this ticket or on a PR, but be warned that this has the potential to be quite involved. It is a great introduction to how some parts of fit together though.
I've been looking into this for a while now, and my idea was to: Check if there a .into() call, check if the type of self was T and finally check if the argument of the function was Into<T. However I cannot figure how to get the type of Self. As far as my understanding goes, rustc hasn't yet inferred the type.
You can query the in-progress type table with the for the expression. You're gonna have an with a . From the first argument in that variant you can take the first element and get the expression for in . Then you can use the for that expression to do I do not know if we will have populated 's type by then, but if we have, then that will give you the type of . Then, if you're in an you can use to see if the inferred type for can be coerced to in the original example. I know this is a bit vague, but for this is inherently exploratory work :)
Hi, are you still working on this issue
No, feel free to claim it if you want
release-assignment
Change:
let cmd = match subcommand.as_str() { "build" | "b" => Subcommand::Build { paths }, "check" | "c" => { <del> Subcommand::Check { paths, all_targets: matches.opt_present("all-targets") } </del> <ins> if matches.opt_present("all-targets") { eprintln!( "Warning: --all-targets is now on by default and does not need to be passed explicitly." ); } Subcommand::Check { paths } </ins> } "clippy" => Subcommand::Clippy { paths, fix: matches.opt_present("fix") }, "fix" => Subcommand::Fix { paths },

Discussion:
It's possible to have errors in files such as: and , and have pass. I would expect to be equivalent of and check every file that CI checks. Otherwise, I run , push code to a PR, and only find later that I have a typo or such.
We don't check tests by default, but you can pass --all-targets () to check tests. I believe this is consistent with cargo check behavior? One reason we don't check tests by default is that causes duplicate error messages for the 'base' crate typically which are annoying (and most changes don't actually need them). If Cargo handled that and didn't show duplicate messages, I imagine we could change the default as well.
Oh, you're right. So my mistake was assuming that is more thorough than it is (my text editor invokes it for me, even for tests, so I didn't realize the command doesn't do everything itself).
Just FYI, 1.55 now deduplicates messages.
Oh, great news -- in that case I'm going to go ahead and reopen this as it seems likely to make sense to check tests (by default, and likely without an option to disable that). Should be a pretty simple adjustment to bootstrap.
Change:
'⚠' } <ins> // @has async_fn/fn.mut_args.html '//pre[@class="rust fn"]' 'pub async fn mut_args(a: usize)' pub async fn mut_args(mut a: usize) {} // @has async_fn/fn.mut_ref.html '//pre[@class="rust fn"]' 'pub async fn mut_ref(x: i32)' pub async fn mut_ref(ref mut x: i32) {} </ins> trait Bar {} impl Bar for () {}

Discussion:
<img width="1016" alt="rustdoc output screenshot" src="https://user-"This example was tested on Rust 1.46.0, but it has been broken for quite a while. For example, see ).
Relevant code: Not sure what's going wrong.
Thanks for the helpful hint, However, I'm not convinced this is the root cause because it's happening to all mutable by-value function arguments, not just to functions with as the first argument. For example, this free function emits similar results: <img width="1004" alt="Screen Shot 2020-09-15 at 9 56 26 AM" src="https://user-"I think the actual root cause may be deeper than the interpretation of types, but I can't tell for sure.
This example confirms that the behavior appears to be per-argument instead of per-function. It's not like one bad argument ruins the formatting of the entire function. <img width="983" alt="Screen Shot 2020-09-15 at 10 04 39 AM" src="https://user-"Perhaps we could investigate where in the code the text is being generated and work our way backwards to see what is triggering it?
Hmm, the only relevant location I could find through GitHub search is in in : Is operating on a desugared form of the AST? I don't think this is the case, since is being successfully displayed here. Is there something else I'm missing?
Here's the issue: Looks like it should use  instead. Are you interested in making a PR? ;)
Yes, rustdoc works on a desugared version and has to reconstruct the by hand.
Sure, I will prepare one right away. Thanks for investigating with me.
Change:
// ok const X: FakeNeedsDrop = { let x = FakeNeedsDrop; x }; <ins> // ok (used to incorrectly error, see #62273) const X2: FakeNeedsDrop = { let x; x = FakeNeedsDrop; x }; </ins> // error const Y: FakeNeedsDrop = { let mut x = FakeNeedsDrop; x = FakeNeedsDrop; x }; <del> //~^ ERROR constant contains unimplemented expression type </del> <ins> //~^ ERROR destructors cannot be evaluated at compile-time // error const Y2: FakeNeedsDrop = { let mut x; x = FakeNeedsDrop; x = FakeNeedsDrop; x }; //~^ ERROR destructors cannot be evaluated at compile-time </ins> // error const Z: () = { let mut x = None; x = Some(FakeNeedsDrop); }; <del> //~^ ERROR constant contains unimplemented expression type </del> <ins> //~^ ERROR destructors cannot be evaluated at compile-time // error const Z2: () = { let mut x; x = None; x = Some(FakeNeedsDrop); }; //~^ ERROR destructors cannot be evaluated at compile-time </ins>

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
<del> Subproject commit 07f1736390e1d4dd88cf9fae4ab7737ee5e086b7 </del> <ins> Subproject commit b91ae16eb1ab03b996de5ffc44db054244c1d2f6 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.