jiebi/CodeConvo huggingface dataset:
Change:
match d { Equinox { warp_factor: warp_factor } => {} //~^ WARN this pattern is redundant <del> //~| HELP remove this </del> <ins> //~| HELP use shorthand field pattern </ins> } println!("{} {}", registry_no, b); }

Discussion:
Code: output: Note that in the attempted fix is incorrect syntax (it ate a colon). Edit: it probably actually isn't. Version info:
thanks for feedback :) it seems a rustfix bug, could you please file a issue there? cc
Will do. Is it intentional that suggests filing a bug in this repo (see the error message), or should that be changed?
This is the correct place to file the issue, it is a bug in . The issue is that the lint is providing a bad suggestion. Either the span needs to encompass the entire binding, or the suggested text needs to be the empty string.
Change:
use super::write_code; use expect_test::expect_file; <del> #[test] fn test_html_highlighting() { let src = include_str!("fixtures/sample.rs"); let html = { let mut out = String::new(); write_code(&mut out, src); format!("{}<pre><code>{}</code></pre>n", STYLE, out) }; expect_file!["fixtures/sample.html"].assert_eq(&html); } </del> const STYLE: &str = r#" <style> .kw { color: #8959A8; }

Discussion:
I tried to document and publish my Windows crate to github pages. Things went pretty smooth until I opened the source code view. As you can see below, a newline is appended to each line doc comment, also no line number for each line: ! Here the render page on gh-pages: Beware that it has no version control for the generated doc. But the link here may work for a limited time before github purge the cache: Also here the the CI script I used: The same code published on is normal: : x86_64-pc-windows-msvc rustc 1.48.0-nightly ( 2020-09-04) modify labels: T-rustdoc
Could be related to normalization depending on the git checkout settings of the runner.
I set before , maybe this is my misconfigure somehow.
Try adding and possibly to make those files end with the right character.
Thanks Andy, I tried as you told but still the issue remains.
Oh, I meant for the source files, you might need to reconfigure git before checking out the source (and that's likely just a workaround, this seems likely to be a bug in rustdoc's handling of in source files).
Thank you, problem is solved in . I am pretty sure this issue is a duplicate of another, but I cannot find it. You could close this issue if you see fit.
(keywords cause I keep failing to search for this: dos line endings)
This is a recent regression, it was introduced sometime between and . I suspect is related, cc
The issue is that is being marked as a doc-comment:
I guess this means is being marked as a ? I don't see why it would.
My test was wrong.
This is not actually correct - it was a blank line in the original source code. The issue is that rustdoc used to strip in newlines, but no longer does. Here's 1.47: and 1.48:
Change:
<del> Subproject commit 9c18177cd36fe07a3c251234240a9c77a4e66785 </del> <ins> Subproject commit a8b976eb350acec83280a0cd1ca3ac99faff67bc </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error[E0382]: use of moved value: `value` --> $DIR/cloning-in-async-block-121547.rs:5:9 | LL |   async fn clone_async_block(value: String) { |                              ----- move occurs because `value` has type `String`, which does not implement the `Copy` trait LL |       for _ in 0..10 { |       -------------- inside of this loop LL | /         async { LL | |             drop(value); | |                  ----- use occurs due to use in coroutine LL | | LL | |         }.await | |_________^ value moved here, in previous iteration of loop | help: consider cloning the value if the performance cost is acceptable | LL |             drop(value.clone()); |                       ++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0382`. </ins>

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
#![feature(nll)] #![feature(associated_type_bounds)] #![feature(strict_provenance)] <ins> #![feature(int_roundings)] </ins> #![recursion_limit = "256"] #![allow(rustc::potential_query_instability)]

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: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- 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 --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim
Change:
#![feature(nll)] #![feature(associated_type_bounds)] #![feature(strict_provenance)] <ins> #![feature(int_roundings)] </ins> #![recursion_limit = "256"] #![allow(rustc::potential_query_instability)]

Discussion:
I tried this code: Build with With recent nighties it fails to link: This issue does not occur with or . searched nightlies: from nightly-2022-04-24 to nightly-2022-04-28 regressed nightly: nightly-2022-04-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
cc This may potentially be reproducible with too. UPD: It does reproduce on , even on hello-world, if LLD is used as a linker instead of UPD2: needs to have one additional "feature-enabling" symbol on these targets, see in LLD sources.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Thanks for the quick fix!
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. #![allow(private_in_public)] mod foo { pub mod bar { extern crate core; } } mod baz { pub use foo::bar::core; } fn main() { baz::core::cell::Cell::new(0u32); } </ins>

Discussion:
A shows regressions related to () () I'm opening an issue to ensure that we're tracking these regressions and they're either expected (so we can close), this is a dupe (so we can close), or we can fix (and then close!) cc
Also fixed by .

A shows regressions related to () () I'm opening an issue to ensure that we're tracking these regressions and they're either expected (so we can close), this is a dupe (so we can close), or we can fix (and then close!) cc
Fixed in .

I get an ICE on an older project, when running cargo doc - when documenting glium v0.13.5 specifically - with the current nightly build. The issue seems to be the line in of that glium version The glium crate is linked in the backend::glutin_backend module. The compiler warns about PR , but at the moment it compiles fine, only generating docs doesn't work. A minimal example, that generates the same behaviour, when documenting, is: : Backtrace for minimal example:
Introduced between and ()
cc looks like this points to , any ideas here?
Hmm, that's odd -- I'll investigate.
Fixed in .
Change:
rendering_params: ImplRenderingParameters, ) { for trait_item in &t.items { <ins> // Skip over any default trait items that are impossible to call // (e.g. if it has a `Self: Sized` bound on an unsized type). if let Some(impl_def_id) = parent.item_id.as_def_id() && let Some(trait_item_def_id) = trait_item.item_id.as_def_id() && cx.tcx().is_impossible_method((impl_def_id, trait_item_def_id)) { continue; } </ins> let n = trait_item.name; if i.items.iter().any(|m| m.name == n) { continue;

Discussion:
Found in [this topic] on URLO. It shows the method on the page for . This is misleading, because you can't actually call that method, because . [this topic]: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The same issue with and . do you know how to exclude these options from hashmap? I'm still digging with it, if hashmap has this kind of issue, other data structures maybe have similar kind of issue. I think we need to check the trait bounds when generating the doc.
I expect you want to do it while — turning the rustc IR into rustdoc's own IR — or earlier. Doing it later would mean reimplementing parts of rustc's type checker using rustdoc's IR, and nobody wants to do that.
For the record I was working on this, sorry for not claiming this... Anyways, let me know if you don't get around to this, and I'll pick it back up :smile_cat: . Seems like you've claimed a few issues in the past hours so not sure which ones you've gotten started with.
I haven't started this one, released it, please go ahead. It's funny and also helpful to learn some Rust internals, I'm starting with some trivial fixes
Thank you Sorry for the mistake, and I am excited for you to get involved more in the compiler :) claim
This is a dupe of
Uh, sorry, actually not a dupe. That's impl level, this is method level. I think there were legitimate concerns with hiding whole impls in that other issue. Reopening this, andf I'll probably solve this first.
Change:
"cannot bind by-move with sub-bindings") .span_label(p.span, "binds an already bound by-move value by moving it") .emit(); <del> } else if has_guard && !cx.tcx.allow_bind_by_move_patterns_with_guards() { </del> <ins> } else if has_guard && !cx.tcx.features().bind_by_move_pattern_guards { </ins> let mut err = struct_span_err!(cx.tcx.sess, p.span, E0008, "cannot bind by-move into a pattern guard"); err.span_label(p.span, "moves value into pattern guard");

Discussion:
Current handling of this feature goes through functions and . One or both of these functions should be removed. cc
NLL triage: prioritizing as P-medium.
Change:
use serialize::json; use std::env; <del> use std::ffi::OsString; </del> <ins> use std::ffi::{OsString, OsStr}; </ins> use std::fs; use std::io::{self, Write}; use std::path::{Path, PathBuf};

Discussion:
I don't think this has been reported yet. I think better error handling in would make this go away.
Change:
<ins> warning: value assigned to `src` is never read --> $DIR/liveness-asm.rs:13:32 | LL |     asm!("/*{0}*/", inout(reg) src); |                                ^^^ | note: the lint level is defined here --> $DIR/liveness-asm.rs:8:9 | LL | #![warn(unused_assignments)] |         ^^^^^^^^^^^^^^^^^^ = help: maybe it is overwritten before being read? warning: value assigned to `src` is never read --> $DIR/liveness-asm.rs:23:39 | LL |     asm!("/*{0}*/", inout(reg) src => src); |                                       ^^^ | = help: maybe it is overwritten before being read? warning: 2 warnings emitted </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim
Change:
<ins> error[E0412]: cannot find type `PEB` in this scope --> $DIR/issue-113788.rs:5:21 | LL |     let peb: *const PEB; |                     ^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
No response No response Happens on , as well as several earlier versions. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Just needs someone to this error if the type , I think.
assign
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
claim
Hi! I have given a brief introduction of myself in the . With that said, I have potentially setup the necessary pre-requisites and compiler infrastructure in my local machine, also re confirmed by using the and other build commands which seem to work. As per the , I have the all the toolchains command executed (for [0-2]). Like any other contribution, I figured that in repo, are tagged as for new-comers, and to start, I have chosen this issue. Until now, I have found the following which I presume is targeting the output: Would be great if one could point out any points I may have missed out! A head start would be great!
claim
Change:
true } }); <del> return INTERNER.intern_path(sysroot); </del> } // Symlink the source root into the same location inside the sysroot,

Discussion:
Running doesn't include miri as part of the built rust toolchain, meaning that doesn't work cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-rustbuild
It seems like the same thing happens to rustfmt: doesn't include rustfmt as part of the built rust toolchain, meaning that doesn't work.
The same thing applies to and .
We need to call in all of these steps. I think that currently adds all libraries as well which isn't correct - someone should look into how this is done for rustdoc and do the same for the other tools. Take a look around I agree it's a bug that we don't copy these today.
claim
this seems related to
claim

This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim
Change:
let bodies = SortedMap::from_presorted_elements(bodies); // Don't hash unless necessary, because it's expensive. <del> let (opt_hash_including_bodies, attrs_hash) = if self.tcx.needs_crate_hash() { self.tcx.with_stable_hashing_context(|mut hcx| { let mut stable_hasher = StableHasher::new(); node.hash_stable(&mut hcx, &mut stable_hasher); // Bodies are stored out of line, so we need to pull them explicitly in the hash. bodies.hash_stable(&mut hcx, &mut stable_hasher); let h1 = stable_hasher.finish(); let mut stable_hasher = StableHasher::new(); attrs.hash_stable(&mut hcx, &mut stable_hasher); let h2 = stable_hasher.finish(); (Some(h1), Some(h2)) }) } else { (None, None) }; </del> <ins> let (opt_hash_including_bodies, attrs_hash) = self.tcx.hash_owner_nodes(node, &bodies, &attrs); </ins> let num_nodes = self.item_local_id_counter.as_usize(); let (nodes, parenting) = index::index_hir(self.tcx, node, &bodies, num_nodes); let nodes = hir::OwnerNodes { opt_hash_including_bodies, nodes, bodies };

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on a value'', 'thread 'rustc' panicked at 'called on a value'' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [associatedtypeforimpltraitintrait] creating the associated item corresponding to the opaque type [associatedtypesforimpltraitsinassociatedfn] creating associated items for opaque types returned by [associateditemdefids] collecting associated items or fields of [associateditems] collecting associated items of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
This will probably make a simple crash in a lot of cases :3
cc
minimal repro:
Hmm, when writing I tried to trigger the case by enabling , but it didn't ICE. I'll check what is the difference with what cargo does.
Fixed in
A workaround to this issue should be to use or which should disable incremental compilation.
run on nightly rust also  but. if you use to switch stable version rust will be run will successful
There’s also an environment variable to control incremental compilation, so you could set CARGO_INCREMENTAL=0 to do that.
I think this error should be completely fixed, otherwise it will still fail to compile in the IDE environment and the automatic build environment of GitHub Action
Sure, we were just offering a workaround to unblock people temporarily. The fix is already present on master and should be available in tomorrow’s nightly.
Oh, this is great
Change:
Some(def_mod(_)) | None => {} Some(_) => { n = Some(TypeNS); <del> is_duplicate = true; </del> <ins> duplicate_type = TypeError; </ins> } }; if child.defined_in_namespace(ValueNS) { <del> is_duplicate = true; </del> <ins> duplicate_type = ValueError; </ins> n = Some(ValueNS); } n } OverwriteDuplicates => None }; <del> if is_duplicate { </del> <ins> if (duplicate_type != NoError) { </ins> // Return an error here by looking up the namespace that // had the duplicate. let ns = ns.unwrap(); self.session.span_err(sp, fmt!("duplicate definition of %s `%s`", <del> namespace_to_str(ns), </del> <ins> namespace_error_to_str(duplicate_type), </ins> self.session.str_of(name))); { let r = child.span_for_namespace(ns); for r.iter().advance |sp| { self.session.span_note(*sp, <del> fmt!("first definition of %s %s here:", namespace_to_str(ns), </del> <ins> fmt!("first definition of %s `%s` here", namespace_error_to_str(duplicate_type), </ins> self.session.str_of(name))); } }

Discussion:
Code like Generates the error Which is wrong. is not a type, it's a module.
Change:
let mut count = 1; let args = vec!["compiler-calls".to_string(), "foo.rs".to_string()]; rustc_driver::catch_fatal_errors(|| { <del> rustc_driver::run_compiler( &args, &mut TestCalls { count: &mut count }, None, None, None, ).ok(); }).ok(); </del> <ins> rustc_driver::RunCompiler::new(&args, &mut TestCalls { count: &mut count }).run().ok(); }) .ok(); </ins> assert_eq!(count, 2); }

Discussion:
This argument list is slowly getting out of hand. Maybe we should create a builder pattern struct that doesn't require most calls to use ? Anyway, pre-existing, if you rather open an issue about it than fix it here, I'm fine with merging this PR Originally posted by in
modify labels: +A-driver +C-cleanup +T-compiler
I would like to give this a try if mentoring is available
I'll be happy to mentor, but we should wait for to get merged, because any change you do will conflict with that PR. Though you can start by basing your change on top of that PR. You will need to modify each place that is modified in that PR, so keep it bookmarked and look at it whenever you end up wondering what you may need to touch. The root change to do is to make private and add a new struct right next to it. That new struct should have a field for every parameter of the function and an inherent method () that just forwards all these fields to . You'll need a method that takes only the non- fields as parameters and creates a new instance of your builder struct with those fileds initialized and the rest set to . Then you'll need a method for each field to be able to set it. After adjusting all the callsites and everything compiles again, you should make a commit and put all follow-up changes in separate commits. As a follow up change you can make take the struct as an argument instead of all the fields individually. You can then destructure the struct in the body of to get all the fields out. There may be other things that you may notice while implementing this change that could be optimized, idk, but we can close this issue after the above changes.
Hi I was trying to get my hands on this. But since Optional fields can't be copied to runcompile, how can I pass those fields to ?. Here is code change that you suggested. I could technically replace to accept references instead of values but that will require the entire function to refactor, and I am not sure I can do that. Am I doing it wrong? What alternative I can take to get this issue fixed?
can take instead of .
Thanks just been away from rust for like 15 days and completely forgot I can do that. one more thing. was also used in miri and rls submodules.

Do I need to make a pull request there for the changes. Thanks.
Once (beta branching) is merged it is fine for miri and rls to break. Submitting a PR there is nice, but not necessary. The respective maintainers are normally the ones to fix them again.