jiebi/CodeConvo huggingface dataset:
Change:
false } <del> fn note_caller_chooses_ty_for_ty_param( </del> <ins> fn try_note_caller_chooses_ty_for_ty_param( </ins> &self, diag: &mut Diag<'_>, expected: Ty<'tcx>, found: Ty<'tcx>, ) { <del> if let ty::Param(expected_ty_as_param) = expected.kind() { diag.subdiagnostic(errors::NoteCallerChoosesTyForTyParam { ty_param_name: expected_ty_as_param.name, found_ty: found, }); </del> <ins> // Only show the note if: // 1. `expected` ty is a type parameter; // 2. The `expected` type parameter does *not* occur in the return expression type. This can //    happen for e.g. `fn foo<T>(t: &T) -> T { t }`, where `expected` is `T` but `found` is //    `&T`. Saying "the caller chooses a type for `T` which can be different from `&T`" is //    "well duh" and is only confusing and not helpful. let ty::Param(expected_ty_as_param) = expected.kind() else { return; }; if found.contains(expected) { return; </ins> } <ins> diag.subdiagnostic(errors::NoteCallerChoosesTyForTyParam { ty_param_name: expected_ty_as_param.name, found_ty: found, }); </ins> } /// check whether the return type is a generic type with a trait bound

Discussion:
The statement "the caller chooses a type for which can be different from " is confusing because and are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in . No response No response
label +D-confusing
Thanks, that note definitely doesn't make sense. CC (). I suggested to move out of in order to catch more cases but that was a bit too aggressive as can be witnessed here — that's on me. We should replicate some parts of , namely checking that the type param in question does not occur in the return expression type. That did cross my mind back then but I didn't really follow up on that thought for some reason.
Thanks for the cc I'll take a look ~today/tomorrow
Opened to avoid making the note if found return type contains the expected return type (type parameter).
Change:
| = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information = help: add `#![feature(async_closure)]` to the crate attributes to enable <ins> = help: to use an async block, remove the `||`: `async {` </ins> error: aborting due to previous error

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
] [[package]] <ins> name = "rustc_plugin" version = "0.0.0" dependencies = [ "rustc_plugin_impl", ] [[package]] </ins> name = "rustc_plugin_impl" version = "0.0.0" dependencies = [

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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 prioritization.
should fix this
Change:
opt local-rust 0 "use an installed rustc rather than downloading a snapshot" opt inject-std-version 1 "inject the current compiler version of libstd into programs" opt llvm-static-stdcpp 0 "statically link to libstdc++ for LLVM" <del> opt rpath 1 "build rpaths into rustc itself" </del> <ins> opt rpath 0 "build rpaths into rustc itself" </ins> opt nightly 0 "build nightly packages" opt verify-install 1 "verify installed binaries work" opt jemalloc 1 "build liballoc with jemalloc"

Discussion:
Followup to and . Can we completely eliminate our usage of rpath? Doing so would make our linkage more consistent across platforms since it doesn't work on windows. Nominating.
I think that the largest difficulty for this is that we build dynamically, and this means that if you have a fresh install of rust in a new location it won't work by default (you'll have to munge your os library path). If we could print out some helpful instructions of what to do, then I think that would be a much better situation, but I'm also not entirely sure how we'd do that.
If we defaulted to static linking then there would it would be easier to justify making people use LDLIBRARYPATH when they opt in to dylibs.
The only consideration that I have about static linking is that you'll install 5 copies of (as opposed to 3): with static linking rustdoc rustc rustpkg without static linking That being said, our distributions are already pretty big, so maybe this isn't much of a concern? I agree though that if we statically linked everything then we could easily take this route of action
IMO this is a concern. What's wrong with the current approach (link rust's own tools dynamically)? It works fine on windows since the DLLs are in the bin folder and for everything else it will soon link statically ().
Another use case for this came up on IRC. If you've got a rust installed locally in , then when you try to recompile rust again, the rpath for all the stage0-produced libraries will have something pointing into /usr/local. Apparently on some platforms when you run the stage1 , this means that you'll pick up all the /usr/local libs at runtime instead of the stage0-produced libs (causing errors until you uninstall rustc).
Accepted for 1.0, P-backcompat-lang.
Rust now builds and passes tests with . This feature could be disabled by default or completely removed, with as a suggestion for those who want to use a dynamically linked in their home directory on *nix.
Change:
<ins> warning: struct `Foo` is never constructed --> $DIR/skipped-ref-pats-issue-125058.rs:8:8 | LL | struct Foo; |        ^^^ | = note: `#[warn(dead_code)]` on by default warning: unused closure that must be used --> $DIR/skipped-ref-pats-issue-125058.rs:12:5 | LL | /     || { LL | | LL | |         if let Some(Some(&mut x)) = &mut Some(&mut Some(0)) { LL | |             let _: u32 = x; LL | |         } LL | |     }; | |_____^ | = note: closures are lazy and do nothing unless called = note: `#[warn(unused_must_use)]` on by default warning: 2 warnings emitted </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
rustc repro:
This ^ bisects to cc
This likely exposed a preexisting bug in cc previously was silently bailing when it couldn't deref a type it expected to be able to deref.
is most likely going to be removed, but this also reproduces with edition 2024 and : claim
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. // edition:2018 // compile-flags:-Z unstable-options // FIXME: once `--edition` is stable in rustdoc, remove that `compile-flags` directive #![feature(rust_2018_preview, async_await, futures_api)] // @has async_fn/struct.S.html // @has - '//code' 'pub async fn f()' pub struct S; impl S { pub async fn f() {} } </ins>

Discussion:
Rustdoc seems to fail on async syntax in some situations. With in , the following is a sample of some apparent issues. This should build fine, but fails when running rustdoc: Tested with a few different nightlies (rustc 1.30.0-nightly ( 2018-08-05)) and latest master ().
This is a bug between rustdoc and , where the only place that is handed to libsyntax is this specific all-in-one entry point to the compiler: However, since rustdoc manages the phases of compilation itself, this line is never hit, and thus the global state telling libsyntax what edition to use is not set. We use this call manually for building doctests (see ), but not anywhere else. I propose moving the call from to , right before it sets up the parse session. That way, rustdoc can continue to set the edition in the session options, and other consumers of aren't caught by this gotcha.
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(decl_macro)] pub macro create_struct($a:ident) { struct $a; impl Clone for $a { fn clone(&self) -> Self { $a } } } fn main() { create_struct!(Test); Test.clone(); } </ins>

Discussion:
Implementing traits doesn't seem to work either in declarative macros. looks like it should compile: But it does this instead:
Looks like this has been fixed.
Change:
<ins> error[E0053]: method `from` has an incompatible type for trait --> $DIR/issue-90444.rs:3:16 | LL |     fn from(_: fn((), (), &mut ())) -> Self { |                ^^^^^^^^^^^^^^^^^^^ |                | |                types differ in mutability |                help: change the parameter type to match the trait: `for<'r> fn((), (), &'r ())` | = note: expected fn pointer `fn(for<'r> fn((), (), &'r ())) -> A` found fn pointer `fn(for<'r> fn((), (), &'r mut ())) -> A` error[E0053]: method `from` has an incompatible type for trait --> $DIR/issue-90444.rs:11:16 | LL |     fn from(_: fn((), (), u64)) -> Self { |                ^^^^^^^^^^^^^^^ |                | |                expected `u32`, found `u64` |                help: change the parameter type to match the trait: `fn((), (), u32)` | = note: expected fn pointer `fn(fn((), (), u32)) -> B` found fn pointer `fn(fn((), (), u64)) -> B` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0053`. </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. --: Also get this using stable: You can see it on the playground: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can reproduce even without the type aliases: Edit: even smaller reproducer: Produces this output: () :
After some testing, this can be reproduced since 1.53, might have been introduced in
Change:
} } <del> Some(cx.enter_alias(args, def_id.to_def_id(), |cx| clean_ty(&ty, cx))) </del> <ins> Some(cx.enter_alias(args, def_id.to_def_id(), |cx| { cx.with_param_env(def_id.to_def_id(), |cx| clean_ty(&ty, cx)) })) </ins> } pub(crate) fn clean_ty<'tcx>(ty: &hir::Ty<'tcx>, cx: &mut DocContext<'tcx>) -> Type {

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. --Original code Auto reduced but does no longer compile: <!-- 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. --: `rustdoc -Znormalize-docs <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
can you share the stack trace? the part that says is actually what's needed to debug this lol
nvm, found it
Change:
#![no_std] ``` <del> See also the [unstable book][1]. </del> <ins> See also [this section of the Rustonomicon][beneath std]. </ins> <del> [1]: https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib </del> <ins> [beneath std]: https://doc.rust-lang.org/nomicon/beneath-std.html </ins>

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .
Change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! format_args { ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! format_args { ($fmt:expr) => ({ /* compiler built-in */ }); ($fmt:expr, $($args:tt)*) => ({ /* compiler built-in */ }); } </ins> /// Inspect an environment variable at compile time. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
<ins> //@ aux-build:block-on.rs //@ edition:2021 //@ check-pass #![feature(async_closure)] extern crate block_on; fn force_fnonce<T: async FnOnce()>(t: T) -> T { t } fn main() { block_on::block_on(async { let x = 1i32; // `force_fnonce` pulls the closure's kind down to `FnOnce`, // which means that we don't treat the borrow of `x` as a // self-borrow (with `'env` lifetime). This leads to a lifetime // error which is solved by forcing the inner coroutine to // be `move` as well, so that it moves `x`. let c = force_fnonce(async move || { println!("{x}"); }); c().await; }); } </ins>

Discussion:
Rustc panicked when I attempted to use async in poll. I wanted to compose an async task inside my custom future :
I believe this is a duplicate of , which I have a local branch to fix but which needs a bit of cleanup first.

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code (minimized): I expected to see this happen: Compiles Instead, this happened (): Instead, this happened (latest nightly): ICE Related: Mentioning :wink: Best guess: <details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. -- modify labels: +regression-from-nightly-to-nightly -regression-untriaged Thanks for investigating! -
Nightly-only features aren't typically regression triaged. I'll look into it soon.
Change:
- env: IMAGE=arm-android - env: IMAGE=armhf-gnu - env: IMAGE=cross DEPLOY=1 <del> - env: IMAGE=linux-tested-targets DEPLOY=1 </del> - env: IMAGE=dist-android DEPLOY=1 - env: IMAGE=dist-arm-linux DEPLOY=1 - env: IMAGE=dist-armv7-aarch64-linux DEPLOY=1 - env: IMAGE=dist-freebsd DEPLOY=1 <ins> - env: IMAGE=dist-i586-gnu-i686-musl DEPLOY=1 </ins> - env: IMAGE=dist-mips-linux DEPLOY=1 - env: IMAGE=dist-mips64-linux DEPLOY=1 - env: IMAGE=dist-powerpc-linux DEPLOY=1 - env: IMAGE=dist-powerpc64-linux DEPLOY=1 - env: IMAGE=dist-s390x-linux-netbsd DEPLOY=1 - env: IMAGE=dist-x86-linux DEPLOY=1 <ins> - env: IMAGE=dist-x86_64-musl DEPLOY=1 </ins> - env: IMAGE=emscripten - env: IMAGE=i686-gnu - env: IMAGE=i686-gnu-nopt

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
lhs, rhs, expected, <del> AllowOverloadedOperators); </del> <ins> SimpleBinop); </ins> let lhs_ty = fcx.expr_ty(lhs); let rhs_ty = fcx.expr_ty(rhs);

Discussion:
OS: Ubuntu 12.04 x86 rustc -v rustc 0.9-pre ( 2013-12-24 01:56:30 -0800) host: i686-unknown-linux-gnu Full error message: 30:14 error: binary operation + cannot be applied to type v += move; ^~~~~ error: internal compiler error: no type for node 81: expr move (id=81) in fcx 0xb3970ef8 This message reflects a bug in the Rust compiler. We would appreciate a bug report: task 'rustc' failed at 'explicit failure', task '<main' failed at 'explicit failure', Source:
Change:
<ins> error[E0119]: conflicting implementations of trait `Clone` for type `&mut MyType` --> $DIR/coherence-conflicting-repeated-negative-trait-impl-70849.rs:8:1 | LL | impl !Clone for &mut MyType {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: conflicting implementation in crate `core`: - impl<T> !Clone for &mut T where T: ?Sized; error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0119`. </ins>

Discussion:
The following code: produces: which reads as: any , which isn't realy true. It realy implements . Perhaps the error message should add a in front of the impl to make it more obvious, like this:
Hi , I'd like to take up this issue if it has not been assigned yet. However this would be my first contribution so I just want to confirm it's a good first task. Thanks!
Yeah, for sure! It should be as simple as updating () to account for the polarity. You can query/obtain the impl polarity with . Feel free to reach out here or on Zulip if you have any questions.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue70273-assoc-fn.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
<ins> // Copyright 2015 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. // Issue #14660 macro_rules! priv_x { () => { static x: u32 = 0; }} macro_rules! pub_x { () => { pub priv_x!(); //~ ERROR can't qualify macro invocation with `pub` //~^ HELP try adjusting the macro to put `pub` inside the invocation }} mod foo { pub_x!(); } fn main() { let y: u32 = foo::x; } </ins>

Discussion:
Hey, I have an issue on my macros use. The source code of my macro is . I can't put the pub keyword and if I call my macro like this : The methods aren't public. Am I doing something wrong or is it a compiler's bug ? Thanks in advance.
Any news on it ?
Related?
I think.
I just encountered this. I can reproduce it with:
Now let's just hope it'll be fixed sooner or later !
Hm, what should actually mean? A macro in item position can expand to zero or more items. Should the qualifier apply to all of them, or should it be an error to use it with a multi-item macro? We might want to forbid in this position for 1.0, and come back to the issue later. I had a design for that I think would be rather nice. The current workaround is to write The precise syntax is up to the macro author and can accommodate multiple items. This workaround would be less annoying if we had a "0 or 1" repeat operator in macros.
Could you be a little more explicit about the workaround - I can't seem to get it to work.
from the compiler itself. looks better, with less duplicated code.
Thanks for the examples. If I understand them correctly (neither of which generate forms, iiuc), I should be matching on and inserting a literal in the expansion, but does not seem to work :
It works for me on rustc 1.0.0-dev ( 2015-02-16). The playpen is just to have my fix for .
Thanks for the confirmation. I'll be looking forward to a new nightly for once :)