jiebi/CodeConvo huggingface dataset:
Change:
// If there is only one implementation of the trait, suggest using it. // Otherwise, use a placeholder comment for the implementation. let (message, impl_suggestion) = if non_blanket_impl_count == 1 {( <del> "use the fully-qualified path to the only available implementation".to_string(), </del> <ins> "use the fully-qualified path to the only available implementation", </ins> format!("<{} as ", self.tcx.type_of(impl_def_id).instantiate_identity()) <del> )} else {( format!( "use a fully-qualified path to a specific available implementation ({} found)", non_blanket_impl_count ), "</* self type */ as ".to_string() </del> <ins> )} else { ("use a fully-qualified path to a specific available implementation", "</* self type */ as ".to_string() </ins> )}; let mut suggestions = vec![( path.span.shrink_to_lo(),

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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:
Change:
<ins> // Regression test for issue #97299, one command line library with modifiers // overrides another command line library with modifiers. // compile-flags:-lstatic:+whole-archive=foo -lstatic:+whole-archive=foo // error-pattern: overriding linking modifiers from command line is not supported 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. --There is no code. The internal compiler error happens when building rustc itself (on MSYS2/Mingw) <!-- 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. --We are trying to build Rust 1.61.0. The error happens when building while processing the libs passed on the command line. The issue concerns native library modifiers and was most probably introduced by The line that triggers the panic is here: The code change in question broke the handling of (i.e. no bundle) which is used when building on mingw. See here for an example: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Note that we have on the rustc command line. So we have the same lib twice and one has modifiers which triggers the error. It should actually trigger an error but panics before...
Yes, the ICE is caused by used to determine the span for the error. There's a PR in progress that fixes that - Even without ICE you'll need a workaround for the error that it's masking - linking the library with modifiers either only from command line, or only from attributes. will relax these restrictions as well.
The ICE is a regression from
Fixed in
Change:
name = "rustc_driver" version = "0.0.0" dependencies = [ <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "graphviz", "lazy_static 1.3.0", "log",

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:
<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. // revisions: lxl nll //[lxl]compile-flags: -Z borrowck=mir -Z two-phase-borrows //[nll]compile-flags: -Z borrowck=mir -Z two-phase-borrows -Z nll // run-pass use std::io::Result; struct Foo {} pub trait FakeRead { fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize>; } impl FakeRead for Foo { fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { Ok(4) } } fn main() { let mut a = Foo {}; let mut v = Vec::new(); a.read_to_end(&mut v); } </ins>

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
Origin::Mir, ), <del> (_, _, _, BorrowKind::Unique, _, _) => self.tcx </del> <ins> (BorrowKind::Shared, lft, _, BorrowKind::Unique, _, _) => self.tcx </ins> .cannot_reborrow_already_uniquely_borrowed( span, &desc_place, <del> "it", </del> "", <ins> lft, issued_span, "", end_issued_loan_span, Origin::Mir, ), (BorrowKind::Mut, _, lft, BorrowKind::Unique, _, _) => self.tcx .cannot_reborrow_already_uniquely_borrowed( span, &desc_place, "", lft, </ins> issued_span, "", end_issued_loan_span,

Discussion:
When compiling the test E0501, I get the following result: The message "cannot borrow it as because previous closure requires unique access" looks wrong - I think the arguments to got mixed up a bit.
I am working on this.
Change:
} } } <ins> fn check_item(&mut self, cx: &EarlyContext<'_>, item: &ast::Item) { use ast::ItemKind::*; if let Const(.., ref expr) | Static(.., ref expr) = item.kind { self.check_unused_parens_expr(cx, expr, "assigned value", false, None, None); } } </ins> } declare_lint! {

Discussion:
It doesn't give a warning for the unnecessary parentheses for N1: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
implemented for to check the .
claim
I've encountered an issue I'm not quite sure how to handle :( After getting what looks like a correct solution up with: I am met with the following after starting to build stage-1: Should I open a separate Issue & PR to deal with any errors generated by unused parens or is it within the scope of this issue (and PR coming soon once I write the UI tests) to deal with them?
should be fixed within this issue, and don' forget to add a testcase named into , then , git add the new and updated if any.
I resolved the issue with the submodule, is it alright if I claim this? It's a small patch to land. claim
Change:
hir::Unsafety::Unsafe }, abi, <del> constness: hir::Constness::NotConst, </del> <ins> constness: if abi == Abi::RustIntrinsic && tcx.is_const_fn(def_id) && is_unstable_const_fn(tcx, def_id).is_none() { hir::Constness::Const } else { hir::Constness::NotConst }, </ins> asyncness: hir::IsAsync::NotAsync, } }

Discussion:
and are both listed as const in 1.56 according to the "since" info on the right, but only the version lists in the actual signature. core: std:
I took this screenshot in : ! So it's fixed. Closing then.
I don't think this has been fixed yet. (note that this issue is about , not ) <img width="1009" alt="core" src="https://user-"
Oh you're right. Re-opening.
Change:
/// Parses a local variable declaration. fn parse_local(&mut self, attrs: AttrVec) -> PResult<'a, P<Local>> { let lo = self.prev_token.span; <ins> if self.token.is_keyword(kw::Const) && self.look_ahead(1, |t| t.is_ident()) { self.struct_span_err( lo.to(self.token.span), "`const` and `let` are mutually exclusive", ) .span_suggestion( lo.to(self.token.span), "remove `let`", "const", Applicability::MaybeIncorrect, ) .emit(); self.bump(); } </ins> let (pat, colon) = self.parse_pat_before_ty(None, RecoverComma::Yes, "`let` bindings")?; let (err, ty) = if colon {

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 inform the user that and are mutually exclusive and suggest the user remove the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
destination: Option<(ReturnDest<'tcx, Bx::Value>, mir::BasicBlock)>, cleanup: Option<mir::BasicBlock>, ) { <del> if let Some(cleanup) = cleanup { </del> <ins> // If there is a cleanup block and the function we're calling can unwind, then // do an invoke, otherwise do a call. if let Some(cleanup) = cleanup.filter(|_| fn_abi.can_unwind) { </ins> let ret_bx = if let Some((_, target)) = destination { fx.blocks[target] } else {

Discussion:
I guess intrinsics need to be ed and not d? Maybe the MIR inliner is inlining the intrinsic's wrapper, but keeps the target intact when it shouldn't. Or this should be handled in codegen, not sure.
The implementation ends up calling pause intrinsic declared as follows: The rustc codegen is completely unaware that it is dealing with an intrinsic, it just changes the symbol name. Looks like the whole feature was introduced by accident, and feature gate was introduced after the fact to make it unstable.
Change:
let target = match body[bb].terminator().kind { TerminatorKind::Goto { target } | TerminatorKind::Drop { target, .. } | <ins> TerminatorKind::DropAndReplace { target, .. } | </ins> TerminatorKind::Assert { target, .. } | TerminatorKind::Call { destination: Some((_, target)), .. } => { Some(target)

Discussion:
In the following example, and are allowed but isn't: The reason is that is lowered to in MIR, and that's not handled in const-checking as a and an assignment (which it functionally is). EDIT: nevermind, promotion works based on temporaries, so it shouldn't be affected. cc
I'm going to label this as a bug since it seems covered by from a T-Lang perspective.
Change:
<ins> // edition:2018 trait MyTrait { async fn resolved(&self); const RESOLVED_WRONG: u8 = 0; } impl MyTrait for i32 { async fn resolved(&self) {} async fn unresolved(&self) {} //~ ERROR method `unresolved` is not a member of trait `MyTrait` async fn RESOLVED_WRONG() {} //~ ERROR doesn't match its trait `MyTrait` } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [visibility] computing visibility of [effectivevisibilities] checking effective visibilities [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Fixed in
Change:
} impl<'a, 'b> Visitor<'b> for BuildReducedGraphVisitor<'a, 'b> { <del> method!(visit_impl_item: ast::ImplItem, ast::ImplItemKind::Macro, walk_impl_item); </del> method!(visit_expr:      ast::Expr,     ast::ExprKind::Mac,       walk_expr); method!(visit_pat:       ast::Pat,      ast::PatKind::Mac,        walk_pat); method!(visit_ty:        ast::Ty,       ast::TyKind::Mac,         walk_ty);

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
} if self.config.bless { <del> cmd.env("RUSTC_BLESS_TEST", "--bless"); // Assume this option is active if the environment variable is "defined", with _any_ value. // As an example, a `Makefile` can use this option by: </del> <ins> // If we're running in `--bless` mode, set an environment variable to tell // `run_make_support` to bless snapshot files instead of checking them. </ins> // <del> //   ifdef RUSTC_BLESS_TEST //       cp "$(TMPDIR)"/actual_something.ext expected_something.ext //   else //       $(DIFF) expected_something.ext "$(TMPDIR)"/actual_something.ext //   endif </del> <ins> // The value is this test's source directory, because the support code // will need that path in order to bless the _original_ snapshot files, // not the copies in `rmake_out`. // (See <https://github.com/rust-lang/rust/issues/129038>.) cmd.env("RUSTC_BLESS_TEST", &self.testpaths.file); </ins> } if self.config.target.contains("msvc") && !self.config.cc.is_empty() {

Discussion:
While working on , I noticed that running an test with appears to succeed, but doesn't actually update the snapshot file(s). This seems to be a side-effect of . The test does successfully bless the temporary copy of the snapshot file in , but that has no effect on the original snapshot file in .
cc label +A-run-make T-bootstrap
Change:
error[E0658]: use of unstable library feature 'function' <del> --> $DIR/internal-unstable.rs:33:25 </del> <ins> --> $DIR/internal-unstable.rs:34:25 </ins> | LL |     pass_through_allow!(internal_unstable::unstable()); |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Discussed in zulip: https://rust- The problem is that compiler doesn't accept code like this: But it accepts code when merging mutiple annotations into one: : Version 1.48.0-nightly ( 2020-09-22) cc which modified some const stability checks. modify labels: E-mentor
Error: Label P-low can only be set by Rust team members Please let know if you're having trouble with this bot.
just refactored a few individual calls to into a single helper function. only looks for the first attribute it seems. Shouldn't be hard to fix.
assign
Error: Parsing assign command in failed: ...'n bugadani' ''... Please let know if you're having trouble with this bot.
The PR did not actually fix the issue. The test case to the PR also works without the PR. A test case that would fail would actually check whether a second attribute would be honored. Adding a second attribute was silently ignored, and it still is after the PR. Edit: nevermind, all is good:
It doesn't hurt to double check, just takes some time :)
Change:
fn visit_anon_const(&mut self, constant: &'ast AnonConst) { // We deal with repeat expressions explicitly in `resolve_expr`. self.with_lifetime_rib(LifetimeRibKind::AnonConst, |this| { <del> this.with_lifetime_rib(LifetimeRibKind::Elided(LifetimeRes::Static), |this| { </del> <ins> this.with_lifetime_rib(LifetimeRibKind::Elided(LifetimeRes::Infer), |this| { </ins> this.resolve_anon_const(constant, IsRepeatExpr::No); }) })

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: It compile Instead, this happened: It errored <!-- 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. --: </p</details
this is also present with repeat exprs:
cc and
const generic defaults also are buggy around
Change:
} } <del> #[unstable(feature = "rustc_private", issue = "0")] #[rustc_deprecated(since = "1.0.0", reason = "Replaced with `expander().fold_expr()`")] pub fn expand_expr(&mut self, e: P<ast::Expr>) -> P<ast::Expr> { self.expander().fold_expr(e) } </del> /// Returns a `Folder` for deeply expanding all macros in an AST node. pub fn expander<'b>(&'b mut self) -> expand::MacroExpander<'b, 'a> { expand::MacroExpander::new(self)

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
placeholder="Click or press ‘S’ to search, ‘?’ for more options…"  type="search"> </div> <del> <button class="help-button">?</button> </del> <ins> <button type="button" class="help-button">?</button> </ins> <a id="settings-menu" href="{root_path}settings.html"> <img src="{static_root_path}wheel{suffix}.svg"  width="18" 

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. --In current Rust nightly, the std docs search function does a very annoying thing for me: every time I open a new tab onto the rust std docs, I get once again the popup with the keybindings which I then have to dismiss. I conjecture that this is because I am looking at locally built docs via a URL. Presumably the same thing would occur for a user who has sensibly disabled cookies in their web browser, resulting in the same horrible "stupid popup" user experience. Given that without web local storage it is not possible to make a thing that is shown to each user once, it would be better not to show this popup at all when local storage is not available. I'm not sure if it is possible to determine easily whether local storage is available. I think there may be browsers which silently discard local storage writes rather than explicitly saying it's not available. Until we know the answer to this question, I suggest that the new popup should be disabled :-(.
modify labels +T-rustdoc +A-rustdoc-ui
modify labels +regression-from-stable-to-nightly
I've been having a different version of this happen on (and ) too. Whenever I press <kbdEnter</kbdafter typing in the search field, the Help popup momentarily appears. I don't think mine is a cookies issue; I think rustdoc is handling events wrong.
cc – this is a pretty severe usability bug, and we should fix it as soon as possible
Might be related to or ?
I'll try to bisect.
I'll send a fix shortly.
Will the affected documentations on be rebuilt?
Unfortunately no. It'll require to rebuild the impacted crates.
Change:
} } <ins> #[stable(feature = "string_box_error", since = "1.7.0")] impl From<String> for Box<Error> { fn from(str_err: String) -> Box<Error> { let err1: Box<Error + Send + Sync> = From::from(str_err); let err2: Box<Error> = err1; err2 } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<'a, 'b> From<&'b str> for Box<Error + Send + Sync + 'a> { fn from(err: &'b str) -> Box<Error + Send + Sync + 'a> {

Discussion:
There's an implementation of that allows the conversion of a to a , but it doesn't quite work when just using . The (perhaps subtle) error message is due to the compiler attempting to use the general implementation for . I was trying to return string errors from a function returning and ended up writing the following: This works well, but is really just boilerplate and not obviously suited to inclusion in any crate or library. Other solutions I thought of include: Adding to the standard library for cases like this. Altering the semantics for trait-resolution on types that parametrise over multiple traits. From what I've read, we don't yet have semantics for general additions of traits, only built-in ones. See .
This is somewhat intentional on the side of being conservative, but it seems pretty harmless to add.
Change:
<del> use crate::iter::{adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen}; </del> <ins> use crate::iter::{adapters::SourceIter, FusedIterator, TrustedLen}; </ins> use crate::ops::{ControlFlow, Try}; /// An iterator with a `peek()` that returns an optional reference to the next

Discussion:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting