jiebi/CodeConvo huggingface dataset:
Change:
assert-css: ("#method.must_use", {"color": "rgb(0, 0, 0)", "background-color": "rgb(253, 255, 211)"}, ALL) goto: file://|DOC_PATH|/test_docs/index.html <del> assert-css: (".section-header a", {"color": "rgb(0, 0, 0)"}, ALL) </del> <ins> assert-css: (".small-section-header a", {"color": "rgb(0, 0, 0)"}, ALL) goto: file://|DOC_PATH|/test_docs/struct.HeavilyDocumentedStruct.html assert-css: (".section-header a", {"color": "rgb(56, 115, 173)"}, ALL) </ins>

Discussion:
They used to be blue and are now black. I don't think this change was intentional, although we have been thinking about migrating more headers to be black recently. I think this regressed very recently, since I probably would have noticed it otherwise. !
I wonder if this was caused by or ? Those were both merged recently, though the second one doesn't seem like it could have changed colors. cc
This regressed in , which as one of the rules for an anchor to be styled black. The goal with that change was to make the section headings on module pages black (e.g. ). Those have . However, headings generated from Markdown in a docblock also have . I think the right short-term fix is: Section headings on module pages get , like their peers on other pages. Remove the CSS rule for to be black. It's not really clear to me why Markdown gets , and Rustdoc-generated headings get , particularly given that the Rustdoc headings are almost always bigger. Probably we should rename these to and .
Since you figured out a way to fix this regression, do you want to assign yourself and open a PR with the fix?
Will do.
Change:
<del> Subproject commit dd94c7c5a32be2ee0adeeaf9d46f26f14925797c </del> <ins> Subproject commit d88138723780d11ca2c09560111223dc20b9d5f3 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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 prioritization.
triage: P-medium. Unnominating.
Change:
RustType.STD_REF_CELL: STD_REF_CELL_REGEX, RustType.STD_CELL: STD_CELL_REGEX, RustType.STD_NONZERO_NUMBER: STD_NONZERO_NUMBER_REGEX, <ins> RustType.STD_PATHBUF: STD_PATHBUF_REGEX, RustType.STD_PATH: STD_PATH_REGEX, </ins> } def is_tuple_fields(fields):

Discussion:
I tried this code (as package ): Run the following, which will break at , step the next 4 lines () to define the variables, then print twice -- the first time will succeed, the second time will fail: I expected to see this happen: would work the same no matter how many times I called it, instead everything seems to be undefined after the first call. Below I show that seems to work (including multiple times), works (including multiple times), but after a single call to , neither of these works anymore: Oddly, if I break on filename / line number instead of function name, it seems to work as expected: I'm using from a git checkout from yesterday:
Realized was not a but an ; have changed to . Don't think it changes the rest, behavior still the same with .
Works just fine in gdb for me: Rust-lldb doesn't want to load for me at all, but plain lldb works fine too. For reference I'm using lldb version 14.0.6.
If only gdb worked on aarch64-darwin! But thanks for prompting me to try other OS -- I can confirm that I do not see the bug using rust-lldb on x86_64-linux, so this may be isolated to one of darwin / aarch64 / aarch64-darwin. (Still repros for me on aarch64-darwin with lldb 16.0.6.)

If is a PathBuf, printing it from lldb does not give a string representation as I would expect. If I explicitly refer to it shows "None" for the inner OsString: If I use I finally get a vec representation.
I've details in .
Visited during wg-debugging triage. We were not able to conclusively repro but we're confident this is probably still an issue. Triaging as P-medium for now.
Change:
impl FromSecsError { const fn description(&self) -> &'static str { match self.kind { <del> FromSecsErrorKind::NonFinite => { "got non-finite value when converting float to duration" } </del> <ins> FromSecsErrorKind::NonFinite => "non-finite value when converting float to duration", </ins> FromSecsErrorKind::Overflow => "overflow when converting float to duration", <del> FromSecsErrorKind::Underflow => "underflow when converting float to duration", </del> <ins> FromSecsErrorKind::Negative => "negative value when converting float to duration", </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: while the current error message might still give a hint as to what could be going on, if you have genuinely large numbers passed to the function, you may go in a completely wrong path while debugging (testing the input to be within limits, rather than checking if it is negative or not). <!-- If dramatically different output is caused by small changes, consider also adding them here. Occurs in stable, beta and nightly compiler. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
for_each_exported_symbols_include_dep(tcx, crate_type, |symbol, info, cnum| { if info.level.is_below_threshold(export_threshold) || info.used { symbols.push(( <del> symbol_export::symbol_name_for_instance_in_crate(tcx, symbol, cnum), </del> <ins> symbol_export::linking_symbol_name_for_instance_in_crate(tcx, symbol, cnum), </ins> info.kind, )); }

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:
for_each_exported_symbols_include_dep(tcx, crate_type, |symbol, info, cnum| { if info.level.is_below_threshold(export_threshold) || info.used { symbols.push(( <del> symbol_export::symbol_name_for_instance_in_crate(tcx, symbol, cnum), </del> <ins> symbol_export::linking_symbol_name_for_instance_in_crate(tcx, symbol, cnum), </ins> info.kind, )); }

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> struct MyArray<const COUNT: usize>([u8; COUNT + 1]); //~^ ERROR generic parameters may not be used in const operations fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
According to Godbolt, this regressed in 1.39.0. Adding removes the ICE on latest nightly, which I think means this will be fixed by stabilization in . cc
Note that it doesn't ICE on the latest nightly (2020-12-25) with , but it still errors out because it's not supported under .
This is indeed fixed on master. I'll file a PR to add a regression test for this.
Change:
<ins> // check-pass // Regression test for an ICE: https://github.com/rust-lang/rust/issues/119916 #![feature(impl_trait_in_assoc_type)] #![feature(type_alias_impl_trait)] // `impl_trait_in_assoc_type` example from the bug report. pub trait StreamConsumer { type BarrierStream; fn execute() -> Self::BarrierStream; } pub struct DispatchExecutor; impl StreamConsumer for DispatchExecutor { type BarrierStream = impl Sized; fn execute() -> Self::BarrierStream { || -> _ {} } } // Functions that constrain TAITs can contain closures with an `_` in the return type. type Foo = impl Sized; fn foo() -> Foo { || -> _ {} } // The `_` in the closure return type can also be the TAIT itself. type Bar = impl Sized; fn bar() -> impl FnOnce() -> Bar { || -> _ {} } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- (not minimized yet) searched nightlies: from nightly-2024-01-11 to nightly-2024-01-13 regressed nightly: nightly-2024-01-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
label -E-needs-mcve +S-has-mcve +F-impltraitinassoctype +requires-nightly
Change:
<ins> error[E0599]: no method named `bar` found for type `Foo` in the current scope --> $DIR/issue-64430.rs:7:9 | LL | pub struct Foo; | --------------- method `bar` not found for this ... LL |     Foo.bar() |         ^^^ method not found in `Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
match self.maybe_resolve_path(&segments, Some(ns), &parent_scope, None) { PathResult::Module(ModuleOrUniformRoot::Module(module)) => Some(module.res().unwrap()), <del> PathResult::NonModule(path_res) => path_res.full_res(), </del> <ins> PathResult::NonModule(path_res) => { path_res.full_res().filter(|res| !matches!(res, Res::Def(DefKind::Ctor(..), _))) } </ins> PathResult::Module(ModuleOrUniformRoot::ExternPrelude) | PathResult::Failed { .. } => { None }

Discussion:
I'm probably planning on working on this, I found it while I was working on . The issue is that rustdoc looks up in the value namespace, which returns a Ctor, not a Variant. Turns out giving doc comments unimpeded access to the rustc resolver might not be a perfect idea This seems slightly (but not very) tricky to fix, mainly an ironing out of semantics - do we pretend that in the value namespace doesn't exist? Or do we let you reference it, but taking care not to say that there's a conflict between (the constructor) and (the variant) and that you have to disambiguate 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. --(current master): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
i'm not sure why we would want this - you can't document the constructor separately from the variant, so i would expect rustdoc to hide it from intra-doc links
(or alternatively we could make an alias for )
First of all, I can reproduce this problem with a unit-like struct. Second of all, This is an observable fact. To see it, use glob exports. Most crates probably won't do this... but most crates probably won't need disambiguators at all. These things are in the value namespace, and that's a fact that can be observed in the surface language, so we probably shouldn't pretend otherwise.
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. #![feature(mmx_target_feature)] #[inline] #[target_feature(enable = "mmx")] pub unsafe fn foo() {} </ins>

Discussion:
Given this code: it compiles as: How odd!
Not technically a regression but this needs to be fixed before 1.27 hits stable, so tagging as a nightly regression

Given: and you'll see: But that's not right! Only the original crate should need this directive, and it indeed has such a directive.
Change:
<ins> error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`) --> $DIR/issue-43037.rs:17:6 | LL | impl<T> From<<A<T> as Z>::Assoc> for T {} |      ^ type parameter `T` must be used as the type parameter for some local type | = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local = note: only traits defined in the current crate can be implemented for a type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0210`. </ins>

Discussion:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable
Change:
const UNC_PREFIX: &[u16] = &[SEP, SEP, QUERY, SEP, U, N, C, SEP]; let mut path = to_u16s(path)?; <del> if path.starts_with(VERBATIM_PREFIX) || path.starts_with(NT_PREFIX) { // Early return for paths that are already verbatim. </del> <ins> if path.starts_with(VERBATIM_PREFIX) || path.starts_with(NT_PREFIX) || path == &[0] { // Early return for paths that are already verbatim or empty. </ins> return Ok(path); } else if path.len() < LEGACY_MAX_PATH { // Early return if an absolute path is less < 260 UTF-16 code units.

Discussion:
I tried this code: I expected to see this happen: returns os error 3 () Instead, this happened: it returns os error 123 () This is problematic as doesn't become but , which isn't useful for most users. Other platforms like Linux return so the former behavior should be correct here. : The issue doesn't happen on , I think the regression was introduced by .
Thanks for finding and fixing that! I do think that should be mapped to an . It means "The filename, directory name, or volume label syntax is incorrect". So a syntax error basically. But I don't think that should block your current PR.
Sounds good, maybe it should be ? (EDIT: Opened )
is it intentional that E-medium is instead of P-medium?
Oh oops.
Change:
<ins> #![deny(improper_ctypes_definitions)] extern "C" fn foo<T: ?Sized + 'static>() -> Option<&'static T> { //~^ ERROR `extern` fn uses type `Option<&T>`, which is not FFI-safe None } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
build-pass -ice in nightly-2020-07-31 commit[0] 2020-07-29: Auto merge of - richkadel:llvm-coverage-map-gen-5, r=tmandry commit[1] 2020-07-29: Auto merge of - P1n3appl3:rustdoc-formats, r=tmandry commit[2] 2020-07-30: Auto merge of - Manishearth:rollup-z2vflrp, r=Manishearth commit[3] 2020-07-30: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[4] 2020-07-30: Auto merge of - oli-obk:lumberjack_disable, r=RalfJung commit[5] 2020-07-30: Auto merge of - npmccallum:naked, r=matthewjasper commit[6] 2020-07-30: Auto merge of - ecstatic-morse:const-size-align-of-val, r=oli-obk commit[7] 2020-07-30: Auto merge of - jumbatm:clashing-extern-decl, r=nagisa commit[8] 2020-07-30: Auto merge of - RalfJung:miri, r=RalfJung commit[9] 2020-07-30: Auto merge of - Manishearth:rollup-3wudwlg, r=Manishearth ERROR: no CI builds available between and
probably ?
why did you mark this as P-critical if it's a stable-to-stable regression from 2020?

Minimal:
its a regression build pass -ice which is critical according to the rustc dev guide
According to (not the dev guide, which I was confused since the dev guide doesn't really mention criteria for priority): This is a regression since like 1.47, so I don't think it necessarily needs to block a release to fix :smiley_cat:
Ah sorry that's what i meant, right guess its p high then.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> fn main() { unsafe { dealloc(ptr2, Layout::(x: !)(1, 1)); //~ ERROR: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:` //~^ ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `)` //~| while parsing this parenthesized list of type arguments starting here } } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' File: --auto-reduced (treereduce-rust): original: Version 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Ah, of course, we want to the returned by .
I will try to remedy the situation. claim
Change:
match cache.entry(hash) { Entry::Occupied(e) => *e.get(), Entry::Vacant(e) => { <ins> debug!("def_path_hash_to_def_id({:?})", hash); </ins> // Check if the `DefPathHash` corresponds to a definition in the current // crate if let Some(def_id) = self.local_def_path_hash_to_def_id.get(&hash).cloned() {

Discussion:
This seems to be an incremental error‽ We need an external crate for this to work. Haven't managed it to work in an internal mod only :/ Also this only happens with . Haven't managed to get it running with sadly extern crate (let's call it f) code Then just remove and add afterwards again (or the other way round, it doesn't matter). This script does it for you: <!-- 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<pand with RUST_BACKTRACE=full the LLVMing assert vanishes </p</details
searched nightlies: from nightly-2020-12-08 to nightly-2020-12-10 regressed nightly: nightly-2020-12-10 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: </detailscc
Assigning as discussed as part of the and removing .
I've fixed the issue locally, and I'm working on a PR.
Opened
Change:
if arg_count.correct.is_ok() && arg_count.explicit_late_bound == ExplicitLateBound::No { <del> Self::generic_arg_mismatch_err(tcx.sess, arg, kind.descr()); </del> <ins> // We're going to iterate over the parameters to sort them out, and // show that order to the user as a possible order for the parameters let mut param_types_present = defs .params .clone() .into_iter() .map(|param| { ( match param.kind { GenericParamDefKind::Lifetime => { ParamKindOrd::Lifetime } GenericParamDefKind::Type { .. } => { ParamKindOrd::Type } GenericParamDefKind::Const => { ParamKindOrd::Const } }, param, ) }) .collect::<Vec<(ParamKindOrd, GenericParamDef)>>(); param_types_present.sort_by_key(|(ord, _)| *ord); let (mut param_types_present, ordered_params): ( Vec<ParamKindOrd>, Vec<GenericParamDef>, ) = param_types_present.into_iter().unzip(); param_types_present.dedup(); Self::generic_arg_mismatch_err( tcx.sess, arg, kind.descr(), Some(&format!( "reorder the arguments: {}: `<{}>`", param_types_present .into_iter() .map(|ord| format!("{}s", ord.to_string())) .collect::<Vec<String>>() .join(", then "), ordered_params .into_iter() .filter_map(|param| { if param.name == kw::SelfUpper { None } else { Some(param.name.to_string()) } }) .collect::<Vec<String>>() .join(", ") )), ); </ins> } // We've reported the error, but we want to make sure that this

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim