jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-rustfix pub fn func<F>() where F: FnOnce() -> () {} //~^ ERROR expected one of //~| NOTE expected one of //~| NOTE `Fn` bounds require arguments in parentheses fn main() {} </ins>

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
assert-attribute: (".impl-items .rustdoc-toggle", {"open": ""}) click: ".impl-items .rustdoc-toggle summary::before" // This is the position of "[-]" next to that pub fn. assert-attribute-false: (".impl-items .rustdoc-toggle", {"open": ""}) <ins> // Click the "Trait" part of "impl Trait" and verify it navigates. click: "#impl-Trait h3 a:first-of-type" assert-text: (".fqn .in-band", "Trait lib2::Trait") </ins>

Discussion:
For example, I can't click any links (i.e., when I click them, nothing happens) in header. Likewise, I can't click any links for , but I can click links in , which has no tag. This same behavior occurs in the docs, though every method is documented and thus has a tag, so there's no comparison to non- methods. This is a regression in nightly 1.58.0. I'm using Safari on macOS; I don't know if this reproduces on other browsers.
This is probably ; I don't know why that change was made or if this is intentional. cc
I can't imagine this part of the behavior is intentional, since it breaks a lot of rustdoc's UI.
We really need more GUI tests so this can't happen again...
Can confirm, that wasn't intentional. I manually checked during development to make sure that wouldn't happen, but it must have broken. Sorry for that, and sorry for not adding a GUI test for it. I'll post a fix in a moment.
Assigning priority as in the prioritization working group.
Change:
// run-fail <del> // error-pattern:assertion failed: `(left != right)` // error-pattern: left: `14` // error-pattern:right: `14` </del> <ins> // error-pattern:assertion `left != right` failed // error-pattern:  left: 14 // error-pattern: right: 14 </ins> // ignore-emscripten no processes fn main() {

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
help: use `Box::new()` instead | LL |     let _ = Box::new(1); <del> |             ~~~~~~~~~~~ </del> <ins> |             ~~~~~~~~~ + </ins> error: `box_syntax` has been removed --> $DIR/removed-syntax-box.rs:11:13

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
} "meta" => token::NtMeta(p.parse_meta_item()), _ => { <del> p.fatal(&format!("unsupported builtin nonterminal parser: {}", name)[]) </del> <ins> p.span_fatal_help(sp, &format!("invalid fragment specifier `{}`", name)[], "valid fragment specifiers are `ident`, `block`,  `stmt`, `expr`, `pat`, `ty`, `path`, `meta`, `tt`  and `item`") </ins> } } }

Discussion:
I work on Windows 8.1 64-bit, rustc version: BTW, the same ICE occurred for my but it did not print backtrace with and I don't know why.
Change:
base.is_like_android = true; base.position_independent_executables = true; base.has_elf_tls = false; <ins> base.requires_uwtable = true; </ins> base }

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?
Change:
error: an inner attribute is not permitted in this context <del> --> $DIR/attr.rs:5:3 </del> <ins> --> $DIR/attr.rs:5:1 </ins> | LL | #![lang = "foo"] <del> |   ^ </del> <ins> | ^^^^^^^^^^^^^^^^ </ins> | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.

Discussion:
Given the following we currently emit We should emit at least the following We might also want to provide suggestions when it makes sense (like turning the attr into an outer attr).
Hey , I tried to solve this with a little help of on a rust meetup. I wasn't able to run because of the following message. But I started to add some code you can read here: is this going into the right direction?
thank you for taking a look at this! You should be able to run the tests with . Use to update the relevant files. The code you've written would generate the following output: Instead, we'd want this to be a single error. What you'd want to do is 1) get the span for the prior attribute from 2) expand to also hold an extra field and 3) change the following to be This lets you point at the prior span in the same error. The second part of this ticket is changing the linked code to no longer use , but rather synthesize a new span from the first 's span to the closing . You can use to do so. Finally, we change the above to be something like
Are you still working on this? I'm thinking of giving it a try.
Go on! I don’t have so much time atm so just go there step by step while learning rust. If you want so solve it - awesome
Change:
builder.create_dir(&image.join("etc/bash_completion.d")); let cargo = builder.ensure(tool::Cargo { compiler, target }); builder.install(&cargo, &image.join("bin"), 0o755); <ins> for dirent in fs::read_dir(cargo.parent().unwrap()).expect("read_dir") { let dirent = dirent.expect("read dir entry"); if dirent.file_name().to_str().expect("utf8").starts_with("cargo-credential-") { builder.install(&dirent.path(), &image.join("libexec"), 0o755); } } </ins> for man in t!(etc.join("man").read_dir()) { let man = t!(man); builder.install(&man.path(), &image.join("share/man/man1"), 0o644);

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. --<!-- The steps to reproduce the bug. --(The actual target doesn't seem to matter, the feature just requires that we pass a argument.) The following error occurs: I think this issue occurs because already landed, while the cargo-side revert in did not. So this issue will likely go away after the next cargo update. I still decided to open this issue in case other people encounter the same problem. <!-- 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. --:
Cc for
This will be fixed by .
Change:
/// implicit closure bindings. It is needed when the closure is /// borrowing or mutating a mutable referent, e.g.: /// <del> ///    let x: &mut isize = ...; ///    let y = || *x += 5; </del> <ins> ///     let x: &mut isize = ...; ///     let y = || *x += 5; </ins> /// /// If we were to try to translate this closure into a more explicit /// form, we'd encounter an error with the code as written: /// <del> ///    struct Env { x: & &mut isize } ///    let x: &mut isize = ...; ///    let y = (&mut Env { &x }, fn_ptr);  // Closure is pair of env and fn ///    fn fn_ptr(env: &mut Env) { **env.x += 5; } </del> <ins> ///     struct Env { x: & &mut isize } ///     let x: &mut isize = ...; ///     let y = (&mut Env { &x }, fn_ptr);  // Closure is pair of env and fn ///     fn fn_ptr(env: &mut Env) { **env.x += 5; } </ins> /// /// This is then illegal because you cannot mutate an `&mut` found /// in an aliasable location. To solve, you'd have to translate with /// an `&mut` borrow: /// <del> ///    struct Env { x: & &mut isize } ///    let x: &mut isize = ...; ///    let y = (&mut Env { &mut x }, fn_ptr); // changed from &x to &mut x ///    fn fn_ptr(env: &mut Env) { **env.x += 5; } </del> <ins> ///     struct Env { x: & &mut isize } ///     let x: &mut isize = ...; ///     let y = (&mut Env { &mut x }, fn_ptr); // changed from &x to &mut x ///     fn fn_ptr(env: &mut Env) { **env.x += 5; } </ins> /// /// Now the assignment to `**env.x` is legal, but creating a /// mutable pointer to `x` is not because `x` is not mutable. We

Discussion:
review comments:
I've looked into this some - NLL misses three errors, all of the form u.yu.x`. In each of the three cases, there is a mutable borrow of some field of the union and then a shared borrow of some other field immediately following. The issue seems to be that the mutable borrow is killed straight away as it isn't used later - therefore not causing a conflict with the shared borrow. I'm inclined to think that this is fine - and that NLL is correct in having less errors here. However, we might want to update the test to use the first mutable borrow for each case in order to make the error happen and demonstrate the diagnostic - if this is the case, I've that we can open a PR for that will update the test. cc
I'm inclined to agree that this is an instance where the test was not robust and that we need to add uses of those first mutable borrows.
I've submitted a PR () that makes the test more robust.
Change:
use rustc_hir::def_id::DefId; use rustc_infer::infer::at::ToTrace; use rustc_infer::infer::canonical::{Canonical, QueryResponse}; <del> use rustc_infer::infer::{InferCtxt, TyCtxtInferExt}; </del> <ins> use rustc_infer::infer::{DefiningAnchor, InferCtxt, TyCtxtInferExt}; </ins> use rustc_infer::traits::TraitEngineExt as _; use rustc_middle::ty::query::Providers; use rustc_middle::ty::subst::{GenericArg, Subst, UserSelfTy, UserSubsts};

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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
} } <del> extern "C" bool LLVMRustLinkInExternalBitcode(LLVMModuleRef DstRef, char *BC, size_t Len) { Module *Dst = unwrap(DstRef); std::unique_ptr<MemoryBuffer> Buf = MemoryBuffer::getMemBufferCopy(StringRef(BC, Len)); #if LLVM_VERSION_GE(4, 0) Expected<std::unique_ptr<Module>> SrcOrError = llvm::getLazyBitcodeModule(Buf->getMemBufferRef(), Dst->getContext()); if (!SrcOrError) { LLVMRustSetLastError(toString(SrcOrError.takeError()).c_str()); return false; } auto Src = std::move(*SrcOrError); #else ErrorOr<std::unique_ptr<Module>> Src = llvm::getLazyBitcodeModule(std::move(Buf), Dst->getContext()); if (!Src) { LLVMRustSetLastError(Src.getError().message().c_str()); return false; } #endif std::string Err; raw_string_ostream Stream(Err); DiagnosticPrinterRawOStream DP(Stream); #if LLVM_VERSION_GE(4, 0) if (Linker::linkModules(*Dst, std::move(Src))) { #else if (Linker::linkModules(*Dst, std::move(Src.get()))) { #endif LLVMRustSetLastError(Err.c_str()); return false; } return true; } </del> // Note that the two following functions look quite similar to the // LLVMGetSectionName function. Sadly, it appears that this function only // returns a char* pointer, which isn't guaranteed to be null-terminated. The

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
"sparc" => sparc::compute_abi_info(cx, self), "sparc64" => sparc64::compute_abi_info(cx, self), "nvptx64" => { <del> if cx.target_spec().adjust_abi(abi) == spec::abi::Abi::PtxKernel { </del> <ins> if cx.target_spec().adjust_abi(abi, self.c_variadic) == spec::abi::Abi::PtxKernel { </ins> nvptx64::compute_ptx_kernel_abi_info(cx, self) } else { nvptx64::compute_abi_info(self)

Discussion:
While testing variadic function support with I discovered that Rust requires such functions to use either "C" or "cdecl" ABIs but requires the "system" ABI on non-x86 Windows. My undertstanding from discussing with is that this is not an issue with itself but with Rust's insistence that such functions aren't allowed to use the "system" ABI. It's just that is very strict about calling convention so that's where the issue surfaced. On x64 I should be able to compile this but Rust says no: This example works if I change the ABI to "cdecl" but that's not meant to be a valid ABI on x64 and so when I try to compile this with it fails: The practical result is that it is impossible to link this function with on non-x86.
cc which originally variadics support to some other calling conventions (though not it seems) behind the feature gate .
A workaround is to use "C" on non-x86 as I implemented here:
Thoughts on permitting variadic parameters with the calling convention for non-x86 Windows? If gets merged then we'll be pushing folks to use so that they get the correct calling convention for Windows APIs on all architectures, but that breaks compatibility with variadic parameters.
This work-around is . Would be great if there was a way that it could be avoided. :)
There's a comment saying this can't work: I don't understand anything about these ABIs so I can't say how accurate this is. Also I see nothing here special-casing x86, so why does the issue specifically mention non-x86?
Happy to update as soon as there's a way to avoid it.
Can we make equal to when applied to a variadic function? It's supposed to be whatever ABI is correct for the system api and is the correct ABI for a variadic win32 function. According to the acts as when applied to a variadic function.
Went ahead and opened for this.
Change:
<ins> // Don't const eval fields with ambiguous layout. // See issues #125842 and #124464. enum TestOption<T> { TestSome(T), TestSome(T), //~^ ERROR the name `TestSome` is defined multiple times } pub struct Request { bar: TestOption<u64>, bar: u8, //~^ ERROR field `bar` is already declared } fn default_instance() -> &'static Request { static instance: Request = Request { bar: 17 }; &instance } pub 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. --:
with debug assertions: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
without: --<details<summary<strongBacktrace</strong</summary<p</p</details

<!-- 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. --(reduced) <details<summary<strongOriginal Code</strong</summary<p</p</details<!-- 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- has the same ICE location, but this one doesn't require any feature to make ICE. ICE-loc: Original ICE-triggering code is mutated from test-file
bisects to searched nightlies: from nightly-2024-01-01 to nightly-2024-04-30 regressed nightly: nightly-2024-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The following already reproduces on 1.77 stable
Change:
var dontApplyBlockRule = toggle.parentNode.parentNode.id !== "main"; if (action === "show") { removeClass(relatedDoc, "fns-now-collapsed"); <del> removeClass(docblock, "hidden-by-usual-hider"); </del> <ins> // Stability information is never hidden. if (hasClass(docblock, "stability") === false) { removeClass(docblock, "hidden-by-usual-hider"); } </ins> onEachLazy(toggle.childNodes, adjustToggle(false, dontApplyBlockRule)); onEachLazy(relatedDoc.childNodes, implHider(false, dontApplyBlockRule)); } else if (action === "hide") { addClass(relatedDoc, "fns-now-collapsed"); <del> addClass(docblock, "hidden-by-usual-hider"); </del> <ins> // Stability information should be shown even when detailed info is hidden. if (hasClass(docblock, "stability") === false) { addClass(docblock, "hidden-by-usual-hider"); } </ins> onEachLazy(toggle.childNodes, adjustToggle(true, dontApplyBlockRule)); onEachLazy(relatedDoc.childNodes, implHider(true, dontApplyBlockRule)); }

Discussion:
renders this as follows. Notice that the blue banner appears for Eq (I guess because the trait is empty) but not for PartialEq. I believe that it should consistently appear for neither Eq nor PartialEq, or both Eq and PartialEq. <img src="https://user-" width="300"<brExpanding the [+] next to impl PartialEq shows the other blue banner but this issue is about the default appearance on page load. <img src="https://user-" width="300"<brMentioning tracking issue . Mentioning
Ohh, the collapse settings are fun; I never noticed this in because I have which seems to imply not collapsing the trait implementations. Clearing that setting from local storage, or if it's set to does this; I think it should be possible to make it so that having this block there either ignores collapsing so it shows always, (though this may be inconsistent with how it works with functions), or make it default to uncollapsing the trait.
(Something else to check at the same time: what happens with JS disabled)
Nothing is collapsed when JS is disabled. :) I'll take a look tomorrow.
The toggle, and the items it toggles, are hidden when JS is disabled.
Hum... I suppose it's a new issue then. Something to add in .
Change:
<del> Subproject commit 86b8643586aa39f36fb7a02e98c8d64d31415e70 </del> <ins> Subproject commit b4f1769734b6204fc6bece8556b7b80a7683271e </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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: P-medium. Removing nomination.
Change:
} ty::TyBox(_) => { // treat like we would treat `Box` <del> let def_id = tcx.lang_items.owned_box().unwrap(); Some(StructSimplifiedType(def_id)) </del> <ins> match tcx.lang_items.require_owned_box() { Ok(def_id) => Some(StructSimplifiedType(def_id)), Err(msg) => tcx.sess.fatal(&msg), } </ins> } ty::TyClosure(def_id, _) => { Some(ClosureSimplifiedType(def_id))

Discussion:
Hi, first time contributor here. This might be a bug. I think every factor mentioned in the title is required to trigger this. (I'm trying to do horrible things to the runtime, but I don't think this is significant here.) Source: Backtrace (rustc 0.13.0-nightly ( 2015-01-04 00:50:59 +0000) installed via rustup on Ubuntu LTS):
This happened to me as well, with an almost identical program. More info:
Following the backtrace, it looks like assumes that the 'ownedbox' lang item is always defined and calls unwrap(), triggering the panic.
Triage: still ICEs: