jiebi/CodeConvo huggingface dataset:
Change:
running 3 tests test $DIR/doctest-output.rs - (line 8) ... ok <del> test $DIR/doctest-output.rs - ExpandedStruct (line 24) ... ok </del> <ins> test $DIR/doctest-output.rs - ExpandedStruct (line 25) ... ok </ins> test $DIR/doctest-output.rs - foo::bar (line 18) ... ok test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME

Discussion:
The repro repository has everything: Expected behavior is that the diagnostics have: , but they currently have .
cc (as per )
Thanks for opening the issue! I'm surprised since it's an issue that was supposed to be fixed in Just to confirm: which rustc version do you use? Also cc since you're the one who fixed this bug.
This happened with 1.81 most likely — I would take the few secs to check but I’m on a phone right now.
The doctest system needs to use the same infrastructure as the rest of rustdoc.
I can confirm this does fix my repro: ! Would you like a separate issue for the part where it says when really it could normalize the path and just say ?
Yes please!
filed as
Thanks! Gonna take a look in the next days if someone else didn't do it before then.
Change:
<del> //@ known-bug: rust-lang/rust#128621 #![feature(ptr_metadata)] use std::{ops::FnMut, ptr::Pointee}; pub type EmplacerFn<'a, T> = dyn for<'b> FnMut(<T as Pointee>::Metadata) + 'a; pub struct Emplacer<'a, T>(EmplacerFn<'a, T>); impl<'a, T> Emplacer<'a, T> { pub unsafe fn from_fn<'b>(emplacer_fn: &'b mut EmplacerFn<'a, T>) -> &'b mut Self { unsafe { &mut *((emplacer_fn as *mut EmplacerFn<'a, T>) as *mut Self) } } } pub fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'called on an value: NoSolution'', 'thread 'rustc' panicked at 'called on an value: NoSolution'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate -- label +F-ptrmetadata
bisects to :thinking: cc
Minimized: This compiles on stable. ICEs on beta. <details<summaryError output on beta</summary</details label +regression-from-stable-to-beta Of note, the opposite pointer cast fails to compile on stable, beta, and nightly. This seems wrong to me. <details<summaryThe opposite cast</summaryError: </details
Just for context (unsure if relevant here) I see in that PR a question for T-lang about a breaking change at this and in the following FCP that was
So while the breaking change was approved, I believe this code should compile (and definitely not ICE). The issue seems to be that borrowck can't prove a bound (after typeck did). Seeing for you need a projection to trigger the issue () I think there is normalization missing somewhere.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
rust_lld_path } <ins> /// Extract LLD flavor name from the lld-wrapper executable name. fn get_lld_flavor(current_exe_path: &Path) -> Result<&'static str, String> { let stem = current_exe_path.file_stem(); Ok(match stem.and_then(|s| s.to_str()) { Some("ld.lld") => "gnu", Some("ld64.lld") => "darwin", Some("lld-link") => "link", Some("wasm-ld") => "wasm", _ => return Err(format!("{:?}", stem)), }) } </ins> /// Returns the command for invoking rust-lld with the correct flavor. <del> /// LLD only accepts the flavor argument at the first two arguments, so move it there. </del> <ins> /// LLD only accepts the flavor argument at the first two arguments, so pass it there. </ins> /// /// Exits on error. fn get_rust_lld_command(current_exe_path: &Path) -> process::Command { let rust_lld_path = get_rust_lld_path(current_exe_path); let mut command = process::Command::new(rust_lld_path); <del> let mut flavor = None; let args = env::args_os() .skip(1) .filter(|arg| match arg.to_str().and_then(|s| s.strip_prefix("-rustc-lld-flavor=")) { Some(suffix) => { flavor = Some(suffix.to_string()); false } None => true, }) .collect::<Vec<_>>(); </del> <ins> let flavor = get_lld_flavor(current_exe_path).unwrap_or_exit_with("executable has unexpected name"); </ins> command.arg("-flavor"); <del> command.arg(flavor.unwrap_or_exit_with("-rustc-lld-flavor=<flavor> is not passed")); command.args(args); </del> <ins> command.arg(flavor); command.args(env::args_os().skip(1)); </ins> command }

Discussion:
lld-wrapper is unhappy. I tried this code: 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<p</p</detailsNote that this worked for months. This is a regression for me.
Is this issue related to ?
I found no traces of the last working nightly.
Is this issue related to It's certainly somehow related because didn't exist before that, but I don't know how it can happen, is in fact passed as snipped posted in the original message shows.
Do you need more information?
Do you need more information? Yes, output of lld-wrapper with inserted here (You don't need whole compiler build to rebuild lld-wrapper, it's a single-file standalone program, it can be built with directly or with , and then temporarily put into the directory.)
Note that main:rs73 is the failure case.
I see. The command line is to long so it's moved to a temporary file and passed with . Neither lld-wrapper nor original (flavorless) lld support specifying the flavor inside the file. Due to the way in which and work for naked LLD never gets into the file, we should do something similar with too.
I don't know whether rustc has utilities for handling response files
Ok, it's actually clang that packs the command line into a , not rustc, so we cannot control or predict when it happens. That's pretty bad. I guess we'll have to partially revert and use something based on file names, like
Fixed in Sorry for the delay, I should have fixed this two months ago. could you test the fix on Darwin?
Change:
let (regions, types, assoc_bindings) = match path.segments.last().unwrap().parameters { ast::AngleBracketedParameters(ref data) => { <ins> // For now, require that parenthetical notation be used // only with `Fn()` etc. if !this.tcx().sess.features.borrow().unboxed_closures && this.tcx().lang_items.fn_trait_kind(trait_def_id).is_some() { this.tcx().sess.span_err(path.span, "angle-bracket notation is not stable when  used with the `Fn` family of traits, use parentheses"); span_help!(this.tcx().sess, path.span, "add `#![feature(unboxed_closures)]` to  the crate attributes to enable"); } </ins> convert_angle_bracketed_parameters(this, &shifted_rscope, data) } ast::ParenthesizedParameters(ref data) => {

Discussion:
We do not expect to completely "unfeature-gate" unboxed closures for 1.0. We wish to reserve the flexibility to change a few aspects: to variadic generics in place of auto-tupling. the and arguments from input types to (possibly) associated types. (cc ) the coherence story with respect to fn-trait hierarchy. (cc ) To this end we will adjust the features to: [ ] Disallow references to the traits using angle bracket notation [x] Disallow user impls of the traits [x] Disallow direct calls to [x] Disallow parenthetical notation () from being used with anything other than the traits In short, we permit unboxed closures to be used as if they are a language builtin, but disallow (for now) a lot of the more generic uses. We should be able to drop this feature gate shortly after 1.0. cc
Nominating for 1.0 or something. :)
P-backcompat-lang, 1.0.
Note that some of this works today though it ought not, e.g. manually implementing traits.
To expand on comment, the following code fails to compile due to the lack of a feature that should be gated: The current solution is to put on the function.
This was done, or done enough.
Oops, I totally overlooked that is still considered legal. It's important to adjust that too!
Change:
"executables": true, "has-elf-tls": true, "has-rpath": true, <del> "is-builtin": true, </del> "linker-is-gnu": true, "llvm-target": "x86_64-unknown-linux-gnu", "max-atomic-width": 64,

Discussion:
I'm new to Rust and I try to compile a project with a (I'm also new to that project and that project is not well organized.) when I use Makefile to make, the process of making executes and it reports it's a bug, so I'm here. I'm fresh here so if there is some information I don't provide, please tell me and I will try my best to provide it. Thank you! <!-- 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. --here I couldn't provide the example code since I don't really know the minimal set of code to be compiled the source code of the repo is in rustc should be in the nightly mode rust code is in the rust/sel4-rust/ in directory will execute in directory <!-- 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
Thank you for filing an issue! When I click that linked you posted, I get an error. Is it set that other people can view it?
Sorry, I have fixed the typo. Now the link should be right.(next time I will be more careful to check my issue)
The root of the issue is in the target definition file that the repository contains, however there are three other bugs that can be fixed in rustc: should not ICE when invalid external targets are being used; should report the actual target name/file in the error message, not the LLVM target name; target files are allowed to set the property.
The minimal target file to reproduce: with
( is a 404 )
Change:
<ins> // check-fail #[derive(PartialEq, Eq)] pub enum Value { Boolean(Option<bool>), Float(Option<f64>), //~ ERROR the trait bound `f64: Eq` is not satisfied } fn main() { let a = Value::Float(Some(f64::NAN)); assert!(a == a); } </ins>

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
fn_def_id: Option<DefId>, ) -> Result<(), &'tcx FnAbiError<'tcx>> { if abi == SpecAbi::Unadjusted { <ins> // The "unadjusted" ABI passes aggregates in "direct" mode. That's fragile but needed for // some LLVM intrinsics. fn unadjust<'tcx>(arg: &mut ArgAbi<'tcx, Ty<'tcx>>) { // This still uses `PassMode::Pair` for ScalarPair types. That's unlikely to be intended, // but who knows what breaks if we change this now. if matches!(arg.layout.abi, Abi::Aggregate { .. }) { assert!( arg.layout.abi.is_sized(), "'unadjusted' ABI does not support unsized arguments" ); } arg.make_direct_deprecated(); } unadjust(&mut fn_abi.ret); for arg in fn_abi.args.iter_mut() { unadjust(arg); } </ins> return Ok(()); }

Discussion:
Crate bytecount compilation fails with latest nightly on NanoPC-T6 (RK3588 ARM / aarch64). It worked yesterday. I tried this code: Updating index Adding bytecount v0.6.7 to dependencies. Features: generic-simd htmlreport packedsimd runtime-dispatch-simd Updating index Compiling bytecount v0.6.7 Intrinsic has incorrect return type! ptr in function ZN4core9corearch10armshared4neon9generated11vld1qu8x417hd6e0965b4ff7ff22E LLVM ERROR: Broken function found, compilation aborted! error: could not compile (lib) Compiling bytecount v0.6.7 Compiling bytecounttest v0.1.0 (/home/pi/bytecounttest) Finished dev [unoptimized + debuginfo] target(s) in 0.90s Linux NanoPC-T6 5.10.160 SMP Thu Jul 20 15:53:55 CST 2023 aarch64 aarch64 aarch64 GNU/Linux PRETTYNAME="Ubuntu 22.04.3 LTS" NAME="Ubuntu" VERSIONID="22.04" VERSION="22.04.3 LTS (Jammy Jellyfish)" VERSIONCODENAME=jammy ID=ubuntu IDLIKE=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" UBUNTUCODENAME=jammy I expected to see this happen: Finished dev [unoptimized + debuginfo] target(s) in 1.32s Instead, this happened: LLVM ERROR: Broken function found, compilation aborted!
searched nightlies: from nightly-2023-11-19 to nightly-2023-11-20 regressed nightly: nightly-2023-11-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </detailslooks like something in that PR changed ABI behavior and now LLVM and rustc disagree. Don't know who's wrong.
Hm, I don't know how that "unadjusted" ABI stuff works...
should fix this. I am not sure how to add a test.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
TcpWatcher { home: home, handle: handle, <del> stream: StreamWatcher::new(handle), </del> <ins> stream: StreamWatcher::new(handle, true), </ins> refcount: Refcount::new(), read_access: AccessTimeout::new(), write_access: AccessTimeout::new(),

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
pub type_length: usize, } <ins> #[derive(Diagnostic)] #[diag(monomorphize_no_optimized_mir)] pub struct NoOptimizedMir { #[note] pub span: Span, pub crate_name: Symbol, } </ins> pub struct UnusedGenericParamsHint { pub span: Span, pub param_spans: Vec<Span>,

Discussion:
The following scenario used to work fine 1.25.0: This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:
Possibly dupe/related to ?
Yea I think this is a dupe, handling over there
The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?
Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate
I've discovered that if I tell the compiler to emit another type along with like this issue goes away. It makes me suspect this piece of code in : I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.
Triage: still repros:
Since , doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.
PR with fix:
Change:
#![feature(fmt_internals)] #![feature(hashmap_internals)] #![feature(is_sorted)] <del> #![feature(iter_copied)] </del> #![feature(iter_nth_back)] #![feature(iter_once_with)] #![feature(pattern)]

Discussion:
This is a tracking issue for Iterator::copied. Added in . Feature gate: . Related feature: in .
do you feel your comment in is still an objection to the state of this feature, given the response in
So ultimately, was closed meaning that we are comfortable with the specialization. If that specialization is always in place then is a redundant type (and the impls that come with it are also redundant). However, keeping the cost and the type also has less of a risk attached to it so there's a trade-off here. I don't know what the right choice is, but those are the facts as I see them.
Fixed :).
For reference, pattern is quite common according to (%5Cs%5C%7C%5Cs(%3F%3A%26%5Cs%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5Cw%2B%7C%5Cw%2B%5Cs%5C%7C%5Cs%5C%7B%3F%5Cs%5C%5Cs%5Cw%2B)%5Cs%5C%7D%3F%5Cs*%5C)&insensitive=off&space=off&precise=off&sources=on This includes both Iterators and Options, because a regex match cannot separate those.
Is there anything blocking stabilization here? We'd like to suggest this in Clippy, see (The crux is that is clearer than , but gives off the wrong impression)
That's not my call... =D Picking random libs member... is there anything blocking stabilization here?
Doesn't seem like it. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
#![feature(binary_heap_retain)] #![feature(inplace_iteration)] #![feature(iter_map_while)] <del> #![feature(int_bits_const)] </del> #![feature(vecdeque_binary_search)] #![feature(slice_group_by)]

Discussion:
Tracking issue for as introduced by Gated behind .
modify labels: +T-libs
Error: Label P can only be set by Rust team members Please let know if you're having trouble with this bot.
This has been in a few releases, is used in many places in rustc itself, and there's no open questions so far. Time to stabilize? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
We agreed in the libs meeting just now to revert stablization, since the is significant throughout the ecosystem, through . :( We can stabilize it again once that is solved upstream.
Closing this since has been merged.
Change:
<ins> // check-pass #![allow(non_camel_case_types, non_upper_case_globals, static_mut_ref)] pub struct wl_interface { pub version: i32 } pub struct Interface { pub other_interfaces: &'static [&'static Interface], pub c_ptr: Option<&'static wl_interface>, } pub static mut wl_callback_interface: wl_interface = wl_interface { version: 0, }; pub static WL_CALLBACK_INTERFACE: Interface = Interface { other_interfaces: &[], c_ptr: Some(unsafe { &wl_callback_interface }), }; // This static contains a promoted that points to a static that points to a mutable static. pub static WL_SURFACE_INTERFACE: Interface = Interface { other_interfaces: &[&WL_CALLBACK_INTERFACE], c_ptr: None, }; // And another variant of the same thing, this time with interior mutability. use std::sync::OnceLock; static LAZY_INIT: OnceLock<u32> = OnceLock::new(); static LAZY_INIT_REF: &[&OnceLock<u32>] = &[&LAZY_INIT]; fn main() {} </ins>

Discussion:
<!-- 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: I expected to see this happen: it compiles with being reachable through . Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: : modify labels: +regression-from-stable-to-nightly +A-const-eval +T-compiler -regression-untriaged
Like , this issue is not contrived since I also use this technique in in code generation for benchmarks of generic functions, specifically for caching via . The simple example I gave is just a minimal reproduction of the issue. This appears to happen with any internally-mutable types such as .
Yea, this is a duplicate of
this seems similar but the error messages suggest to me that it's not a duplicate. This is about referencing mutable data while the other is a cycle caused by self-referencing.
Let's keep it open an check
Yeah it's the same root cause; adds a test.