jiebi/CodeConvo huggingface dataset:
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: item: &Item, hir_id: HirId, doc: &'md str, <ins> resolutions: &DocLinkResMap, </ins> ) -> Option<()> { let mut broken_line_callback = |link: BrokenLink<'md>| Some((link.reference, "".into())); let mut offset_iter = Parser::new_with_broken_link_callback(
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: Some(&mut broken_line_callback), ) .into_offset_iter(); <del> let item_id = item.def_id()?; let module_id = match cx.tcx.def_kind(item_id) { DefKind::Mod if item.inner_docs(cx.tcx) => item_id, _ => find_nearest_parent_module(cx.tcx, item_id).unwrap(), }; let resolutions = cx.tcx.doc_link_resolutions(module_id); </del> while let Some((event, link_range)) = offset_iter.next() { match event {
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: <ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </ins>
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: <ins> error: redundant explicit link target --> $DIR/issue-120444-1.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-1.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 previous error </ins>
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: <ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] pub mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </ins>
Code 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Related discussion:
text: <ins> error: redundant explicit link target --> $DIR/issue-120444-2.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-2.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 previous error </ins>
Code change:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

Related discussion:
text: "arch": "x86_64", "cpu": "x86-64", "crt-static-respected": true, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "dynamic-linking": true, "env": "gnu", "has-rpath": true,
Code change:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

Related discussion:
text: "arch": "x86_64", "cpu": "x86-64", "crt-static-respected": true, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "dynamic-linking": true, "env": "gnu", "executables": true,
Code change:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

Related discussion:
text: { <del> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-f80:32-n8:16:32-S128", </del> <ins> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128", </ins> "linker-flavor": "gcc", "llvm-target": "i686-unknown-linux-gnu", "target-endian": "little",
Code change:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

Related discussion:
text: { "pre-link-args": {"gcc": ["-m64"]}, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "linker-flavor": "gcc", "llvm-target": "x86_64-unknown-linux-gnu", "target-endian": "little",
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: } } <del> fn install_llvm_file(builder: &Builder<'_>, source: &Path, destination: &Path) { </del> <ins> fn install_llvm_file( builder: &Builder<'_>, source: &Path, destination: &Path, install_symlink: bool, ) { </ins> if builder.config.dry_run() { return; } <del> builder.install(source, destination, 0o644); </del> <ins> if source.is_symlink() { // If we have a symlink like libLLVM-18.so -> libLLVM.so.18.1, install the target of the // symlink, which is what will actually get loaded at runtime. builder.install(&t!(fs::canonicalize(source)), destination, 0o644); if install_symlink { // If requested, also install the symlink. This is used by download-ci-llvm. let full_dest = destination.join(source.file_name().unwrap()); builder.copy(&source, &full_dest); } } else { builder.install(&source, destination, 0o644); } </ins> } /// Maybe add LLVM object files to the given destination lib-dir. Allows either static or dynamic linking. /// /// Returns whether the files were actually copied. <del> fn maybe_install_llvm(builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path) -> bool { </del> <ins> fn maybe_install_llvm( builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path, install_symlink: bool, ) -> bool { </ins> // If the LLVM was externally provided, then we don't currently copy // artifacts into the sysroot. This is not necessarily the right // choice (in particular, it will require the LLVM dylib to be in
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: } else { PathBuf::from(file) }; <del> install_llvm_file(builder, &file, dst_libdir); </del> <ins> install_llvm_file(builder, &file, dst_libdir, install_symlink); </ins> } !builder.config.dry_run() } else {
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // dynamically linked; it is already included into librustc_llvm // statically. if builder.llvm_link_shared() { <del> maybe_install_llvm(builder, target, &dst_libdir); </del> <ins> maybe_install_llvm(builder, target, &dst_libdir, false); </ins> } }
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: let mut tarball = Tarball::new(builder, "rust-dev", &target.triple); tarball.set_overlay(OverlayKind::LLVM); <ins> // LLVM requires a shared object symlink to exist on some platforms. tarball.permit_symlinks(true); </ins> builder.ensure(crate::core::build_steps::llvm::Llvm { target });
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. let dst_libdir = tarball.image_dir().join("lib"); <del> maybe_install_llvm(builder, target, &dst_libdir); </del> <ins> maybe_install_llvm(builder, target, &dst_libdir, true); </ins> let link_type = if builder.llvm_link_shared() { "dynamic" } else { "static" }; t!(std::fs::write(tarball.image_dir().join("link-type.txt"), link_type), dst_libdir);
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: let out_dir = builder.llvm_out(target); let mut llvm_config_ret_dir = builder.llvm_out(builder.config.build); <del> if (!builder.config.build.is_msvc() || builder.ninja()) && !builder.config.llvm_from_ci { llvm_config_ret_dir.push("build"); } </del> llvm_config_ret_dir.push("bin"); let build_llvm_config = llvm_config_ret_dir.join(exe("llvm-config", builder.config.build)); let llvm_cmake_dir = out_dir.join("lib/cmake/llvm");
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: <del> Subproject commit 9ea7f739f257b049a65deeb1f2455bb2ea021cfa </del> <ins> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </ins>
Code change:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

Related discussion:
text: })?; let libdir = env.build_artifacts().join("stage2").join("lib"); <del> let llvm_lib = io::find_file_in_dir(&libdir, "libLLVM", ".so")?; </del> <ins> // The actual name will be something like libLLVM.so.18.1-rust-dev. let llvm_lib = io::find_file_in_dir(&libdir, "libLLVM.so", "")?; </ins> log::info!("Optimizing {llvm_lib} with BOLT");
Code change:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

Related discussion:
text: resolve_consider_marking_as_pub = consider marking `{$ident}` as `pub` in the imported module <ins> resolve_consider_move_macro_position = consider moving the definition of `{$ident}` before this call </ins> resolve_const_not_member_of_trait = const `{$const_}` is not a member of trait `{$trait_}` .label = not a member of trait `{$trait_}`
Code change:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

Related discussion:
text: attempt to use a non-constant value in a constant .suggestion = try using `Self` <ins> resolve_macro_defined_later = a macro with the same name exists, but it appears later at here </ins> resolve_macro_expected_found = expected {$expected}, found {$found} `{$macro_path}`