jiebi/CodeConvo huggingface dataset:
Code change:
emit, generate_link_to_definition, call_locations, <ins> no_emit_shared: false, </ins> }, crate_name, output_format,

Related discussion:
text: <!-- 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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .
Code change:
<ins> //@ check-pass //@ edition: 2021 // issue: rust-lang/rust#123697 #![feature(async_closure)] struct S { t: i32 } fn test(s: &S, t: &i32) { async || { println!("{}", s.t); println!("{}", t); }; } fn main() {} </ins>

Related discussion:
text: This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.
Code change:
/// Basic usage: /// /// ``` <del> /// #![feature(nonzero_is_power_of_two)] /// </del> #[doc = concat!("let eight = std::num::", stringify!($Ty), "::new(8).unwrap();")] /// assert!(eight.is_power_of_two()); #[doc = concat!("let ten = std::num::", stringify!($Ty), "::new(10).unwrap();")] /// assert!(!ten.is_power_of_two()); /// ``` #[must_use] <del> #[unstable(feature = "nonzero_is_power_of_two", issue = "81106")] </del> <ins> #[stable(feature = "nonzero_is_power_of_two", since = "1.59.0")] </ins> #[inline] pub const fn is_power_of_two(self) -> bool { // LLVM 11 normalizes `unchecked_sub(x, 1) & x == 0` to the implementation seen here.

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for (and friends for the other unsigned types). Like (), this generates simpler code than the underlying integer type because it can avoid a separate zero check. <!-- Include a short description of the feature. --<!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] Implementation: [ ] Final commenting period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Great, something else that just breaks my code. Sigh.
Code change:
/// Basic usage: /// /// ``` <del> /// #![feature(nonzero_is_power_of_two)] /// </del> #[doc = concat!("let eight = std::num::", stringify!($Ty), "::new(8).unwrap();")] /// assert!(eight.is_power_of_two()); #[doc = concat!("let ten = std::num::", stringify!($Ty), "::new(10).unwrap();")] /// assert!(!ten.is_power_of_two()); /// ``` #[must_use] <del> #[unstable(feature = "nonzero_is_power_of_two", issue = "81106")] </del> <ins> #[stable(feature = "nonzero_is_power_of_two", since = "1.59.0")] </ins> #[inline] pub const fn is_power_of_two(self) -> bool { // LLVM 11 normalizes `unchecked_sub(x, 1) & x == 0` to the implementation seen here.

Related discussion:
text: With , I would like to propose  for stabilization as well. (I think this in the tracking issue is the right thing to do now, rather than filing a PR?)
shall we 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. This will be merged soon.
Code change:
fn process() { let handles: Vec<_> = (0..10).map(|_| { thread::spawn(|| { <del> let mut _x = 0; </del> <ins> let mut x = 0; </ins> for _ in (0..5_000_000) { <del> _x += 1 </del> <ins> x += 1 </ins> } <ins> x </ins> }) }).collect(); for h in handles { <del> h.join().ok().expect("Could not join a thread!"); </del> <ins> println!("Thread finished with count={}", h.join().map_err(|_| "Could not join a thread!").unwrap()); </ins> } <ins> println!("done!"); </ins> } ``` Some of this should look familiar from previous examples. We spin up ten threads, collecting them into a `handles` vector. Inside of each thread, we <del> loop five million times, and add one to `_x` each time. Why the underscore? Well, if we remove it and compile: ```bash $ cargo build Compiling embed v0.1.0 (file:///home/steve/src/embed) src/lib.rs:3:1: 16:2 warning: function is never used: `process`, #[warn(dead_code)] on by default src/lib.rs:3 fn process() { src/lib.rs:4     let handles: Vec<_> = (0..10).map(|_| { src/lib.rs:5         thread::spawn(|| { src/lib.rs:6             let mut x = 0; src/lib.rs:7             for _ in (0..5_000_000) { src/lib.rs:8                 x += 1 ... src/lib.rs:6:17: 6:22 warning: variable `x` is assigned to, but never used, #[warn(unused_variables)] on by default src/lib.rs:6             let mut x = 0; ^~~~~ ``` That first warning is because we are building a library. If we had a test for this function, the warning would go away. But for now, it’s never called. The second is related to `x` versus `_x`. Because we never actually _do_ anything with `x`, we get a warning about it. In our case, that’s perfectly okay, as we’re just trying to waste CPU cycles. Prefixing `x` with the underscore removes the warning. Finally, we join on each thread. </del> <ins> loop five million times, and add one to `x` each time. Finally, we join on each thread. </ins> Right now, however, this is a Rust library, and it doesn’t expose anything that’s callable from C. If we tried to hook this up to another language right

Related discussion:
text: I'm running the example from the section in Rust Book. I noticed that when I embed the code into Python and execute it, the execution time does not depend on the counter size (initially set to 5 million in the book). Although the text suggests it should (we are comparing execution time in different languages after all). However, if I modify the code to return, say, the count in the spawned thread (and later do , the execution time starts depending on the number of iterations. This seems not to depend on the number of iterations: This seems to get slower with more iterations (as it should): Why is this so? Is this some sort of compiler optimisation that removes the loop execution altogether? Should the code in the book be updated?
I thought that was enough to kill the optimization, but I guess not. Yes, it should be updated. (I think you can get rid of the `` too...)
Code change:
} #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_process_output_error() { let Output { status, stdout, stderr } = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "mkdir ."]).output().unwrap()

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
// Check magic number let magic = t!(read_le_u16(file)); <del> if magic != 0x011A { return Err(format!("invalid magic number: expected {:x}, found {:x}", 0x011A, magic)); } </del> <ins> let extended = match magic { 0o0432 => false, 0o01036 => true, _ => return Err(format!("invalid magic number, found {:o}", magic)), }; </ins> // According to the spec, these fields must be >= -1 where -1 means that the feature is not // supported. Using 0 instead of -1 works because we skip sections with length 0.

Related discussion:
text: does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .
Code change:
// Check magic number let magic = t!(read_le_u16(file)); <del> if magic != 0x011A { return Err(format!("invalid magic number: expected {:x}, found {:x}", 0x011A, magic)); } </del> <ins> let extended = match magic { 0o0432 => false, 0o01036 => true, _ => return Err(format!("invalid magic number, found {:o}", magic)), }; </ins> // According to the spec, these fields must be >= -1 where -1 means that the feature is not // supported. Using 0 instead of -1 works because we skip sections with length 0.

Related discussion:
text: I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.
Code change:
<ins> error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/issue-66286.rs:8:22 | LL | pub extern fn foo(_: Vec(u32)) -> u32 { |                      ^^^^^^^^ |                      | |                      only `Fn` traits may use parentheses |                      help: use angle brackets instead: `Vec<u32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0214`. </ins>

Related discussion:
text: Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.
Code change:
} #[cfg(all( <del> any(target_arch = "aarch64", target_arch = "powerpc", target_arch = "x86_64"), </del> <ins> any( target_arch = "aarch64", target_arch = "powerpc", target_arch = "s390x", target_arch = "x86_64" ), </ins> any(not(target_arch = "aarch64"), not(any(target_os = "macos", target_os = "ios"))), not(target_family = "wasm"), not(target_arch = "asmjs"),

Related discussion:
text: fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.
Code change:
<ins> error: `extern` fn uses type `NotSafe`, which is not FFI-safe --> $DIR/lint-ctypes-113436-1.rs:22:22 | LL | extern "C" fn bar(x: Bar) -> Bar { |                      ^^^ not FFI-safe | = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout note: the type is defined here --> $DIR/lint-ctypes-113436-1.rs:13:1 | LL | struct NotSafe(u32); | ^^^^^^^^^^^^^^ note: the lint level is defined here --> $DIR/lint-ctypes-113436-1.rs:1:9 | LL | #![deny(improper_ctypes_definitions)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: `extern` fn uses type `NotSafe`, which is not FFI-safe --> $DIR/lint-ctypes-113436-1.rs:22:30 | LL | extern "C" fn bar(x: Bar) -> Bar { |                              ^^^ not FFI-safe | = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout note: the type is defined here --> $DIR/lint-ctypes-113436-1.rs:13:1 | LL | struct NotSafe(u32); | ^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion
Code change:
pub fn foo(arg: Option<&Vec<i32>>) -> Option<&[i32]> { arg //~ ERROR 5:5: 5:8: mismatched types [E0308] } <ins> pub fn bar(arg: Option<&Vec<i32>>) -> &[i32] { arg.unwrap_or(&[]) //~ ERROR 9:19: 9:22: mismatched types [E0308] } pub fn barzz<'a>(arg: Option<&'a Vec<i32>>, v: &'a [i32]) -> &'a [i32] { arg.unwrap_or(v) //~ ERROR 13:19: 13:20: mismatched types [E0308] } pub fn convert_result(arg: Result<&Vec<i32>, ()>) -> &[i32] { arg.unwrap_or(&[]) //~ ERROR 17:19: 17:22: mismatched types [E0308] } </ins>

Related discussion:
text: Given : Current error, for the motivating use case above: It should be possible for rustc to suggest replacing this specific instantiation of with . Maybe similarly for some other common cases: . Originally posted by in label -T-rustdoc T-compiler
Code change:
<ins> error[E0706]: trait fns cannot be declared `async` --> $DIR/async-trait-fn.rs:3:5 | LL |     async fn foo() {} |     ^^^^^^^^^^^^^^^^^ | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error[E0706]: trait fns cannot be declared `async` --> $DIR/async-trait-fn.rs:4:5 | LL |     async fn bar(&self) {} |     ^^^^^^^^^^^^^^^^^^^^^^ | = note: `async` trait functions are not currently supported = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0706`. </ins>

Related discussion:
text: we currently emit We should tell people that trait functions are not possible , and possibly point them to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Created
Code change:
#[rustc_doc_primitive = "f128"] #[doc(alias = "quad")] <del> /// A 128-bit floating point type (specifically, the "binary128" type defined in IEEE 754-2008). </del> <ins> /// A 128-bit floating-point type (specifically, the "binary128" type defined in IEEE 754-2008). </ins> /// /// This type is very similar to [`prim@f32`] and [`prim@f64`], but has increased precision by using twice /// as many bits as `f64`. Please see [the documentation for `f32`](prim@f32) or [Wikipedia on

Related discussion:
text: Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .
Code change:
<ins> #[doc(hidden)] pub enum HiddenType {} #[doc(hidden)] pub trait HiddenTrait {} </ins>

Related discussion:
text: Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for