jiebi/CodeConvo huggingface dataset:
Change:
I try this code: () I expect to see this happen: No invalid suggestion for . Instead, I got this errors: label D-invalid-suggestion T-compiler

Discussion:
) } <ins> /// Checks if the node is left-hand side of an assignment. pub fn is_lhs(&self, id: HirId) -> bool { match self.find(self.get_parent_node(id)) { Some(Node::Expr(expr)) => match expr.kind { ExprKind::Assign(lhs, _rhs, _span) => lhs.hir_id == id, _ => false, }, _ => false, } } </ins> /// Whether the expression pointed at by `hir_id` belongs to a `const` evaluation context. /// Used exclusively for diagnostics, to avoid suggestion function calls. pub fn is_inside_const_context(&self, hir_id: HirId) -> bool {

|err: &mut DiagnosticBuilder<'_>, found_to_exp_is_fallible: bool, exp_to_found_is_fallible: bool| { <ins> let exp_is_lhs = expected_ty_expr.map(|e| self.tcx.hir().is_lhs(e.hir_id)).unwrap_or(false); if exp_is_lhs { return; } </ins> let always_fallible = found_to_exp_is_fallible && (exp_to_found_is_fallible || expected_ty_expr.is_none()); let msg = if literal_is_ty_suffixed(expr) {

<ins> fn main() { let a: u16; let b: u16 = 42; let c: usize = 5; a = c + b * 5; //~ ERROR: mismatched types [E0308] //~| ERROR: mismatched types [E0308] //~| ERROR: cannot add `u16` to `usize` [E0277] } </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-81293.rs:6:13 | LL |     a = c + b * 5; |             ^^^^^ expected `usize`, found `u16` error[E0308]: mismatched types --> $DIR/issue-81293.rs:6:9 | LL |     a = c + b * 5; |         ^^^^^^^^^ expected `u16`, found `usize` error[E0277]: cannot add `u16` to `usize` --> $DIR/issue-81293.rs:6:11 | LL |     a = c + b * 5; |           ^ no implementation for `usize + u16` | = help: the trait `Add<u16>` is not implemented for `usize` error: aborting due to 3 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>
Change:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!

Discussion:
return document.getElementById("theme-picker"); } <ins> // Returns the current URL without any query parameter or hash. function getNakedUrl() { return window.location.href.split("?")[0].split("#")[0]; } </ins> // Sets the focus on the search bar at the top of the page function focusSearchBar() { getSearchInput().focus();

hideSearchResults(search); var hash = ev.newURL.slice(ev.newURL.indexOf("#") + 1); if (browserSupportsHistoryApi()) { <del> history.replaceState(hash, "", "?search=#" + hash); </del> <ins> // `window.location.search`` contains all the query parameters, not just `search`. history.replaceState(hash, "", getNakedUrl() + window.location.search + "#" + hash); </ins> } elem = document.getElementById(hash); if (elem) {

// Because searching is incremental by character, only the most // recent search query is added to the browser history. if (browserSupportsHistoryApi()) { <ins> var newURL = getNakedUrl() + "?search=" + encodeURIComponent(query.raw) + window.location.hash; </ins> if (!history.state && !params.search) { <del> history.pushState(query, "", "?search=" + encodeURIComponent(query.raw)); </del> <ins> history.pushState(query, "", newURL); </ins> } else { <del> history.replaceState(query, "", "?search=" + encodeURIComponent(query.raw)); </del> <ins> history.replaceState(query, "", newURL); </ins> } }

clearInputTimeout(); if (search_input.value.length === 0) { if (browserSupportsHistoryApi()) { <del> history.replaceState("", window.currentCrate + " - Rust", "?search="); </del> <ins> history.replaceState("", window.currentCrate + " - Rust", getNakedUrl() + window.location.hash); </ins> } hideSearchResults(); } else {

if (search_input.value !== "" && hasClass(search, "hidden")) { showSearchResults(search); if (browserSupportsHistoryApi()) { <del> history.replaceState(search_input.value, "", "?search=" + encodeURIComponent(search_input.value)); </del> <ins> var extra = "?search=" + encodeURIComponent(search_input.value); history.replaceState(search_input.value, "", getNakedUrl() + extra + window.location.hash); </ins> } document.title = searchTitle; }
Change:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!

Discussion:
getSearchInput().focus(); } <del> // Removes the focus from the search bar </del> <ins> // Removes the focus from the search bar. </ins> function defocusSearchBar() { getSearchInput().blur(); }

addClass(search, "hidden"); removeClass(main, "hidden"); document.title = titleBeforeSearch; <ins> // We also remove the query parameter from the URL. if (browserSupportsHistoryApi()) { history.replaceState("", window.currentCrate + " - Rust", getNakedUrl() + window.location.hash); } </ins> } // used for special search precedence
Change:
Since 1.49 beta, many tests fail on 32-bit PowerPC with the error that the test could not be compiled: I have not bisected the issue yet. Full log in: CC
I am seeing a lot of signal 4 (SIGILL) errors in the build log.
Ah, that reminds me of one bug in LLVM: I'll check whether this one fixes it:
Debian's LLVM 11 package () already contains the fix, so it can't be this. I'm trying to bisect this now in the Rust compiler itself but I just stumbled into the problem that a cross build no longer builds a full stage2 compiler with the std compiler which can be used on the target system, so I will first have to figure out what changed in Rust here.
You can pass to . The default changed to .
Thanks, that's what I guessed already, I just couldn't find the change in the vast amount of other changes ;).
Just cross-compiled 1.50 and the issue is still there:
I cannot get a sensible backtrace, unfortunately:
I'm bisecting this now. I think it might actually be a bug in the Rust compiler and not LLVM.
has lead me to :
At a first blush sounds like a limitation of the platform most likely (much like how it doesn't really support e.g. copy relocations all that well on PPC64) in which case a simple exclusion would make sense here.
I can confirm that reverting that change fixes the Rust compiler on 32-bit PowerPC for me. So, I agree, it should just be disabled on this target.
I can submit a simple patch either tonight or tomorrow some time.
there are reports of powerpc little endian toolchains still hitting this bug, can you imagine to push a simple patch to include the case of little endian as well? example:
...Does LLVM, or any of our codegen backends for that matter, actually support PowerPC 32-bit LE targets? Do they really exist? I know PowerPCs are bi-endian, but I thought the endian-switch bit was an extension that 32-bit architectures didn't have to include. Well, I do know we don't actually support any ppc32le Rust targets. I don't think it would exactly be what one would call a "maintenance burden" to accept a patch that adds a mild fix to bootstrap for custom targets. But if people are really using this target, it might be better to submit an application to add it as a new tier 3 target, so we can at least be Formally Aware of it.
Yes.
Fair enough! The patch you ask for is simple so if you send it in we probably would happily accept it, but the best way to make sure Void Linux's targets are accounted for in the future would be to go through . For , it isn't required that it works well or passes tests. In fact, it isn't even required to build. However, merely having such support in the codebase would help with letting us know which tuples are actually in use, and thus reduce the likelihood of accidentally stomping on them.

Discussion:
// efficient initial-exec TLS model. This doesn't work with `dlopen`, // so we can't use it by default in general, but we can use it for tools // and our own internal libraries. <del> if !mode.must_support_dlopen() { </del> <ins> if !mode.must_support_dlopen() && !target.triple.starts_with("powerpc-") { </ins> rustflags.arg("-Ztls-model=initial-exec"); }
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!
Yeah I expected that PR to break Miri.^^ I'll look into it.
I'll take a look.
Is there a failed CI job that I can look at?
Thanks for the offer! However, this will be much easier to do with some Miri experience, so in the interest of getting Miri to work again ASAP, it's probably better if I do it.
Oh, certainly. I spent some time trying to learn how to get Miri building and running, which I have always wanted to do, anyway. Here's my first attempt at fixing it: Pretty obvious stuff, I guess.

Discussion:
<del> Subproject commit 1cf1a2e40a6867948db84f806085a875fbefce3c </del> <ins> Subproject commit de0800e83b4e15cf3c6aa8f15f8328e86a95d955 </ins>
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. --I don't have a minimal example yet, but here's . Sample: The ICE happens on the and macros, which are both from the crate. <!-- 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. --This began with commit . <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
FYI, I think that link is only accessible to Googlers: !
Sorry, .
Minimized: Caused by
When we run on the AST, we create a definition for the desugared closure body inside an : As a result, the entry for our macro call will have the of the desugared closure. However, this desugared closure does not actually exist in the AST (it is created during lowering), so we will never check for lints with its when we emit buffered early lints.
Nightly has been broken for 3 days, if there's disagreement on how to fix the issue, can we revert while the fix is being worked on?
This will be fixed by PR
I'm still hitting this bug with the latest nightly.

Discussion:
// Explicitly check for lints associated with 'closure_id', since // it does not have a corresponding AST node <del> if let ast::ExprKind::Closure(_, asyncness, ..) = e.kind { if let ast::Async::Yes { closure_id, .. } = asyncness { self.check_id(closure_id); } </del> <ins> match e.kind { ast::ExprKind::Closure(_, ast::Async::Yes { closure_id, .. }, ..) | ast::ExprKind::Async(_, closure_id, ..) => self.check_id(closure_id), _ => {} </ins> } }

fn inner() { let _ = foo!(third); } <ins> #[allow(semicolon_in_expressions_from_macros)] async { let _ = foo!(fourth); }; </ins> }
Change:
I tried this code: I expected the code to compile sucessfully, but got an ICE instead: (This is procedural-macro-related. I can't reproduce without a procedural macro.) This used to work and regressed in . <details<summaryBacktrace</summary<p</p</detailscc
If this code only works on nightly, then I don't think it's a . However, we don't have a label, so ...
This will be fixed by , which handles attributes on expressions in a more systematic way. As a side note, is currently parsed as
Do you want to add to that PR then?
We'll still need to add a regression test.
Assigning P-high as .20on.20nightly.20with.20.60stmt_ex.E2.80.A6) and removing I-prioritize.

Discussion:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn assert_input(args: TokenStream, input: TokenStream) -> TokenStream { assert_eq!(input.to_string(), "trait Alias = Sized ;"); assert!(args.is_empty()); TokenStream::new() } </ins>

<ins> // check-pass // aux-build:issue-79825.rs #![feature(trait_alias)] extern crate issue_79825; #[issue_79825::assert_input] trait Alias = Sized; fn main() {} </ins>

<ins> // check-pass // aux-build:test-macros.rs #![feature(stmt_expr_attributes, proc_macro_hygiene)] extern crate test_macros; use test_macros::identity_attr; #[identity_attr] fn main() { let _x; let y = (); #[identity_attr] _x = y; } </ins>
Change:
Feature gate: This is a tracking issue for , which allows copying elements from a range to the end: <!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [x] Final commenting period (FCP) [x] yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.

Discussion:
#![cfg_attr(test, feature(test))] #![cfg_attr(test, feature(new_uninit))] #![feature(allocator_api)] <del> #![feature(vec_extend_from_within)] </del> #![feature(array_chunks)] #![feature(array_methods)] #![feature(array_windows)]

/// ## Examples /// /// ``` <del> /// #![feature(vec_extend_from_within)] /// </del> /// let mut vec = vec![0, 1, 2, 3, 4]; /// /// vec.extend_from_within(2..);

/// vec.extend_from_within(4..8); /// assert_eq!(vec, [0, 1, 2, 3, 4, 2, 3, 4, 0, 1, 4, 2, 3, 4]); /// ``` <del> #[unstable(feature = "vec_extend_from_within", issue = "81656")] </del> <ins> #[stable(feature = "vec_extend_from_within", since = "1.53.0")] </ins> pub fn extend_from_within<R>(&mut self, src: R) where R: RangeBounds<usize>,

#![feature(vecdeque_binary_search)] #![feature(slice_group_by)] #![feature(slice_partition_dedup)] <del> #![feature(vec_extend_from_within)] </del> #![feature(vec_spare_capacity)] #![feature(string_remove_matches)]
Change:
Compiled with gives:
This was caused by prioritize edit: in beta, this gives the following error: `
Assigning as discussed as part of the and removing .
Looks likely that is the cause. cc
Re-prioritizing as and removing as in the prioritization working group. label: +regression-from-stable-to-nightly +P-high -P-medium -I-prioritize

Discussion:
let upvar = ty::place_to_string_for_capture(tcx, place); match tables.upvar_capture(upvar_id) { ty::UpvarCapture::ByRef(ty::UpvarBorrow { <del> kind: ty::BorrowKind::MutBorrow, </del> <ins> kind: ty::BorrowKind::MutBorrow | ty::BorrowKind::UniqueImmBorrow, </ins> .. }) => { format!("mutable borrow of `{}`", upvar)

ty::UpvarCapture::ByValue(_) => { format!("possible mutation of `{}`", upvar) } <del> _ => bug!("upvar `{}` borrowed, but not mutably", upvar), </del> <ins> val => bug!("upvar `{}` borrowed, but not mutably: {:?}", upvar, val), </ins> } } else { bug!("not an upvar")

<ins> fn foo(x: &mut u32) { let bar = || { foo(x); }; bar(); //~ ERROR cannot borrow } fn main() {} </ins>

<ins> error[E0596]: cannot borrow `bar` as mutable, as it is not declared as mutable --> $DIR/issue-81700-mut-borrow.rs:3:5 | LL |     let bar = || { foo(x); }; |         ---            - calling `bar` requires mutable binding due to mutable borrow of `x` |         | |         help: consider changing this to be mutable: `mut bar` LL |     bar(); |     ^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </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!
Hey don't blame the rollerupperer! Looks like this was :)
Yeah I'm on it.

Discussion:
<del> Subproject commit 8d24b02414073bd4dafd3810205265c668dbcae1 </del> <ins> Subproject commit 4cf36f285084f8f841f3cff7b29d44b1d95ee1dd </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!
Where can I learn more about how this check is done? I just built stage 1 compiler with current master, and I was able to build miri with .
I'm guessing one of the tests is failing because it now needs a . The failure should be hidden somewhere in the logs of the runner:
should fix tihs.
Ah, so the problem is in one of the tests.. I only checked building.
usually, should let you run the tests, but this is currently broken by

Discussion:
<del> Subproject commit 4cf36f285084f8f841f3cff7b29d44b1d95ee1dd </del> <ins> Subproject commit 54bbbd13ac532deed80416295a224ce12547a40c </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: /// let f = Foo; /// I expected to see this happen: succeeds. Instead, this happened: <!-- 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. --:
searched nightlies: from nightly-2020-09-30 to nightly-2020-11-30 regressed nightly: nightly-2020-11-12 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: </detailsso probably
What is the correct option here ? Ignoring derived traits or putting default examples on the derive for those types ? The first seems hard to do but I'm maybe missing knowledge to see it done. The second means the examples won't be very relevant to the type on which they are derived. For this is not much of a problem, but for thing like I can see it confusing people.
I think rustdoc shouldn't require examples for derived traits. A possible fix is to only call in render, and use the macro span everywhere else for the purpose of lints.

Discussion:
if cx.tcx.hir().attrs(hir_id).lists(sym::doc).has_word(sym::hidden) || inherits_doc_hidden(cx.tcx, hir_id) <ins> || cx.tcx.hir().span(hir_id).in_derive_expansion() </ins> { return false; }

} <ins> /// doc /// /// ``` /// println!("hello"); /// ``` #[derive(Clone)] pub struct NiceStruct; </ins> #[doc(hidden)] pub mod foo { pub fn bar() {}
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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
We still need to land the Miri update in the rustc repo (I'll take care of that)

Discussion:
<del> Subproject commit 54bbbd13ac532deed80416295a224ce12547a40c </del> <ins> Subproject commit e09dce0f43993faf03cc46ac365b6a46287f90e7 </ins>
Change:
The following code causes compiler panics due to the first line without which the issue isn't reproducible. Calling the function outside of a constant context emits the right compiler errors. <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
FWIW, replacing the function body with still gives an ICE:
Minimized slightly further, without const generics: <details<summarybacktrace</summary</detailsThe ICE occurs back to . In , it errors with By making small changes such as making the closure no longer take paramters or removing the reference at It errors, instead of an ICE, on stable and nightly with
searched nightlies: from nightly-2020-08-16 to nightly-2021-02-03 regressed nightly: nightly-2020-12-28 searched commits: from to regressed commit: edit: for this code sample <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
cc
Just to clarify, AFAICT, this issue is not due to , the stabilization just allowed code with const generics to run into this. MCVE ICEs before and shows that this is a borrowck bug not related to const generics
Assigning as discussed as part of the and removing .
I'm not sure if this is identical problem or not. The error message is: and my code is: I need both parts or the COPY tuple for the error to trigger and I'm unsure why. And also, if I put in its own const the bug is not triggered.
Triage: No longer ICE with the latest nightly, I guess fixed it? Marking as .

Discussion:
<ins> // Regression test for #81899. // The `panic!()` below is important to trigger the fixed ICE. const _CONST: &[u8] = &f(&[], |_| {}); const fn f<F>(_: &[u8], _: F) -> &[u8] where F: FnMut(&u8), { panic!() //~ ERROR: evaluation of constant value failed } fn main() {} </ins>

<ins> error[E0080]: evaluation of constant value failed --> $DIR/issue-81899.rs:10:5 | LL | const _CONST: &[u8] = &f(&[], |_| {}); |                        -------------- inside `_CONST` at $DIR/issue-81899.rs:4:24 ... LL |     panic!() |     ^^^^^^^^ |     | |     the evaluated program panicked at 'explicit panic', $DIR/issue-81899.rs:10:5 |     inside `f::<[closure@$DIR/issue-81899.rs:4:31: 4:37]>` at $SRC_DIR/std/src/panic.rs:LL:COL | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>