jiebi/CodeConvo huggingface dataset:
Change:
rustc often offers a help to import something from std and core: Perhaps in such situations rustc could use an heuristic to suggest only one of the two imports.
cc feels like we should at least show first here?
This is quite useful in situations like the rust playground because there sometimes there are many different sources for a function, and sometimes the std one (that's most times the one you really want) gets elided in the "others" sources.
We already have a couple of hacks for these kind of suggestions, so I'd be fine with just modifying the code here to push any suggestion that starts with to the end of the list, or at the very least, after . As pointed above it might make sense to bias the sort to always put first. We could also consider removing all references to , but that makes me uneasy.
The regression test (), when run on the playground, does seem to have regressed between beta 1.57.0 and nightly 1.58.0, which is weird because it's a test, so it shouldn't have changed. Maybe it only regressed when there are external dependencies?

Discussion:
candidates.iter().map(|c| path_names_to_string(&c.path)).collect(); path_strings.sort(); <ins> let core_path_strings = path_strings.drain_filter(|p| p.starts_with("core::")).collect::<Vec<String>>(); path_strings.extend(core_path_strings); </ins> path_strings.dedup(); let (determiner, kind) = if candidates.len() == 1 {

#![doc(html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/")] #![feature(box_patterns)] <ins> #![feature(drain_filter)] </ins> #![feature(bool_to_option)] #![feature(crate_visibility_modifier)] #![feature(format_args_capture)]
Change:
<!-- 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
The ICE happens because the type placeholder error has been gone since 1.43.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium

Discussion:
tcx.ensure().generics_of(item.def_id); tcx.ensure().type_of(item.def_id); tcx.ensure().predicates_of(item.def_id); <del> if let hir::ForeignItemKind::Fn(..) = item.kind { tcx.ensure().fn_sig(item.def_id); </del> <ins> match item.kind { hir::ForeignItemKind::Fn(..) => tcx.ensure().fn_sig(item.def_id), hir::ForeignItemKind::Static(..) => { let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_foreign_item(item); placeholder_type_error(tcx, None, &[], visitor.0, false, None); } _ => (), </ins> } } }

<ins> // Regression test for #83621. extern "C" { static x: _; //~ ERROR: [E0121] } fn main() {} </ins>

<ins> error[E0121]: the type placeholder `_` is not allowed within types on item signatures --> $DIR/issue-83621-placeholder-static-in-extern.rs:4:15 | LL |     static x: _; |               ^ not allowed in type signatures error: aborting due to previous error For more information about this error, try `rustc --explain E0121`. </ins>
Change:
I was under the impression that should work on stable channel with version 1.51, however using the example code from I get rustc -Vv output (its the ):
attributes are used to enable unstable/gated features in the nightly compiler. Once a feature stabilizes, the attribute is no longer required.
I think the compiler should suggest removing the feature gate if it's been stabilized.
I see, I was unsure whether the error message was referring to the referred feature or the feature flag itself (since the example code of the stabilize PR was using it too I was assuming the former). And yes, removing the feature line from the example code makes it compile, thanks. Is there any way to make rustc ignore the feature flag and try to compile it anyway? The crate I want to use still has it included and I'd prefer not having to remove it manually until it gets removed upstream. (re-opening since seems to think its a valid issue/suggestion)
No, you'll need to either patch the crate or fix it upstream.

Discussion:
} fn maybe_stage_features(sess: &Session, krate: &ast::Crate) { <ins> use rustc_errors::Applicability; </ins> if !sess.opts.unstable_features.is_nightly_build() { <ins> let lang_features = &sess.features_untracked().declared_lang_features; </ins> for attr in krate.attrs.iter().filter(|attr| sess.check_name(attr, sym::feature)) { <del> struct_span_err!( </del> <ins> let mut err = struct_span_err!( </ins> sess.parse_sess.span_diagnostic, attr.span, E0554, "`#![feature]` may not be used on the {} release channel", option_env!("CFG_RELEASE_CHANNEL").unwrap_or("(unknown)") <del> ) .emit(); </del> <ins> ); let mut all_stable = true; for ident in attr.meta_item_list().into_iter().flatten().map(|nested| nested.ident()).flatten() { let name = ident.name; let stable_since = lang_features .iter() .flat_map(|&(feature, _, since)| if feature == name { since } else { None }) .next(); if let Some(since) = stable_since { err.help(&format!( "the feature `{}` has been stable since {} and no longer requires  an attribute to enable", name, since )); } else { all_stable = false; } } if all_stable { err.span_suggestion( attr.span, "remove the attribute", String::new(), Applicability::MachineApplicable, ); } err.emit(); </ins> } } }
Change:
<!-- 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 on nightly Rust: This produced a warning claiming that was stabilized in 1.51: I removed the feature gate and tried compiling the code on Rust 1.51.0: However, this led to an error claiming that is unstable: <!-- 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. --: : modify labels: +A-diagnostics +D-incorrect +F-unsafe-block-in-unsafe-fn
According to the milestone on the stabilization PR (), this feature will be stabilized in 1.52, but the PR wasn't updated to account for this.
Thanks for the report, yeah, the stabilized version should be wrong. Submitted as a fix.

Discussion:
/// The smallest useful subset of `const_generics`. (accepted, min_const_generics, "1.51.0", Some(74878), None), /// The `unsafe_op_in_unsafe_fn` lint (allowed by default): no longer treat an unsafe function as an unsafe block. <del> (accepted, unsafe_block_in_unsafe_fn, "1.51.0", Some(71668), None), </del> <ins> (accepted, unsafe_block_in_unsafe_fn, "1.52.0", Some(71668), None), </ins> /// Allows the use of or-patterns (e.g., `0 | 1`). (accepted, or_patterns, "1.53.0", Some(54883), None),
Change:
<!-- 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
From
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium

Discussion:
Some(next) => next, None => break None, }; <ins> // See issue #83753. If someone writes an associated type on a non-trait, just treat it as // there being no supertrait HRTBs. match tcx.def_kind(def_id) { DefKind::Trait | DefKind::TraitAlias | DefKind::Impl => {} _ => break None, } </ins> if trait_defines_associated_type_named(def_id) { break Some(bound_vars.into_iter().collect()); }

| Scope::Supertrait { ref s, .. } => { scope = *s; } <del> Scope::Root => bug!("In fn_like_elision without appropriate scope above"), </del> <ins> Scope::Root => { // See issue #83907. Just bail out from looking inside. self.tcx.sess.delay_span_bug( rustc_span::DUMMY_SP, "In fn_like_elision without appropriate scope above", ); return; } </ins> } }; // While not strictly necessary, we gather anon lifetimes *before* actually

<ins> // check-fail struct Foo {} impl Foo { fn bar(foo: Foo<Target = usize>) {} //~^ associated type bindings are not allowed here } fn main() {} </ins>

<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-83753-invalid-associated-type-supertrait-hrtb.rs:5:21 | LL |     fn bar(foo: Foo<Target = usize>) {} |                     ^^^^^^^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>

<ins> // check-fail static STATIC_VAR_FIVE: &One(); //~^ cannot find type //~| free static item without body fn main() {} </ins>

<ins> error: free static item without body --> $DIR/issue-83907-invalid-fn-like-path.rs:3:1 | LL | static STATIC_VAR_FIVE: &One(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^- |                               | |                               help: provide a definition for the static: `= <expr>;` error[E0412]: cannot find type `One` in this scope --> $DIR/issue-83907-invalid-fn-like-path.rs:3:26 | LL | static STATIC_VAR_FIVE: &One(); |                          ^^^ not found in this scope error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0412`. </ins>
Change:
I think it was working yesterday, but is giving a "Not Found" response for me. works fine, however.
Hm, I wonder if this is a similar bug to the one fixed due to link check failure during the bootstrap bump.
FYI, works fine—it seems to just be .
Yeah, almost certainly the bootstrap bump. cc (just a heads up, I plan to submit a patch soon, though haven't written it yet)
My guess without too much investigation is that the symlinkdirforce which intends to share the compiler-doc directory between rustdoc and rustc docs is ending up clobbered. I likely won't get around to a fix tonight but may be able to do so tomorrow, we'll see how much time I have.
I'm also happy to revert the change on beta, if you want, so there isn't a rush to fix things.
Yeah, I think we should do that - there's enough stuff broken in rustbuild that's not really of the too unusual kind (well, really just two cases, but they seem fairly typical). I'd rather we drop it from beta and either pursue resource-suffix as suggested by or at least tackle the bugs in rustbuild on a less urgent timescale before relanding. (Ideally we should figure out what people should do; rustbuild's approach to just building twice seems pretty... suboptimal; I imagine that the fix for this newly found bug will end up similar if I do it quickly).
OK, I have posted I'll push through the changes, though it may take at least a few days to get beta updated and then bump the version.
Yeah. I think I'm not sure there's as easy a fix in this case (unlike the simple add of a double core build), as the clobbering occurs over two different steps I believe. So I think we'll wait for that patch to land and bump beta. (We could also temporarily remove, say, rustdoc or rustc docs - but that doesn't seem like a real benefit).
Thanks for the speedy fix! The docs are back online now (because it's a bit after midnight UTC). I'm glad they're back :)

Discussion:
// output directory will be deleted by us (as cargo will purge the stamp // file during the first slot's run), and core is relatively fast to // build so works OK to fill this 'dummy' slot. <del> let krates = ["core", "core", "alloc", "std", "proc_macro", "test"]; </del> <ins> let krates = ["core", "alloc", "std", "proc_macro", "test"]; </ins> for krate in &krates { run_cargo_rustdoc_for(krate); }

# stable release's version number. `date` is the date where the release we're # bootstrapping off was released. <del> date: 2021-03-26 </del> <ins> date: 2021-04-07 </ins> rustc: beta # We use a nightly rustfmt to format the source because it solves some
Change:
There are bad (404) links in search results with nightly rustdoc. E.g. go to and then click the result. This leads to which does not exist. Cc
Actually, this issue seems to exist even on stable -- somehow it went unnoticed for quite a while, it seems.
I think it's because we are badly handling a reexport/type alias.
I think this is a duplicate of

Discussion:
// for where the type was defined. On the other // hand, `paths` always has the right // information if present. <del> Some(&( ref fqp, ItemType::Trait | ItemType::Struct | ItemType::Union | ItemType::Enum, )) => Some(&fqp[..fqp.len() - 1]), Some(..) => Some(&*self.cache.stack), </del> <ins> Some(&(ref fqp, _)) => Some(&fqp[..fqp.len() - 1]), </ins> None => None, }; ((Some(*last), path), true)

<ins> // ignore-order const QUERY = 'RawFd::as_raw_fd'; const EXPECTED = { 'others': [ // Reproduction test for https://github.com/rust-lang/rust/issues/78724 // Validate that type alias methods get the correct path. { 'path': 'std::os::unix::io::AsRawFd', 'name': 'as_raw_fd' }, { 'path': 'std::os::wasi::io::AsRawFd', 'name': 'as_raw_fd' }, { 'path': 'std::os::linux::process::PidFd', 'name': 'as_raw_fd' }, { 'path': 'std::os::unix::io::RawFd', 'name': 'as_raw_fd' }, ], }; </ins>

<ins> const QUERY = 'MyForeignType::my_method'; const EXPECTED = { 'others': [ // Test case for https://github.com/rust-lang/rust/pull/96887#pullrequestreview-967154358 // Validates that the parent path for a foreign type method is correct. { 'path': 'foreign_type_path::aaaaaaa::MyForeignType', 'name': 'my_method' }, ], }; </ins>

<ins> #![feature(extern_types)] pub mod aaaaaaa { extern { pub type MyForeignType; } impl MyForeignType { pub fn my_method() {} } } </ins>
Change:
At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it

Discussion:
- [You can now pass the `--features` option multiple times to enable multiple features.][cargo/7084] <ins> Rustdoc ------- - [Documentation on `pub use` statements is prepended to the documentation of the re-exported item][63048] </ins> Misc ---- - [`rustc` will now warn about some incorrect uses of

[63421]: https://github.com/rust-lang/rust/pull/63421/ [cargo/7084]: https://github.com/rust-lang/cargo/pull/7084/ [cargo/7143]: https://github.com/rust-lang/cargo/pull/7143/ <ins> [63048]: https://github.com/rust-lang/rust/pull/63048 </ins> [`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32
Change:
<!-- 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. --After testing, it's this macro here: The semicolon in the third variant causes the error when used in a context such as: Note that prior to updating I was using , which did not error. This errors on Nightly and Stable, I tested both ( and both have the same result). Removing the semicolon causes the project to build fine and function as it did before updating. : This error is repeated over and over again before the notification saying to submit the bug report <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Can you share the original repository, or provide a self-contained reproduction of the issue?
here is one I got to error in the same way: I also noticed this warning that I believe I failed to include in the original issue: If I remove the semicolon, this warning does not show up, and the program works as expected.

Discussion:
fn visit_anon_const(&mut self, c: &'a ast::AnonConst) { run_early_pass!(self, check_anon_const, c); <ins> self.check_id(c.id); </ins> ast_visit::walk_anon_const(self, c); }

<ins> // Regression test for issue #84195 // Checks that we properly fire lints that occur inside // anon consts. #![deny(semicolon_in_expressions_from_macros)] macro_rules! len { () => { 0; }; //~  ERROR trailing semicolon //~| WARN this was previously accepted } fn main() { let val: [u8; len!()] = []; } </ins>

<ins> error: trailing semicolon in macro used in expression position --> $DIR/issue-84195-lint-anon-const.rs:8:14 | LL |     () => { 0; }; |              ^ ... LL |     let val: [u8; len!()] = []; |                   ------ in this macro invocation | note: the lint level is defined here --> $DIR/issue-84195-lint-anon-const.rs:5:9 | LL | #![deny(semicolon_in_expressions_from_macros)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813> = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
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!
yes I can work on that :)
that would be great. :) However, there's some amount of urgency here as these Miri failures tend to accumulate.
I am not particularly fast. So maybe someone else should work on that if they want to.
that's okay! Sadly, these Miri breakages are not good opportunities for first-time Miri contribution. Thanks anyway. :) I'll take care of it.
as pointed by it seems simple enough I can do it now

Discussion:
<del> Subproject commit b9b2af9729243ab8d5b02cca2e19ce93cc23c1b1 </del> <ins> Subproject commit b13b79db73e3fa692fc648a8cd70f162a5eade34 </ins>
Change:
Build with overflow checking enabled: Then try compiling the following program (found by ):
The ICE is a regression, introduced in . The overflowing subtraction happens here: cc
( can also hit this when , see https://rust-)
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
This regression will unfortunately be included in 1.52.0 stable. Updating the labels.
This was discussed a bit on Zulip . I did a small amount of investigation, and found that the code that checks if "errors were generated" does not handle stashed errors correctly. It keeps a count of errors, but with stashed errors that count can go up and down at various times. In this particular case, an error is stashed and then stolen. The comment on the relevant function ("Remove this method, it should never be needed.") isn't really clear why it shouldn't be needed. In general, that error tracking logic needs to change to handle stashed errors correctly.
is a remnant from when we desired to check at the end of each stage and stop rustc from continuing. This is the easiest and safest course of action, but leads to the "waves of errors" experience. We've been moving away from that, but just removing blindly would cause a bunch of ICEs when codepaths that still assume things are well formed are exercised.

Discussion:
{ let old_count = self.err_count(); let result = f(); <del> let errors = self.err_count() - old_count; if errors == 0 { Ok(result) } else { Err(ErrorReported) } </del> <ins> if self.err_count() == old_count { Ok(result) } else { Err(ErrorReported) } </ins> } pub fn span_warn<S: Into<MultiSpan>>(&self, sp: S, msg: &str) { self.diagnostic().span_warn(sp, msg)
Change:
See below. Last nightly version that was known to work was 2021-04-19. Note that it says below but this is the version that installs as ! Similarly is the last known to work version but installed via as .
points at the following: searched nightlies: from nightly-2021-04-18 to nightly-2021-04-22 regressed nightly: nightly-2021-04-21 searched commits: from to regressed commit:
Because it was a small change, I have a guess about what I may need to check, but it would help to have an MCVE. I can't tell what code you're compiling that caused this. Can you provide a small example I can build locally? Thanks! cc:
By the way, where is the source for ? It looks like it is gone from github. I tried building , on the off chance that it might cause the same ICE with , but it built without issues.
We're having the same issue, if this helps: I'll see if I can get a minimal example
I don't have a minimal example, had no time to dig through the code yet to understand the problem. But you can easily reproduce it via
Ah! Thanks for providing the link to the source. I wasn't sure how to get it without access to the repo. Yes I can reproduce this. Looking into it now. Thanks!

Discussion:
let body_span = hir_body.value.span; let source_file = source_map.lookup_source_file(body_span.lo()); let fn_sig_span = match some_fn_sig.filter(|fn_sig| { <del> Lrc::ptr_eq(&source_file, &source_map.lookup_source_file(fn_sig.span.hi())) </del> <ins> fn_sig.span.ctxt() == body_span.ctxt() && Lrc::ptr_eq(&source_file, &source_map.lookup_source_file(fn_sig.span.hi())) </ins> }) { Some(fn_sig) => fn_sig.span.with_hi(body_span.lo()), None => body_span.shrink_to_lo(),

/// to be). pub(super) fn generate_coverage_spans( mir_body: &'a mir::Body<'tcx>, <del> fn_sig_span: Span, </del> <ins> fn_sig_span: Span, // Ensured to be same SourceFile and SyntaxContext as `body_span` </ins> body_span: Span, basic_coverage_blocks: &'a CoverageGraph, ) -> Vec<CoverageSpan> { let mut coverage_spans = CoverageSpans { mir_body, <del> fn_sig_span: fn_sig_source_span(fn_sig_span, body_span), </del> <ins> fn_sig_span, </ins> body_span, basic_coverage_blocks, sorted_spans_iter: None,

} #[inline] <del> fn fn_sig_source_span(fn_sig_span: Span, body_span: Span) -> Span { original_sp(fn_sig_span, body_span).with_ctxt(body_span.ctxt()) } #[inline] </del> fn function_source_span(span: Span, body_span: Span) -> Span { let span = original_sp(span, body_span).with_ctxt(body_span.ctxt()); if body_span.contains(span) { span } else { body_span }