jiebi/CodeConvo huggingface dataset:
Change:
pub struct Bar; // @has 'foo/struct.Bar.html' <del> // @has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @has - '//div[@class="sidebar-elems"]//a' 'FOO' </del> <ins> // @!has - '//h3[@class="sidebar-title"]' 'Associated Constants' // @!has - '//div[@class="sidebar-elems"]//a' 'FOO' </ins> impl Trait for Bar { const FOO: u32 = 1;

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: I would expect not to appear as its own item in the rustdoc sidebar for the struct. This would be consistent with the behavior of methods and associated types from trait impls, which also don't appear as their own item in the sidebar. Instead, this happened: The constant is listed under "Associated Constants" in the left-hand sidebar of the rustdoc page for . This is inconsistent with how methods from trait impls appear in documentation. ! <!-- 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 was intentionally in .
The inclusion of associated consts from inherent impls is intentional. But is it intentional that associated consts from trait impls also appear in the sidebar (even though methods from trait impls do not)? (I'm filing this bug because for a crate I'm developing, the current behavior makes the sidebar extremely messy. Restricting the list of associated constants to those from inherent impls would make navigating the documentation for my crate much more pleasant.)
I think the behavior proposes makes sense.
Change:
``` ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_add(1), 101); assert_eq!(", stringify!($SelfT), "::max_value().saturating_add(100), ", stringify!($SelfT), <del> "::max_value());", </del> <ins> "::max_value()); assert_eq!(", stringify!($SelfT), "::min_value().saturating_add(-1), ", stringify!($SelfT), "::min_value());", </ins> $EndFeature, " ```"),

Discussion:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.
Change:
<ins> //! This is a regression test for an ICE. // edition: 2021 trait Foo { async fn foo(self: &dyn Foo) { //~^ ERROR: `Foo` cannot be made into an object //~| ERROR invalid `self` parameter type: &dyn Foo todo!() } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()', 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()' 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: [typeck] type-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in module [analysis] running analysis passes on this crate --
Also ices in Rust 2021 in case anybody was wondering. Further reduced:
(see below)
It's of course :upsidedownface:
fyi
Change:
"byteorder", "cargo_metadata 0.9.0", "colored", <del> "compiletest_rs 0.3.26", </del> <ins> "compiletest_rs", </ins> "directories", "env_logger 0.7.1", "getrandom",

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: P-medium, removing nomination label.
Change:
_ => None, }) .flat_map(|bp| { <del> let bt = if is_param(self.tcx, bp.bounded_ty, param_id) { </del> <ins> let bt = if bp.is_param_bound(param_def_id) { </ins> Some(ty) } else if !only_self_bounds.0 { Some(self.to_ty(bp.bounded_ty))

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
<ins> // Regression test for #71732, it used to emit incorrect diagnostics, like: // error[E0283]: type annotations needed //  --> src/main.rs:5:10 //   | // 5 |         .get(&"key".into()) //   |          ^^^ cannot infer type for struct `String` //   | //   = note: cannot satisfy `String: Borrow<_>` // help: consider specifying the type argument in the method call //   | // 5 |         .get::<Q>(&"key".into()) //   | use std::collections::hash_map::HashMap; fn foo(parameters: &HashMap<String, String>) -> bool { parameters .get(&"key".into()) //~ ERROR: type annotations needed .and_then(|found: &String| Some(false)) .unwrap_or(false) } fn main() {} </ins>

Discussion:
This is either a regression of or it was closed prematurely. Fairly minimal reproducer: - I'm still not entirely sure what is actually wrong here - is it the lifetime as in ? Anyhow - the message doesn't refer to any T that needs to be specified, and the named explicit type is not sufficient to fix the issue even when given. Happens with nightly too.
Right, so the triggering problem here is the call - with that fixed it all falls into place, but the error message is still poor.
I got hit by this bug too and in my case the fix isn't obvious (it's a mix of an iterator and ). What did you mean by "fixing the get() call"?
It has a parameter type that is a bit bonkers given the type of the Hash, which causes the type inference of the to go off into the weeds I think; doesn't change that there is a bug - this is about the diagnostics after all. is a fixed version of the broken code.
The error message should have been fixed by , marking as .
Change:
| LL | macro_rules! macro_one { () => ("one") } | ---------------------- similarly named macro `macro_one` defined here <ins> | = note: consider importing this macro: two_macros::macro_two </ins> error: aborting due to previous error

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: compiler should suggest importing from (it is in ). Instead, this happened: compiler say cannot find macro 'Component' but did not suggest importing it like other functions <!-- 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 not available in stable.
Change:
position_independent_executables: true, relro_level: RelroLevel::Full, has_elf_tls: true, <ins> crt_static_respected: true, </ins> ..Default::default() } }

Discussion:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .
Change:
<ins> // compile-flags: --error-format=human --color=always // ignore-windows fn short(foo_bar: &Vec<&i32>) -> &i32 { //~ ERROR missing lifetime specifier &12 } fn long( //~ ERROR missing lifetime specifier foo_bar: &Vec<&i32>, something_very_long_so_that_the_line_will_wrap_around__________: i32, ) -> &i32 { &12 } fn long2( //~ ERROR missing lifetime specifier foo_bar: &Vec<&i32>) -> &i32 { &12 } fn main() {} </ins>

Discussion:
The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"<!-- 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 on stable: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Change:
get_u8()); //~ ERROR unreachable expression } fn diverge_second() { <del> call( //~ ERROR unreachable expression </del> <ins> call( //~ ERROR unreachable call </ins> get_u8(), diverge()); }

Discussion:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.
Change:
<ins> //@ build-fail fn main() { let _n = [64][200]; //~^ ERROR this operation will panic at runtime [unconditional_panic] // issue #121126, test index value between 0xFFFF_FF00 and u32::MAX let _n = [64][u32::MAX as usize - 1]; //~^ ERROR this operation will panic at runtime [unconditional_panic] } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'', 'thread 'rustc' panicked at 'assertion failed: value <= 0xFFFFFF00'' 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: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc
I cannot reproduce this with a local stage 1 build nightly and beta show this tho...
maybe this is a rustc miscompile? cc
I can reproduce this on aarch64-apple-darwin, and on beta.
The calls to seem bogus because index is potentially out of range (the valid range is restricted further in comparison to u32):
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
/// 1-3. fn run(self, builder: &Builder<'_>) -> Interned<PathBuf> { let compiler = self.compiler; <ins> let host_dir = builder.out.join(&compiler.host.triple); </ins> let sysroot = if compiler.stage == 0 { <del> builder.out.join(&compiler.host.triple).join("stage0-sysroot") </del> <ins> host_dir.join("stage0-sysroot") } else if builder.download_rustc() { host_dir.join("ci-rustc-sysroot") </ins> } else { <del> builder.out.join(&compiler.host.triple).join(format!("stage{}", compiler.stage)) </del> <ins> host_dir.join(format!("stage{}", compiler.stage)) </ins> }; let _ = fs::remove_dir_all(&sysroot); t!(fs::create_dir_all(&sysroot));

Discussion:
suggests deleting the and directories when using download-rustc, to avoid caching issues like this. still won't do the right thing, but it will at least give a hard error instead of silently using the wrong version. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: in delete the sysroots and folders, not just the current sysroot. Some background info: https://rustc-dev-
claim
Change:
<ins> // Copyright 2016 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. // @has issue_30366/index.html '//a/@href' 'http://www.rust-lang.org/' /// Describe it. [Link somewhere][1]. /// /// [1]: http://www.rust-lang.org/ pub fn here_is_a_fn() { } </ins>

Discussion:
There are times it's nice to be able to include a link in the description of a given item. At present, however, if you try to include a reference link, it fails. Rust: HTML for the item description: However, if you change the first line of the Rust to be an inline reference, the problem goes away. Rust: Generated HTML: It appears (I haven't had a chance to check the implementation yet) that rustdoc is only parsing the first Markdown block element, rather than only keeping the first block element. This probably slightly improves performance, but it produces unexpected results.
Change:
= note: consult the function's documentation for information on how to avoid undefined behavior error[E0133]: call to unsafe function `unsafe_fn` is unsafe and requires unsafe block <del> --> $DIR/unsafe-env.rs:23:5 </del> <ins> --> $DIR/unsafe-env.rs:33:5 </ins> | LL |     unsafe_fn(); |     ^^^^^^^^^^^ call to unsafe function

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: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .
Change:
); return; } <del> for (span, _trivial, non_exhaustive) in field_infos { if let Some((descr, def_id, args, non_exhaustive)) = non_exhaustive { tcx.struct_span_lint_hir( REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS, tcx.hir().local_def_id_to_hir_id(adt.did().expect_local()), span, "zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types", |lint| { let note = if non_exhaustive { "is marked with `#[non_exhaustive]`" } else { "contains private fields" }; let field_ty = tcx.def_path_str_with_args(def_id, args); lint .note(format!("this {descr} contains `{field_ty}`, which {note},  and makes it not a breaking change to become non-zero-sized in the future.")) }, ) </del> <ins> let mut prev_non_exhaustive_1zst = false; for (span, _trivial, non_exhaustive_1zst) in field_infos { if let Some((descr, def_id, args, non_exhaustive)) = non_exhaustive_1zst { // If there are any non-trivial fields, then there can be no non-exhaustive 1-zsts. // Otherwise, it's only an issue if there's >1 non-exhaustive 1-zst. if non_trivial_count > 0 || prev_non_exhaustive_1zst { tcx.struct_span_lint_hir( REPR_TRANSPARENT_EXTERNAL_PRIVATE_FIELDS, tcx.hir().local_def_id_to_hir_id(adt.did().expect_local()), span, "zero-sized fields in `repr(transparent)` cannot  contain external non-exhaustive types", |lint| { let note = if non_exhaustive { "is marked with `#[non_exhaustive]`" } else { "contains private fields" }; let field_ty = tcx.def_path_str_with_args(def_id, args); lint.note(format!( "this {descr} contains `{field_ty}`, which {note},  and makes it not a breaking change to become  non-zero-sized in the future." )) }, ) } else { prev_non_exhaustive_1zst = true; } </ins> } } }

Discussion:
Lifted from I believe this future compatibility warning was badly affected by . Minimal repro: As far as I understand what this issue is about, this code should be 100% fine. This issue is about preventing a previously-accepted struct from ending up with contents which a transparent struct is not allowed to have, after a permissible size increase of a non-exhaustive formerly-ZST from a different crate. That's not possible in the code above. continues to be a valid struct if increases in size. Regression in nightly-2023-09-18: Originally posted by in
Ah... good catch. When a type is not "stably 1-ZST" we should just consider it the one non-1-ZST field. Though given that this is a lint right now the logic is a bit trickier... we need to remember if there was a non-1-ZST field, and then if there was, all 1-ZST fields need to be stably 1-ZST if there wasn't, all but one 1-ZST field need to be stably 1-ZST. Having a nice diagnostic for this could be tricky because ideally we'd point it at two 1-ZST fields that are not stable, and explain "both of these might become non-1-ZST in the future and then this wouldn't build any more". Sadly I won't have the time to work on fixing this quickly. Let me know if you want me to revert the PR.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
use cmake; use cc; <ins> use crate::channel; </ins> use crate::util::{self, exe}; use build_helper::up_to_date; use crate::builder::{Builder, RunConfig, ShouldRun, Step};

Discussion:
Which means that programs that run from a build script, or from cargo in some other way, fail. Steps to Reproduce: a clang binary pointing to clang-8 installed and in your path. install nightly clone && cd $ test Actual results: /usr/bin/clang: relocation error: symbol ZTIN4llvm14FoldingSetBaseE version LLVM8 not defined in file libLLVM-8.so with link time reference Expected results: not so This only happens if ran from cargo, if I run the test executable manually then stuff works, so I suspect this is some LDLIBRARYPATH mungling that cargo or rustup do under the hood. This is technically a regression from , same problem does not exist with rust stable / beta and clang 7. There's a slight chance that there's an issue on how clang-8 is built in Fedora, so I also filed , but I think it's unexpected that clang when called from cargo / build scripts uses rust's , and probably should be avoided. cc
Is invoked from a build script? It is possible that cargo neglects removing the unnecessary or similar environment variables before invoking the script in question. EDIT: oh you wrote that in the report already. I remember there being an issue like this in cargo repo from a long long time ago, but cannot find it now.
cc
See also . We should probably set a custom suffix per . Maybe even include the Rust version to help avoid bootstrap issues like what commit saw. (cc
Yep, I think a suffix of rust version (or maybe LLVM submodule commit?) would be good. I think we'd appreciate a PR for something like that; I would expect it to be a matter of making the version suffix default be or something along those lines.
Sure, that sounds good, I can give that a shot.
I sent with a change that I hope will address this, but see there why I cannot confirm it will :)
triage: P-high, assigning to