jiebi/CodeConvo huggingface dataset:
Change:
python3 ../x.py test --stage 0 src/tools/compiletest &&  python3 ../x.py test --stage 0 core alloc std test proc_macro &&  # Build both public and internal documentation. <ins> RUSTDOCFLAGS="--document-private-items --document-hidden-items" python3 ../x.py doc --stage 0 compiler &&  </ins> RUSTDOCFLAGS="--document-private-items --document-hidden-items" python3 ../x.py doc --stage 0 library/test &&  /scripts/validate-toolstate.sh &&  /scripts/validate-error-codes.sh && 

Discussion:
Docs (and specially intra-doc-links) are easy to get wrong and rarely tested locally, causing many rollups to fail. We should check them in CI as well to catch mistakes early. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
But already runs in PR CI
cc maybe linkchecker is missing some cases?
The most recent case I've seen was this: where broken docs broke a try build while PR CI was green (that wasn't an intra doc link though but still docs)
Ah ok, this is specifically about rustdoc warnings, not broken links. That's definitely doable to do, we can shove into mingw-check :) it doesn't need to build the compiler at all, only check it.
Apparently doesn't actually build the compiler docs (or tool docs) when the flag isn't set in . I don't know if this is a bug or a feature, but we could just set the flag for CI here:
Apparently doesn't actually build the compiler docs (or tool docs) when the flag isn't set in . I don't know if this is a bug or a feature, but we could just set the flag for CI here:
Change:
[[package]] name = "env_logger" <del> version = "0.7.0" </del> <ins> version = "0.7.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "39ecdb7dd54465526f0a56d666e3b2dd5f3a218665a030b6e4ad9e70fa95d8fa" </del> <ins> checksum = "44533bbbb3bb3c1fa17d9f2e4e38bbbaf8396ba82193c4cb1b6445d711445d36" </ins> dependencies = [ "atty", "humantime",

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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
impl Stderr { pub fn new() -> io::Result<Stderr> { <del> get(c::STD_ERROR_HANDLE).map(Stderr) </del> <ins> Ok(Stderr) </ins> } pub fn write(&self, data: &[u8]) -> io::Result<usize> { <del> write(&self.0, data) </del> <ins> write(c::STD_ERROR_HANDLE, data) </ins> } pub fn flush(&self) -> io::Result<()> {

Discussion:
Over time the value of may change (e.g. see ) and we should likely reload the value over time instead of caching the return value to catch cases like this.
There's very little value in caching the result. takes 3 nanoseconds for me according to a quick bench.
Change:
if let Some(test_name) = ISSUE_NAME_REGEX.captures(testname) { // these paths are always relative to the passed `path` and always UTF8 <del> let stripped_path = file_path.strip_prefix(path).unwrap().to_str().unwrap(); if !remaining_issue_names.remove(stripped_path) { </del> <ins> let stripped_path = file_path .strip_prefix(path) .unwrap() .to_str() .unwrap() .replace(std::path::MAIN_SEPARATOR_STR, "/"); if !remaining_issue_names.remove(stripped_path.as_str()) { </ins> tidy_error!( bad, "file `tests/{stripped_path}` must begin with a descriptive name, consider `{{reason}}-issue-{issue_n}.rs`",

Discussion:
1) modify some code of 2) run =for the first ~6 seconds, tidy is being built in parallel, but for the remaining ~1 minute and 9 seconds llvm is doing some sequential work. I'm not sure what takes so long, there must be one epic cgu that it is processing or something?
I wanted to check the problem but couldn't reproduce it locally.
! :thinking:
aha lol! it boils down to , an array of ~4K static &strs which is being inlined into the code it seems. When I cut the file down to just a handful of items, compilation time reduces to 7 seconds :upsidedownface: cc I guess?
Can you check if reduces this slowness?
It does indeed.
Ah, but if people give the tests meaningful names, it will reduce the build time. :relieved:
Change:
pub use core::slice::{SplitMut, ChunksMut, Split}; #[stable(feature = "rust1", since = "1.0.0")] pub use core::slice::{SplitN, RSplitN, SplitNMut, RSplitNMut}; <ins> #[unstable(feature = "slice_bytes", issue = "27740")] #[allow(deprecated)] pub use core::slice::bytes; </ins> #[stable(feature = "rust1", since = "1.0.0")] pub use core::slice::{from_raw_parts, from_raw_parts_mut};

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
<ins> // Copyright 2018 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. // https://github.com/rust-lang/rust/issues/49208 trait Foo { fn foo(); } impl Foo for [(); 1] { fn foo() {} } fn main() { <[(); 0] as Foo>::foo() //~ ERROR E0277 } </ins>

Discussion:
After , when a trait bound fails and the trait was implemented by fixed-size arrays, the compiler will display an error like: Which is pretty unhelpful. A solution would be to evaluate these and/or to show evaluated bounds preferably.
I can't reproduce triggering an error with these messages, do you have an example? I need it for a regression test, the fix was indeed as simple
It only appears if you explicitly disambiguate the trait, like . .
are you displaying these as ? I feel that'd be a reasonable output for this.
that would be a better fallback than , but I'm currently trying to get at the actual value (though that triggers cycle errors atm when building libcore's array impls ^^)
That's better in some ways, but kinda implies that
Change:
// ignore-tidy-linelength // compile-flags:-Zprint-mono-items=lazy <del> // NB: We do not expect *any* monomorphization to be generated here. </del> #![deny(dead_code)] #![crate_type = "rlib"] <ins> //~ MONO_ITEM fn unreferenced_const_fn::foo[0] @@ unreferenced_const_fn-cgu.0[External] </ins> pub const fn foo(x: u32) -> u32 { x + 0xf00 }

Discussion:
Adding to 's definition works around the ICE. Also, the bug doesn't trigger if is an non- , so it's not just that is inlined cross-crate, but -specific behavior is also involved. cc
Still happens on the latest nightly. cc It doesn't block , but the workaround in that PR is a bit ugly.
I have a fix in
Change:
<ins> error[E0596]: cannot borrow data in an index of `Container` as mutable --> $DIR/issue-44405.rs:21:5 | LL |     container[&mut val].test(); |     ^^^^^^^^^^^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Container` error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Discussion:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.
Change:
/// to prevent modification. /// /// The `format_args!` macro will safely create an instance of this structure <del> /// and pass it to a user-supplied function. The macro validates the format /// string at compile-time so usage of the `write` and `format` functions can /// be safely performed. </del> <ins> /// and pass it to a function or closure, passed as the first argument. The /// macro validates the format string at compile-time so usage of the `write` /// and `format` functions can be safely performed. </ins> pub struct Arguments<'a> { fmt: &'a [rt::Piece<'a>], args: &'a [Argument<'a>],

Discussion:
I'm trying to upgrade code that worked in 0.10/0.11-pre (implementation of ): I've found a method that sounds like what I need, but it's undocumented: Linked Arguments documentation suggests usnig : but the usage I'd expect: fails with "format argument must be a string literal.", which left me lost. If really supports only literals as arguments then it's totally useless, but if I'm doing something wrong, then the docs/compiler don't help me figure this out.
The docs are not up to date. I think this should work for you: doesn't need to be escaped anymore, and you can use directly on the formatter. It should have been documented at but it has not quite been updated. *Updated to not ignore the return value. has a return value -- you can return it from the method.
That works, thanks! Shall I leave the issue open as a reminder to update the docs?
Errors from the formatter should be propagated upstream instead of being ignored.
yes, please leave it open, i will tag it 'docs'
I just opened a PR to remove that faulty paragraph.
The docs are up-to-date, it's just passes the created structure into a closure/function passed as the first argument. .
Change:
}); if explicit && impl_trait { <ins> let spans = seg.generic_args().args .iter() .filter_map(|arg| match arg { GenericArg::Type(_) => Some(arg.span()), _ => None }) .collect::<Vec<_>>(); </ins> let mut err = struct_span_err! { tcx.sess, <del> span, </del> <ins> spans.clone(), </ins> E0632, "cannot provide explicit generic arguments when `impl Trait` is  <del> used in argument position" </del> <ins> used in argument position" </ins> }; <ins> for span in spans { err.span_label(span, "explicit generic argument not allowed"); } </ins> err.emit(); }

Discussion:
The spans for this error should point to the generic arguments, not the entire path. See <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> error: expected expression, found `:` --> $DIR/issue-70552-ascription-in-parens-after-call.rs:2:19 | LL |     expr as fun()(:); |                   ^ expected expression error: aborting due to previous error </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
Report from : searched nightlies: from nightly-2020-01-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-08 searched commits: from to regressed commit:
is the cause. Reduced to: clarified to: clarified further to:
Change:
/// A trait to express the ability to construct an object from a raw file /// descriptor. <ins> #[cfg_attr(not(bootstrap), rustc_allowed_through_unstable_modules)] </ins> #[stable(feature = "from_raw_os", since = "1.1.0")] pub trait FromRawFd { /// Constructs a new instance of `Self` from the given raw file

Discussion:
Steps to reproduce: It's possible that this was accidentally stabilized, then feature gated later.
This seems to be caused by . I was thinking might address this, but I tried that PR and it doesn't seem to work. Maybe can confirm. cc
Looks like another case of , is stable but the module it lives in is not: Just need to add and it should work.
I'll work on this.
Using your suggested fix, I have a simple PR to address this, if you'd like to review: . I've confirmed locally that a toolchain built with this patch fixes the regression.
Change:
<ins> // Checks what happens when `public` is used instead of the correct, `pub` // run-rustfix public enum Test { //~^ ERROR expected one of `!` or `::`, found keyword `enum` //~^^ HELP write `pub` instead of `public` to make the item public A, B, } fn main() { } </ins>

Discussion:
When writing it will suggest and I think nothing should be suggested before it is validated. The statement to be suggested must be checked if it is true or not, if true it is suggested and if not it is not. The issue from: : The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oh dear, I didn't think of that while making the PR. A possible solution could be checking if the current token is for initializing an item? Like, struct/enum/macro, etc.
I wrote this solution, but I don't know if I can use it in rustc, it's currently building
I can't work on the problem unfortunately, whoever will assign it to him you can solve it this way The block
release-assignment
claim
Trying to add a method in token: And add a check: Any other better idea?
could be the keyword, as well. looks alright, ideally the repeated block could be prevented using a macro? I'm afraid that might slightly overengineer it, though.
Change:
pub use self::check_match::check_crate; pub(crate) use self::check_match::check_match; <del> use interpret::{const_val_field, const_discr}; </del> <ins> use interpret::{const_val_field, const_discr, self}; </ins> use rustc::middle::const_val::ConstVal; use rustc::mir::{Field, BorrowKind, Mutability};

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
#[no_coverage] fn assert_receiver_is_total_eq(&self) -> () { let _: ::core::cmp::AssertParamIsEq<u32>; <ins> let _: ::core::cmp::AssertParamIsEq<Option<u32>>; let _: ::core::cmp::AssertParamIsEq<Option<i32>>; </ins> } } #[automatically_derived]

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
/// # Example /// Consume a number if it's equal to 0. /// ``` <del> /// #![feature(peekable_next_if)] </del> /// let mut iter = (0..5).peekable(); /// // The first item of the iterator is 0; consume it. /// assert_eq!(iter.next_if_eq(&0), Some(0));

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
<ins> // check-pass // edition:2021 #![feature(async_fn_in_trait)] #![allow(incomplete_features)] pub trait SpiDevice { async fn transaction<F, R>(&mut self); } impl SpiDevice for () { async fn transaction<F, R>(&mut self) {} } fn main() {} </ins>

Discussion:
While working on an experimental runtime and using a couple of experimental features I found that the compiler while in resolving the async call on a trait crash badly. This is a minimal reproducible example and this is the stacktrace generated N.B: I guess this happens with any runtime? BTW also if happens only with rio the compiler should not crash, but I do not think this is related to a specific runtime, but I guess instead, the runtime triggers the resolution of the futures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-async-await +T-compiler
In the meanwhile, I will try to swim inside the codebase to catch the problem! claim
this is fixed by .
Minimized so it doesn't depend on rio:
Cool great work :)

gives happens with either rustc 1.66.0-dev () 66.0-nightly (2022-09-25 )
label +F-asyncfnin_traits
label +T-compiler +C-bug +I-ICE +requires-nightly Please use the ICE issue template for subsequent ICE issues. Thanks.
This is fixed by

I tried this code: I expected this to compile without error, since it is implementing the trait correctly. Instead, the following error was shown: It suggests replacing the code with the code I already have, which doesn't make much sense, as well as complaining that two things which appear identical are not. . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +T-compiler +requires-nightly +F-returnpositionimpltraitin_trait +D-invalid-suggestion
claim
Change:
key!(default_hidden_visibility, bool); key!(embed_bitcode, bool); key!(emit_debug_gdb_scripts, bool); <ins> key!(requires_uwtable, bool); </ins> if let Some(array) = obj.find("abi-blacklist").and_then(Json::as_array) { for name in array.iter().filter_map(|abi| abi.as_string()) {

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
This directory contains the source code of the rust project, including: - The test suite - The bootstrapping build system - Various submodules for tools, like rustdoc, rls, etc.

Discussion:
The following code: gives the following error: However, is a , so this code can be made to compile by creating a new item: We should suggest this to user when a function is being called in the array initializer. <strikeAssuming that is accepted, we could eventually suggest an inline block.</strikeOn Nightly, we could suggest an inline block. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this would make a good first issue for someone looking to get started contributing. I'd be happy to mentor anyone who wants to work on this.
claim
Is this still an issue that I can work on?
Yes, assuming that is no longer working on this.
Should I claim it?
It looks like DavidHusicka hasn't had any activity this month, so I think it would be fine for you to take the issue. Feel free to reach out to me if you have any questions about how to get started implementing this.
claim
Change:
cx.attr_nested_word(sym::cfg, sym::test, attr_sp), // #[rustc_test_marker = "test_case_sort_key"] cx.attr_name_value_str(sym::rustc_test_marker, test_path_symbol, attr_sp), <ins> // #[doc(hidden)] cx.attr_nested_word(sym::doc, sym::hidden, attr_sp), </ins> ], // const $ident: test::TestDescAndFn = ast::ItemKind::Const(

Discussion:
I tried this code: I expected to see this happen: no errors Instead, this happened: : Very likely to be related
Looks like allowed missing docs on the generated function, but didn't test having any actual s. cc
Attempt fix in
Change:
use ast::*; use syntax_pos::Span; use codemap::Spanned; <ins> use parse::token::Token; use tokenstream::{TokenTree, TokenStream}; </ins> #[derive(Copy, Clone, PartialEq, Eq)] pub enum FnKind<'a> {

Discussion:
This issue probably needs a better title, perhaps someone more familiar with the compiler's handling of macros can suggest a better one. Some kind of error message, at least. panic with exit code :
Simplified: Same ICE will happen if is changed to ///. Update: Panic happens at this line: has keys and , but the is .
Change:
_ => {} }; <del> base = self.add_move_path(base, elem, |tcx| { Place { base: place.base.clone(), projection: tcx.intern_place_elems(&place.projection[..i+1]), } }); </del> <ins> if union_path.is_none() { base = self.add_move_path(base, elem, |tcx| { Place { base: place.base.clone(), projection: tcx.intern_place_elems(&place.projection[..i+1]), } }); } </ins> } <del> Ok(base) </del> <ins> if let Some(base) = union_path { // Move out of union - always move the entire union. Err(MoveError::UnionMove { path: base }) } else { Ok(base) } </ins> } fn add_move_path(

Discussion:
The following code ICEs, when it should produce a cannot move error
Worse, the following compiles:
regression from stable-to-beta and stable-to-nightly
triage: P-high