jiebi/CodeConvo huggingface dataset:
Change:
let mut align = if pack.is_some() { dl.i8_align } else { dl.aggregate_align }; <del> let mut sized = true; let mut offsets = vec![Size::ZERO; fields.len()]; </del> let mut inverse_memory_index: Vec<u32> = (0..fields.len() as u32).collect(); let mut optimize = !repr.inhibit_struct_field_reordering_opt();

Discussion:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(
Change:
<ins> fn main() { // Should suggest only `std::mem::size_of` let _ = size_of::<usize>(); //~^ ERROR cannot find // Should suggest `std::intrinsics::fabsf64`, // since there is no non-intrinsic to suggest. let _ = fabsf64(1.0); //~^ ERROR cannot find } </ins>

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: Ideally the output should look like: In cases where intrinsics have been stabilised in | it would be useful to suggest these to users first. Especially as using intrinsics generates another error that tells you to prefer stabilized functions in . This would hopefully make handling this error easier for new rust users coming from languages like C/C++ and looking for the equivalent of <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --The output is the same on stable, beta and nightly
I'd be satisfied if we filtered out intrinsics altogether except for when the feature was enabled.
I also get quite annoyed when stable rustc recommends I use unstable features (maybe that should be fixed in an RFC)
Checking the DefId of each suggested path to see if they are annotated with should be doable.
This seems to be harder than I initially thought... so since we emit this "consider importing" suggestion in , we do not have access to it seems. And I have no idea how to extract the attributes from each without ... :thinking:
We might want to consider adding yet another dumping ground field in the itself or in ... But at that point it seems like too much mem consumption for little gain. The other option is to delay the emitting of these errors until later, but that also seems... like a lot of additional complexity :-/
For now, I guess it wouldn't hurt just to filter suggesting paths that are literally (and ) instead of going thru all of the work of adding more info to the . I can put up a PR that does that later.
Change:
target | std | host | notes -------|-----|------|------- `aarch64-apple-ios-macabi` | ? |  | Apple Catalyst on ARM64 <ins> `aarch64-apple-ios-sim` | ? |  | Apple iOS Simulator on ARM64 </ins> `aarch64-apple-tvos` | * |  | ARM64 tvOS `aarch64-unknown-freebsd` | ✓ | ✓ | ARM64 FreeBSD `aarch64-unknown-hermit` | ? |  |

Discussion:
Currently in our application we cannot run the iOS simulator on M1 machines because it is expecting architecture. Forcing using the target can build the project and ship the application but this targets the iOS Device SDK, and will not build in the simulator for testing with this error: should provide an target that uses the iOS Simulator SDK.
Is relevant at all? Can the same path be followed?
Awesome find I'll try doing this! If successful I'll open a similar PR :)
Ran into this now too. Happy to help here as well. Did you already get started?
I did but having trouble I've pushed my changes here: More than happy to work with you on this Jan!
I'll try to get a dev environment set up and then I'll take a look.
I built the toolchain successfully, but when I try to compile my project (with either or ) I'm getting: I think I've missed a setting in the build config I'm using, because the normal nightly compiles fine :( : Edit looks like I will try off :
Yeah, that looks like upstream breakage in because of recent changes. I can try taking your code tomorrow and throw this against my project to see if that fixes my simulator issues.
Yeah I the patch mentioned in that issue and am getting further but: which Xcode still seems to be getting x8664 somewhere: I tried replacing all the with and got closer: but got:
I believe my current version is working but there's something off in my Xcode project that I need to figure out:
Ah, you're building a binary? Yeah, that seems to sort-of work now? I managed to build your branch, my static library is still unchanged. I think we actually need LLVM 12 first to fully enable this ().
It was just a test to see if the simulator is working at all XD. Yeah my file is still saying it's :
Change:
issue = "27800")] <ins> use fmt; </ins> use core::cell::{Cell, UnsafeCell}; use core::marker; use core::ptr;

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
/// When using a future, you generally won't call `poll` directly, but instead /// `await!` the value. #[doc(spotlight)] <del> #[must_use = "futures do nothing unless polled"] </del> <ins> #[must_use = "futures do nothing unless you `.await` or poll them"] </ins> #[stable(feature = "futures_api", since = "1.36.0")] pub trait Future { /// The type of value produced on completion.

Discussion:
The following code (which is awesome!), but the warning is not as clear as it could be: This results in: it should probably say "futures do nothing unless you await them" or something. Most people won't know what 'polled' is all about, I think.
The current note originates from: To change it, simply edit that.
What about ?
In any case, . Just a typo :wink: I would actually expect something in the line of: Btw, I'd love to work on this issue and provide a PR. I'm really looking forward to help Rust just as much as it has helped me thus far!
We may want to work in the fact that you can use somehow. Other than that, sounds pretty good.
what trait does provide ? :astonished:
is equivalent to and is likely to replace it eventually. See I think for now might be good enough and we could tweak later.
That makes sense to me! Am I ok to work on this?
Change:
} for arg in fn_abi.args.iter() { <del> fn_arg_sanity_check(cx, fn_abi, arg); </del> <ins> fn_arg_sanity_check(cx, fn_abi, spec_abi, arg); </ins> } <del> fn_arg_sanity_check(cx, fn_abi, &fn_abi.ret); </del> <ins> fn_arg_sanity_check(cx, fn_abi, spec_abi, &fn_abi.ret); </ins> } // FIXME(eddyb) perhaps group the signature/type-containing (or all of them?)

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:
ty::Adt(adt, substs) if adt.repr().simd() => { let fields = &adt.non_enum_variant().fields; let elem_ty = fields[FieldIdx::from_u32(0)].ty(self.tcx, substs); <del> match elem_ty.kind() { ty::Never | ty::Error(_) => return None, ty::Int(IntTy::I8) | ty::Uint(UintTy::U8) => { Some(InlineAsmType::VecI8(fields.len() as u64)) </del> <ins> let (size, ty) = match elem_ty.kind() { ty::Array(ty, len) => { if let Some(len) = len.try_eval_target_usize(self.tcx, self.tcx.param_env(adt.did())) { (len, *ty) } else { return None; } </ins> } <ins> _ => (fields.len() as u64, elem_ty), }; match ty.kind() { ty::Never | ty::Error(_) => return None, ty::Int(IntTy::I8) | ty::Uint(UintTy::U8) => Some(InlineAsmType::VecI8(size)), </ins> ty::Int(IntTy::I16) | ty::Uint(UintTy::U16) => { <del> Some(InlineAsmType::VecI16(fields.len() as u64)) </del> <ins> Some(InlineAsmType::VecI16(size)) </ins> } ty::Int(IntTy::I32) | ty::Uint(UintTy::U32) => { <del> Some(InlineAsmType::VecI32(fields.len() as u64)) </del> <ins> Some(InlineAsmType::VecI32(size)) </ins> } ty::Int(IntTy::I64) | ty::Uint(UintTy::U64) => { <del> Some(InlineAsmType::VecI64(fields.len() as u64)) </del> <ins> Some(InlineAsmType::VecI64(size)) </ins> } ty::Int(IntTy::I128) | ty::Uint(UintTy::U128) => { <del> Some(InlineAsmType::VecI128(fields.len() as u64)) </del> <ins> Some(InlineAsmType::VecI128(size)) </ins> } ty::Int(IntTy::Isize) | ty::Uint(UintTy::Usize) => { Some(match self.tcx.sess.target.pointer_width { <del> 16 => InlineAsmType::VecI16(fields.len() as u64), 32 => InlineAsmType::VecI32(fields.len() as u64), 64 => InlineAsmType::VecI64(fields.len() as u64), </del> <ins> 16 => InlineAsmType::VecI16(size), 32 => InlineAsmType::VecI32(size), 64 => InlineAsmType::VecI64(size), </ins> _ => unreachable!(), }) } <del> ty::Float(FloatTy::F32) => Some(InlineAsmType::VecF32(fields.len() as u64)), ty::Float(FloatTy::F64) => Some(InlineAsmType::VecF64(fields.len() as u64)), </del> <ins> ty::Float(FloatTy::F32) => Some(InlineAsmType::VecF32(size)), ty::Float(FloatTy::F64) => Some(InlineAsmType::VecF64(size)), </ins> _ => None, } }

Discussion:
I tried this code: I expected to see this happen: I thought this would compile and do as it says since, states that accepts vector types., like f64x8 and i64x8. 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. --: No backtrace applicable.
This is partly a diagnostics issue. The type you refer to in is more abstract, in that we permit it to be compiled in a way that does not actually use an AVX512 register. The type that the documentation is trying to refer to is... very not. Thus it needs a conversion step to/from the "definitely a hardware register" type. The implementation that we should be recommending is: Obviously that's a fair few steps to get from here to there and we can also consider ways to smooth this path further.
It turns out this was actually more possible than I expected by simply changing how inline accepts arguments, and validating that still has an equivalence to a register, so this code now passes:
Change:
warning: the feature `const_generics` is incomplete and may cause the compiler to crash <del> --> $DIR/cannot-infer-type-for-const-param.rs:1:12 </del> <ins> --> $DIR/cannot-infer-type-for-const-param.rs:2:12 </ins> | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ <del> error[E0282]: type annotations needed --> $DIR/cannot-infer-type-for-const-param.rs:10:19 | LL |     let _ = Foo::<3>([1, 2, 3]); |                   ^ cannot infer type for `{integer}` error[E0308]: mismatched types --> $DIR/cannot-infer-type-for-const-param.rs:10:22 | LL |     let _ = Foo::<3>([1, 2, 3]); |                      ^^^^^^^^^ expected `3`, found `3usize` | = note: expected type `[u8; _]` found type `[u8; 3]` error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`. </del>

Discussion:
This very simple example (): results in: . Changing it to use curly braces around does not help.
This does work:
I was actually just experimenting locally to see if I could fix this and I think I have, I could put a PR up in a few minutes.
Change:
self.tcx.hir().span_with_body(self.tcx.local_def_id_to_hir_id(fn_id)), ) { <del> err.multipart_suggestion( </del> <ins> // When the expr is in a match arm's body, we shouldn't add semicolon ';' at the end. // For example: // fn mismatch_types() -> i32 { //     match 1 { //         x => dbg!(x), //     } //     todo!() // } // -------------^^^^^^^- // Don't add semicolon `;` at the end of `dbg!(x)` expr fn is_in_arm<'tcx>(expr: &'tcx hir::Expr<'tcx>, tcx: TyCtxt<'tcx>) -> bool { for (_, node) in tcx.hir().parent_iter(expr.hir_id) { match node { hir::Node::Block(block) => { if let Some(ret) = block.expr && ret.hir_id == expr.hir_id { continue; } } hir::Node::Arm(arm) => { if let hir::ExprKind::Block(block, _) = arm.body.kind && let Some(ret) = block.expr && ret.hir_id == expr.hir_id { return true; } } hir::Node::Expr(e) if let hir::ExprKind::Block(block, _) = e.kind => { if let Some(ret) = block.expr && ret.hir_id == expr.hir_id { continue; } } _ => { return false; } } } false } let mut suggs = vec![(span.shrink_to_lo(), "return ".to_string())]; if !is_in_arm(expr, self.tcx) { suggs.push((span.shrink_to_hi(), ";".to_string())); } err.multipart_suggestion_verbose( </ins> "you might have meant to return this value", <del> vec![ (span.shrink_to_lo(), "return ".to_string()), (span.shrink_to_hi(), ";".to_string()), ], </del> <ins> suggs, </ins> Applicability::MaybeIncorrect, ); }

Discussion:
when using i even got this suggestion recommending i return DefKind from the GlobalCtxt::enter closure, which isn't even remotely the right type. it also seems to only show up when using macros? all around quite strange. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> // Copyright 2014 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. pub fn bar() {} </ins>

Discussion:
and maybe other characters as well? I'm not actually entirely sure what syntax should be used, but I imagine that gcc knows!
Change:
do for t in $CFG_TARGET do <ins> # host bin dir stage0 make_dir $h/stage0/bin </ins> # host lib dir stage0 make_dir $h/stage0/lib <ins> # host test dir stage0 make_dir $h/stage0/test </ins> # target bin dir stage0 make_dir $h/stage0/lib/rustlib/$t/bin # target lib dir stage0 make_dir $h/stage0/lib/rustlib/$t/lib <del> for i in 0 1 2 3 </del> <ins> for i in 1 2 3 </ins> do # host bin dir make_dir $h/stage$i/bin

Discussion:
Fedora x8664 builds install libraries to /usr/lib64 so that 32-bit and 64-bit libraries can coexist on the same system. However, with , the build breaks: It appears that libraries are getting generated at stage0/lib but the build is (maybe?) looking for them at stage0/lib64. The results of : I can only assume the same problem will probably propagate through later stages. This is from doing a bootstrap build of the 1.1.0 tag (i.e., commit ) in rust git, but I've also tried bootstrapping using commit and gotten the same results. I've tried hunting down hard-coded "lib" and replacing it with $CFGLIBDIRRELATIVE. However, that did not resolve the problem, so perhaps something else is going on. Possibly related: , , Output of :
Change:
succeeds_non_ident && preceeds_whitespace_and_paren }); <del> cfgs.map(|i| { </del> <ins> cfgs.flat_map(|i| { </ins> let mut depth = 0; let contents_from = &contents[i..]; for (j, byte) in contents_from.bytes().enumerate() {

Discussion:
Adding some with unbalanced parens in some file in the rust directory makes fail with the following error and backtrace: Which is rather unhelpful.
Looking at means, that should be (or similar) If that wording is okay, I would go and file a PR
Rather than panicking, it would be better to throw an error (e.g. using ). (I think would read slightly better.)
Note that there are other cases where there is an error message like: It seems like we should get the same here too. Edit: Come to think of it, this one might be coming from the compiler.
We could just ignore s with unbalanced parentheses in tidy, as they'll be picked up during compilation. In that case, removing the and adding a comment to that effect should be enough.
Change:
debug!(?param.ident, ?param.ident.span, ?use_span); let elidable = matches!(use_ctxt, LifetimeCtxt::Ref); <ins> let deletion_span = if param.bounds.is_empty() { deletion_span() } else { None }; </ins> <del> let deletion_span = deletion_span(); </del> self.r.lint_buffer.buffer_lint_with_diagnostic( lint::builtin::SINGLE_USE_LIFETIMES, param.id,

Discussion:
This code, as expected, triggers the lint. This is the compiler output: Applying the suggested change, we then get a lifetime error. In this specific instance, must also be changed to . That'll then trigger the lint on , with no ensuing issues. I have not checked this, but I my suspicion is any place where a lifetime bound is also present in the return type (or possibly even a parameter) will result in a similar failure to compile the suggested code. Figuring out which lifetimes to suggest removal of in other parts of the function signature probably isn't straightforward. This example is not theoretical, unfortunately. I ran into this in real-world code and it caused me quite a bit of time to figure out. The example is the minimal reproduction of the bad suggestion.
Should the lint even trigger for ? It's only "used" once directly, but it's also linked to another lifetime through the bound .
cc label +F-lint-singleuselifetimes
Change:
/// types that can be `==` without being identical. See the [module-level /// documentation] for more. /// <del> /// [module-level documentation]: crate::collections#insert-and-complex-keys </del> <ins> /// [module-level documentation]: index.html#insert-and-complex-keys </ins> /// /// # Examples ///

Discussion:
Crate exports from . is documented in quit and has no documentation in quitmacros. When that documentation has a link to , which is only in crate quit, it is unresolved. However, is resolved. Rustdoc gives no warnings with either. You can see the result with quit version 1.1.1 . cc cc
<details<summaryAll of this was wrong, I forgot to use +nightly</summaryThis isn't related to scopes, rustdoc will also fail to resolve these links: Something about the re-export itself is messing it up. </details
The good news is this is unrelated to proc-macros. Here's what I found: This is really strange. I would have expected it to resolve relative to , not relative to the current crate.
Ok, I found the issue: rustdoc and resolve disagree about which crate this is in For , rustdoc passes the original module of String, , and resolve correctly says there's no item named . But for , resolve thinks that refers to the current crate, not to alloc. This explains a lot of other broken links I've been seeing actually: anything that has will be wrong. So you were actually correct to start that this was the same issue as ;) The fix will be a little tricky ... there's no 'change ' button for resolve. There are a few things rustdoc can do: all links relative to the current module (the status quo before ). This is a no-go, because it means links will break on re-exports (). all links relative to the original module. This is what I thought was the current behavior. It means that additional documentation can't refer to things in the current lexical scope, which is non-intuitive (cc ). links in lexical scope: the original docs get resolved in the original module; the new docs get resolved in the module with the re-export. This is the ideal fix but somewhat hard to do because rustdoc doesn't distinguish between the two internally. A possible way to implement 2. is by stripping wherever we see it and resolving relative to the crate root instead of the current module. This is slightly_ hacky but should work fairly reliably.
Marking as P-high after discussing with ; it would be unfortunate to still have this bug on the first release after stabilization.
Change:
|                                                        ^^ | = note: lifetime arguments must be provided before type arguments <ins> = help: reorder the arguments: lifetimes, then types: `<'a, 'b, 'c, T, U, V>` </ins> error: aborting due to 12 previous errors

Discussion:
The current diagnostics are a little ad hoc and rely on counting the number of mismatches (e.g. they will only produce an error for the first mismatch). It would be nice to produce diagnostics like: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is follow up work for
Please give more context on this. I am not sure the error message of which test should be improved.
This is more of the kind of issue opened to avoid forgetting about finishing some work, sorry for the confusion. That is, this is leaving a TODO to themselves about improving the diagnostics from .
Ok. I see. Thanks for the explanation.
That said, if is too busy to work on this, you could talk to them on Discord or Zulip to see what their plans were, and maybe turn this into a mentored issue.
The idea is essentially this. We currently emit errors telling the user that the generic arguments they provide are in the wrong order: However, what we'd like to do is suggest reordering the parameters, and let rustfix automatically apply the suggestion. I don't have the bandwidth to work on this at the moment, or any time soon, so if anyone is interested in tackling it, I'll be happy to mentor the issue.
would you mind if I take this up?
you're very welcome to! Let me know if you need any guidance in tackling this issue!
claim