jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-106443-sugg-clone-for-arg.rs:11:9 | LL |     foo(s); |     --- ^ expected struct `S`, found `&S` |     | |     arguments to this function are incorrect | note: function defined here --> $DIR/issue-106443-sugg-clone-for-arg.rs:7:4 | LL | fn foo(_: S) {} |    ^^^ ---- help: consider using clone here | LL |     foo(s.clone()); |          ++++++++ error[E0308]: mismatched types --> $DIR/issue-106443-sugg-clone-for-arg.rs:17:9 | LL |     bar(t); |     --- ^ expected struct `T`, found `&T` |     | |     arguments to this function are incorrect | note: function defined here --> $DIR/issue-106443-sugg-clone-for-arg.rs:14:4 | LL | fn bar(_: T) {} |    ^^^ ---- error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
<ins> // ignore-tidy-cr // compile-pass // This file checks the spans of intra-link warnings in a file with CRLF line endings. The // .gitattributes file in this directory should enforce it. /// [error] pub struct A; /// /// docs [error1] /// docs [error2] /// pub struct B; /** * This is a multi-line comment. * * It also has an [error]. */ pub struct C; </ins>

Discussion:
Given the following source: The span conversion calculation in the error reporting will give the wrong offset when reporting the resolution failure, leading to a confusing report: Strangely enough, putting either the leading or the closing on its own line will cause the report to change to something that looks correct, if a little too broad: I believe the code at fault is this section here: Because it assumes that every doc comment will have a padding of 3 characters (the or ), it includes that in its calculation of each line's offset. However, for block-style comments, this assumption is false.
I'm working on this.
You can also reproduce this with unsugared docs:
Change:
"compiletest_rs", "directories", "env_logger 0.6.0", <ins> "getrandom", </ins> "hex", "log", "num-traits",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
Needs a xargo fix, which is on its way at
Change:
run_lints!(cx, check_crate, early_passes, krate); ast_visit::walk_crate(cx, krate); <ins> run_lints!(cx, check_crate_post, early_passes, krate); </ins> }); // Put the lint store back in the session.

Discussion:
For clippy's lint, I made use of a so I could stop clippy from linting the same macro multiple times while being reasonably fast. However, this unfortunately means the lint ignores .. attributes below the crate level. To solve this and other related problems, I propose any of allow a lint to check anything from anywhere in the analysis by moving up the parent chain to check the level allow a lint to opt out of calls for the duration of a specific node including its child nodes add methods to the {Early, Late}LintPass trait, so lints can decide themselves The third option is probably the easiest to implement, yet the most flexible. This would bring the trait closer to other stream parser implementations like SAX.
Seeing that we already have a few, _post methods, I think adding some more will be an acceptable solution here. I'll have a PR shortly.
Change:
/// # Examples /// /// ``` <del> /// #![feature(slice_ptr_get, nonnull_slice_from_raw_parts)] </del> <ins> /// #![feature(slice_ptr_get)] </ins> /// use std::ptr::NonNull; /// /// let x = &mut [1, 2, 4];

Discussion:
This is a tracking issue for the method proposed in PR The feature gates for the issue are , and for using as a . Docs: [x] Implementation: [x] FCP: [ ] Stabilization PR
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] [ ] 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.
I'm willing to file the stabilization report for this if the library team is on board for stabilization.
I'd certainly appreciate one!
: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.
Change:
let val = if type_is_sized(cx.tcx(), field_ty) { llfld_a } else { <ins> // FIXME(#36457) -- we should pass unsized values as two arguments </ins> let scratch = alloc_ty(cx, field_ty, "__fat_ptr_iter"); Store(cx, llfld_a, get_dataptr(cx, scratch)); Store(cx, value.meta, get_meta(cx, scratch));

Discussion:
The following successfully typechecks on , but generates an LLVM assertion failure: Error: Note that replacing with (and making mutable) allows compilation to succeed.
First occurs in nightly-2016-08-03 which turns on mir by default, does not occur on nightly-2016-08-03 with -Z orbit=off.
Using this was introduced between and ().
Problem seems to be that we call the with a fat pointer as 2 arguments, but it expects a pointer to a tuple.
I have a fix for this, running the full locally now to see if I broke anything else on the way.
Change:
<ins> error: `extern` fn uses type `[u8]`, which is not FFI-safe --> $DIR/extern-C-fnptr-lints-slices.rs:5:14 | LL | pub type F = extern "C" fn(&[u8]); |              ^^^^^^^^^^^^^^^^^^^^ not FFI-safe | = help: consider using a raw pointer instead = note: slices have no C equivalent note: the lint level is defined here --> $DIR/extern-C-fnptr-lints-slices.rs:1:8 | LL | #[deny(improper_ctypes_definitions)] |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>

Discussion:
I tried this code: I expected to see this happen: should trigger for this definition. Instead, this happened: It is not linted.
Change:
<del> // edition:2018 #![feature(async_await)] #[path = "../auxiliary/arc_wake.rs"] mod arc_wake; use std::pin::Pin; use std::future::Future; use std::sync::{ Arc, atomic::{self, AtomicUsize}, }; use std::task::{Context, Poll}; use arc_wake::ArcWake; struct Counter { wakes: AtomicUsize, } impl ArcWake for Counter { fn wake(self: Arc<Self>) { Self::wake_by_ref(&self) } fn wake_by_ref(arc_self: &Arc<Self>) { arc_self.wakes.fetch_add(1, atomic::Ordering::SeqCst); } } struct WakeOnceThenComplete(bool, u8); impl Future for WakeOnceThenComplete { type Output = u8; fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<u8> { if self.0 { Poll::Ready(self.1) } else { cx.waker().wake_by_ref(); self.0 = true; Poll::Pending } } } fn wait(fut: impl Future<Output = u8>) -> u8 { let mut fut = Box::pin(fut); let counter = Arc::new(Counter { wakes: AtomicUsize::new(0) }); let waker = ArcWake::into_waker(counter.clone()); let mut cx = Context::from_waker(&waker); loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(out) => return out, Poll::Pending => (), } } } fn base() -> WakeOnceThenComplete { WakeOnceThenComplete(false, 1) } async fn await1_level1() -> u8 { base().await } async fn await2_level1() -> u8 { base().await + base().await } async fn await3_level1() -> u8 { base().await + base().await + base().await } async fn await3_level2() -> u8 { await3_level1().await + await3_level1().await + await3_level1().await } async fn await3_level3() -> u8 { await3_level2().await + await3_level2().await + await3_level2().await } async fn await3_level4() -> u8 { await3_level3().await + await3_level3().await + await3_level3().await } async fn await3_level5() -> u8 { await3_level4().await + await3_level4().await + await3_level4().await } fn main() { assert_eq!(2, std::mem::size_of_val(&base())); assert_eq!(8, std::mem::size_of_val(&await1_level1())); assert_eq!(12, std::mem::size_of_val(&await2_level1())); assert_eq!(12, std::mem::size_of_val(&await3_level1())); assert_eq!(20, std::mem::size_of_val(&await3_level2())); assert_eq!(28, std::mem::size_of_val(&await3_level3())); assert_eq!(36, std::mem::size_of_val(&await3_level4())); assert_eq!(44, std::mem::size_of_val(&await3_level5())); assert_eq!(1,   wait(base())); assert_eq!(1,   wait(await1_level1())); assert_eq!(2,   wait(await2_level1())); assert_eq!(3,   wait(await3_level1())); assert_eq!(9,   wait(await3_level2())); assert_eq!(27,  wait(await3_level3())); assert_eq!(81,  wait(await3_level4())); assert_eq!(243, wait(await3_level5())); } </del>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
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. // Check that we correctly prevent users from making trait objects // from traits with associated consts. #![feature(associated_consts)] trait Bar { const X: usize; } fn make_bar<T:Bar>(t: &T) -> &Bar { //~^ ERROR E0038 //~| NOTE the trait cannot contain associated consts like `X` //~| NOTE the trait `Bar` cannot be made into an object t } fn main() { } </ins>

Discussion:
The following code compiles: Furthermore, adding the line to causes an ICE:
I think the code should be legal to compile. It's impossible to get the value of from a variable (there's no such thing as where is a binding of type ).
Well it shouldn't compile
I don't know if this can lead to unsoundness or not. Correct me.
says no
Update on this, the example in the original post compiles today. But this ICEs: AFAICT there are two options here: consts are not object safe, just like associated (static) functions. consts must all be specified, just like associated types. I think its sensible to start with the first. The second makes more sense in the context of a world with const params, but the first can be extended to the second. It might also make sense some day to allow clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).
Can't associated consts be part of the vtable/fat pointers?
Associated consts are inlined at compiletime, they can't have a value which is determined at runtime. This is a hard requirement for making things like const fn and const generics work. Associated statics could be object safe if they existed.
I think that having to write: instead of just: or is a pain. The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.
The value is not determined at compile time for the virtually dispatched type (the trait object type). What you want is the fields in traits RFC.
I did not say otherwise (the value is only determined at compile-time for the types that implement , not for itself or trait objects). What I did say is that currently there is no way to access this value at run-time without in my opinion unnecessary boilerplate but there should be one.
Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).
Will they be object-safe in the future? I mean if "fn foo() -u8 where Self: Sized;" is already safe why are consts not?
Change:
[[package]] name = "git2-curl" <del> version = "0.11.0" </del> <ins> version = "0.12.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "cd6527e480187ce19aaf4fa6acfb7657b25628ce31cb8ffabdfca3bf731524c5" </del> <ins> checksum = "d2559abb1d87d27668d31bd868a000f0e2e0065d10e78961b62da95d7a7f1cc7" </ins> dependencies = [ "curl", "git2",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
self.clear_if_dirty(&my_out, &rustdoc); } <del> cargo.env("CARGO_TARGET_DIR", &out_dir).arg(cmd).arg("-Zconfig-profile"); </del> <ins> cargo.env("CARGO_TARGET_DIR", &out_dir).arg(cmd); if !self.local_rebuild { cargo.arg("-Zconfig-profile"); } </ins> let profile_var = |name: &str| { let profile = if self.config.rust_optimize { "RELEASE" } else { "DEV" };

Discussion:
Seems to be a cargo issue: -Z Maybe cargo 0.44.0 should just ignore this flag with a warning instead?
Change:
<del> Subproject commit 670e5f673acb736acbfce65e0ffe2c8cd115b93f </del> <ins> Subproject commit 9567f08afc94332d59025744f3a8198104949d3c </ins>

Discussion:
This code has differing behavior in debug and release (): When compiled in debug mode (without optimizations), the program produces no output. When compiled in release mode (with optimizations), the assertion fails: (This output doesn't make sense to me: how can they be unequal, but both negative infinity?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Here's another program with similar behavior, failing only in release. Not sure if it's the same issue.
This function, based on the first code example, is misoptimized to unconditionally return false (): This was not misoptimized before rustc 1.25, which upgraded LLVM to version 6.0. This appears to be a misoptimization by LLVM (Unless there's some allowed variability to do with the signs of zeroes that I'm not aware of?) label A-LLVM A-floating-point I-unsound T-compiler regression-from-stable-to-stable
This C code miscompiled under Clang as well: Confirmed to be a LLVM bug.
The second example does actually appear to be different - it doesn't miscompile until rustc 1.30 () (which upgraded to LLVM 8).
Upstream issue:
possibly related:
WG-prioritization assigning priority (). label -I-prioritize +P-high
T-compiler P-high review assign (also, notes that since upstream is fixed now, this issue should eventually get resolved by either an LLVM upgrade or by cherry-picking the fix to Rust's LLVM fork.)
Does that fix take care of the ?
To answer my own question: both examples are fixed for me after updating rustc nightly from ( 2022-09-29) to ( 2022-09-30)
Should we add a test for this?
Change:
fn lookup_and_handle_definition(&mut self, id: &ast::NodeId) { self.tcx.def_map.borrow().find(id).map(|def| { match def { <ins> &def::DefConst(_) => { self.check_def_id(def.def_id()) } _ if self.ignore_non_const_paths => (), </ins> &def::DefPrimTy(_) => (), &def::DefVariant(enum_id, variant_id, _) => { self.check_def_id(enum_id);

Discussion:
This may be related to but here is some test code for this specific case: Which prints: Ideally this would not issue a warning.
Change:
span, "silent safe transmute error" ); } <ins> GetSafeTransmuteErrorAndReason::Default => { (err_msg, None) } </ins> GetSafeTransmuteErrorAndReason::Error { err_msg, safe_transmute_explanation,

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
<ins> // aux-build:bad-region.rs // edition:2021 #![allow(async_fn_in_trait)] extern crate bad_region as jewel; use jewel::BleRadio; pub struct Radio {} impl BleRadio for Radio { //~^ ERROR implicit elided lifetime not allowed here async fn transmit(&mut self) {} } fn main() {} </ins>

Discussion:
I was developing one trait in one crate, changing it to use a lifetime, and forgot to add it to the other crate's implementation. The compiler shows de correct error message but breaks. If I fix the code, adding the lifetime to the trait, de compiler works. If it is in the same crate also works. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Same backtrace as .
Thanks for the minimized test! I'll fix this tomorrow.

<!-- 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. --While I was trying to add lifetimes for picoserve's I got into ICE (1.) had a dep of picoserve as 2. That code isn't finished and should not compile yet <!-- 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. --: has ice files
rustc 1.75.0 ( 2023-12-21) binary: rustc commit-hash: commit-date: 2023-12-21 host: x86_64-unknown-linux-gnu release: 1.75.0 LLVM version: 17.0.6 Here ICE is also present
Backtrace from one of the linked files pasted below for the sake of searchability and preservation: <details<summaryBacktrace</summary</details
Change:
); } <del> fn check_bb(&self, location: Location, bb: BasicBlock) { if self.body.basic_blocks().get(bb).is_none() { </del> <ins> fn check_edge(&self, location: Location, bb: BasicBlock, edge_kind: EdgeKind) { if let Some(bb) = self.body.basic_blocks().get(bb) { let src = self.body.basic_blocks().get(location.block).unwrap(); match (src.is_cleanup, bb.is_cleanup, edge_kind) { // Non-cleanup blocks can jump to non-cleanup blocks along non-unwind edges (false, false, EdgeKind::Normal) // Non-cleanup blocks can jump to cleanup blocks along unwind edges | (false, true, EdgeKind::Unwind) // Cleanup blocks can jump to cleanup blocks along non-unwind edges | (true, true, EdgeKind::Normal) => {} // All other jumps are invalid _ => { self.fail( location, format!( "{:?} edge to {:?} violates unwind invariants (cleanup {:?} -> {:?})", edge_kind, bb, src.is_cleanup, bb.is_cleanup, ) ) } } } else { </ins> self.fail(location, format!("encountered jump to invalid basic block {:?}", bb)) } }

Discussion:
Blocks that are part of unwinding code always need to marked as . This seems like an easy thing to check in the validation pass. I believe this would have caught a bug in the generator transform (a pretty long time ago). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Good point! Moreover, cleanup block terminators should also only jump to cleanup blocks, and other terminators should only jump to non-cleanup blocks. Basically, unwind edges must be the only ones that cross the "cleanup to non-cleanup" boundary. (Miri is already checking this.)
claim
Change:
fn check_local_or_return_ty(&mut self, ty: Ty<'tcx>, local: Local) { let kind = self.body.local_kind(local); <del> for ty in ty.walk() { let ty = match ty.unpack() { GenericArgKind::Type(ty) => ty, // No constraints on lifetimes or constants, except potentially // constants' types, but `walk` will get to them as well. GenericArgKind::Lifetime(_) | GenericArgKind::Const(_) => continue, }; </del> <ins> let mut visitor = LocalReturnTyVisitor { kind, checker: self }; </ins> <del> match *ty.kind() { ty::Ref(_, _, hir::Mutability::Mut) => self.check_op(ops::ty::MutRef(kind)), _ => {} } } </del> <ins> visitor.visit_ty(ty); </ins> } fn check_mut_borrow(&mut self, local: Local, kind: hir::BorrowKind) {

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
self.token.span, &format!("expected identifier, found {}", self.this_token_descr()), ); <ins> let valid_follow = &[ TokenKind::Eq, TokenKind::Colon, TokenKind::Comma, TokenKind::Semi, TokenKind::ModSep, TokenKind::OpenDelim(token::DelimToken::Brace), TokenKind::OpenDelim(token::DelimToken::Paren), TokenKind::CloseDelim(token::DelimToken::Brace), TokenKind::CloseDelim(token::DelimToken::Paren), ]; </ins> if let token::Ident(name, false) = self.token.kind { <del> if Ident::new(name, self.token.span).is_raw_guess() { </del> <ins> if Ident::new(name, self.token.span).is_raw_guess() && self.look_ahead(1, |t| valid_follow.contains(&t.kind)) { </ins> err.span_suggestion( self.token.span, "you can escape reserved keywords to use them as identifiers",

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.