jiebi/CodeConvo huggingface dataset:
Change:
// box, and `TAG_CUSTOM` just... isn't zero -- it's `0b01`). Therefore, // `TAG_CUSTOM + p` isn't zero and so `tagged` can't be, and the // `new_unchecked` is safe. <del> let res = Self(unsafe { NonNull::new_unchecked(tagged) }); </del> <ins> let res = Self(unsafe { NonNull::new_unchecked(tagged) }, PhantomData); </ins> // quickly smoke-check we encoded the right thing (This generally will // only run in libstd's tests, unless the user uses -Zbuild-std) debug_assert!(matches!(res.data(), ErrorData::Custom(_)), "repr(custom) encoding failed");

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: either it to compile or not compile. Instead, this happened: it compiled but only on 64-bit platforms. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.59 (where it did not compile no matter what platform) <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Not sure what the best approach is here. We could just to restore consistency from which made auto-implement . cc
which non-64bit platform does reproduce the issue (not sure if this question matters a lot)?
All platforms that have and . For example, . This is caused by this code:
Ah, should have or something along those lines. I'll get a fix for this up later this evening or tomorrow.
Hmm, this should probably not be closed, unless prioritization will still see it if it is closed.
Yeah, for backports I think the issue stays open until the backport is landed or decided against. Reopened for tracking.
Change:
error: MethodError<'tcx> ) { let rcvr = &args[0]; <del> let try_alt_rcvr = |err: &mut DiagnosticBuilder<'_>, new_rcvr_t| { if let Ok(pick) = self.lookup_probe( span, segment.ident, new_rcvr_t, rcvr, probe::ProbeScope::AllTraits, ) { err.span_label( pick.item.ident.span, &format!("the method is available for `{}` here", new_rcvr_t), ); </del> <ins> let try_alt_rcvr = |err: &mut DiagnosticBuilder<'_>, rcvr_t, lang_item| { if let Some(new_rcvr_t) = self.tcx.mk_lang_item(rcvr_t, lang_item) { if let Ok(pick) = self.lookup_probe( span, segment.ident, new_rcvr_t, rcvr, probe::ProbeScope::AllTraits, ) { err.span_label( pick.item.ident.span, &format!("the method is available for `{}` here", new_rcvr_t), ); } </ins> } };

Discussion:
Test Program: Error message on nightly [ 2019-09-02] and before: Error message since nightly [ 2019-09-03]: Diff Between the Nightlies: Reported by and in
I'm testing this with regression in Maybe cause it
cc -- I think we need to be more graceful by checking if liballoc exists or not or not requiring the language items.
PR show more suggestions on method take ,, or when method not found However, , and don't exist in , but in . Error message of this code:
Mentoring instructions: Change to return and use instead of .Make take in and call instead and return early . Also be sure to not use .Include tests like above and make sure to check for Box, Rc, and Arc.Use to update the tests.
Change:
} } <del> /// Appends elements to `Self` from other buffer. </del> <ins> /// Appends elements to `self` from other buffer. </ins> #[cfg(not(no_global_oom_handling))] #[inline] unsafe fn append_elements(&mut self, other: *const [T]) {

Discussion:
See the documentation for here and for here: In both cases, the documentation refers to the object the method is called for, not the type, so it should be using the lower case . (And maybe should be in backticks here?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-docs +T-libs +E-easy
claim
Change:
<ins> //@ check-pass #![feature(type_alias_impl_trait)] fn spawn<T, F>(future: F) -> impl Sized where F: FnOnce() -> T, { future } fn spawn_task(sender: &'static ()) -> impl Sized { type Tait = impl Sized + 'static; spawn::<Tait, _>(move || sender) } fn main() {} </ins>

Discussion:
Replacing with in makes it compile, so it feels to me the RPIT version should be accepted too. This is minimized from the . bisected: searched nightlies: from nightly-2024-03-14 to nightly-2024-03-20 regressed nightly: nightly-2024-03-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label F-type-alias-impl-trait
label F-typealiasimpl_trait
Strange that this is due to . I'll look into this :thinking:
This started passing in . I wonder if it's because we were erroneously defining an opaque to be equal to itself.
yea looks like it
Change:
Self::from_bits(tcx, n as u128, ParamEnv::empty().and(tcx.types.usize)) } <ins> /// Attempts to convert to a `ValTree` pub fn try_to_valtree(self) -> Option<ty::ValTree<'tcx>> { match self.kind() { ty::ConstKind::Value(valtree) => Some(valtree), _ => None, } } </ins> #[inline] /// Attempts to evaluate the given constant to bits. Can fail to evaluate in the presence of /// generics (or erroneous code) or if the value can't be represented as bits (e.g. because it

Discussion:
<!-- 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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It's coming from calling at this line: I can take a look at it later, doesn't seem to be related to recent changes. Nice find. We're mistakenly assuming that the const has always already been evaluated by the time is called. claim
This one also seems to be regressing in :thinking: cc
Change:
) } } <ins> /// If we have an expected file to write into, and `RUSTC_BLESS_TEST` is /// set, then write the actual output into the file and return `true`. /// /// We assume that `RUSTC_BLESS_TEST` contains the path to the original test's /// source directory. That lets us bless the original snapshot file in the /// source tree, not the copy in `rmake_out` that we would normally use. fn maybe_bless_expected_file(&self, actual: &str) -> bool { let Some(ref expected_file) = self.expected_file else { return false; }; let Ok(bless_dir) = std::env::var("RUSTC_BLESS_TEST") else { return false; }; let bless_file = Path::new(&bless_dir).join(expected_file); println!("Blessing `{}`", bless_file.display()); fs::write(bless_file, actual); true } </ins> }

Discussion:
While working on , I noticed that running an test with appears to succeed, but doesn't actually update the snapshot file(s). This seems to be a side-effect of . The test does successfully bless the temporary copy of the snapshot file in , but that has no effect on the original snapshot file in .
cc label +A-run-make T-bootstrap
Change:
if sess.target.options.cpu.contains("r6") { e_flags |= elf::EF_MIPS_NAN2008; } <del> file.flags = FileFlags::Elf { e_flags }; </del> <ins> e_flags </ins> } Architecture::Mips64 => { // copied from `mips64el-linux-gnuabi64-gcc foo.c -c`

Discussion:
When compiling for , the resulting binaries should have the OS/ABI () field in the ELF header set to Standalone () as per the LLVM target, which it did before . Now, it is set to "UNIX - System V", which I only tested on Linux. identified the introduction of synthetic object files for exported symbols from to have changed this: I did not have a deep dive into the code yet, but I assume the synthetic object file has the host's OS/ABI, which is prevalent over the other OS/ABI. do you have any insight? Related:
Hmm, the crate sets to , which seems to be an alias of . Unfortunately currently crate provide no ways to set this field, so to fix this I suppose some postprocessing of the generated ELF file would be needed. I am surprised that this doesn't show up earlier, given that exactly the same routine is used to create rmeta files. Does hermit not support dylibs?
Ah, yes, sets the OS/ABI here: . I think there are three possibilities: proper support for setting OS/ABI in . This would probably take a lot of effort. before passing it to in This can be done quite easily. the synthetic object file after (?) the real ones. I think lld infers the OS/ABI from the first proper input object file, if I am reading this correctly:  For 1 and 2 we would need to know the proper OS/ABI from the real object files though. I am not sure how easy that would be to come by. What do you think? Hermit is a unikernel, which is linked statically to the application. There is no support for dynamic libraries. A similar problem occurs when using though (). This issue was closed, because we did not need anyways.
Here's how LLVM determines what OSABI to use: We could look at and use the same logic to determine the OSABI. The synthetic object can be placed after real object files (it only needs to be linked before any libraries), but assuming the linker only looks at the first object file sounds a bit hacky. cc what's your take on this issue?
object-rs has only recently been taught to set expected by some MIPS targets (). In think we can teach object-rs to set too, and then just set it, if some linker expects it.
All right.

Thanks for the quick feedback. I'll cook something up in the coming days.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I opened , but first the necessary changes in have to be released.
Change:
<ins> #![allow(unused, nonstandard_style)] #![deny(bindings_with_variant_name)] // If an enum has two different variants, // then it cannot be matched upon in a function argument. // It still gets a warning, but no suggestions. enum Foo { C, D, } fn foo(C: Foo) {} //~ERROR fn main() { let C = Foo::D; //~ERROR } </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 lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
} self.gather_rvalue(rval); } <del> StatementKind::StorageLive(_) | StatementKind::StorageDead(_) => {} </del> <ins> StatementKind::StorageLive(_) => {} StatementKind::StorageDead(local) => { self.gather_move(&Lvalue::Local(local), true); } </ins> StatementKind::SetDiscriminant{ .. } => { span_bug!(stmt.source_info.span, "SetDiscriminant should not exist during borrowck");

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
) -> Result<std::ops::Range<BasicBlock>, &'static str> { let callee_attrs = self.tcx.codegen_fn_attrs(callsite.callee.def_id()); self.check_codegen_attributes(callsite, callee_attrs)?; <ins> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; for arg in args { if !arg.ty(&caller_body.local_decls, self.tcx).is_sized(self.tcx, self.param_env) { // We do not allow inlining functions with unsized params. Inlining these functions // could create unsized locals, which are unsound and being phased out. return Err("Call has unsized argument"); } } </ins> self.check_mir_is_available(caller_body, &callsite.callee)?; let callee_body = try_instance_mir(self.tcx, callsite.callee.def)?; self.check_mir_body(callsite, callee_body, callee_attrs)?;

Discussion:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .
Change:
a + a; //~ ERROR cannot add `A` to `A` <del> a - a; //~ ERROR cannot substract `A` from `A` </del> <ins> a - a; //~ ERROR cannot subtract `A` from `A` </ins> a * a; //~ ERROR cannot multiply `A` to `A`

Discussion:
Got this error message when trying to compile a crate using rustc 1.42.0-nightly ( 2020-01-07). The text reads substract instead of subtract.
if you want to contribute a fix, you would just need to modify these three lines:
thanks for your response, I submitted a PR to fix this.
Change:
} encode_bounds_and_type(rbml_w, ecx, &lookup_item_type(ecx.tcx,local_def(nitem.id))); <ins> encode_attributes(rbml_w, &*nitem.attrs); let stab = stability::lookup(ecx.tcx, ast_util::local_def(nitem.id)); encode_stability(rbml_w, stab); </ins> encode_symbol(ecx, rbml_w, nitem.id); encode_name(rbml_w, nitem.ident.name); }

Discussion:
This may be a duplicate, but can't find the original if it exists. See for the problem. Most of the intrinsics are doc'd with stability markers, but none of that shows up. Docs also consequently don't show up in re-exports.
Uh, are you sure? The doesn't seem to have stability markers at all. Reexports would be a different story though.
The copy_memory ones do.
Ah, you are right. It seems that any extern fns (and not only ) with stability markers are missing them.
To clarify: functions declared inside an block are missing stability markers. Extern functions have them. That is:
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Change:
err.highlighted_span_help( span, vec![ <del> StringPart::normal("you have ".to_string()), </del> <ins> StringPart::normal("there are ".to_string()), </ins> StringPart::highlighted("multiple different versions".to_string()), StringPart::normal(" of crate `".to_string()), StringPart::highlighted(format!("{name}")), <del> StringPart::normal("` in your dependency graph".to_string()), </del> <ins> StringPart::normal("` the your dependency graph".to_string()), </ins> ], ); let candidates = if impl_candidates.is_empty() {

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
// Infer the generic parameters of the impl by unifying the // impl type with the self type of the projection. <del> let self_ty = alias_ty.self_ty(); </del> <ins> let mut self_ty = alias_ty.self_ty(); if !selcx.infcx.next_trait_solver() { self_ty = normalize_with_depth_to( selcx, param_env, cause.clone(), depth + 1, self_ty, obligations, ); } </ins> match selcx.infcx.at(&cause, param_env).eq(DefineOpaqueTypes::No, impl_ty, self_ty) { Ok(mut ok) => obligations.append(&mut ok.obligations), Err(_) => {

Discussion:
<!-- 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. --<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ow, my bad! claim
Change:
left: -5px; } .small-section-header > .anchor { <del> left: -20px; } .small-section-header > .anchor:not(.field) { </del> left: -28px; <ins> padding-right: 10px; /* avoid gap that causes hover to disappear */ </ins> } .anchor:before { content: '200200a72002';

Discussion:
Some of the section anchors that appear when you hover over an item can be difficult to click. It seems to disappear when the mouse transitions over the spacing between the item and the symbol. ! Tested on a variety of browsers, all seem to behave similarly. Rust 1.25 seems OK (there isn't as much spacing). I only notice this on nightly (1.26.0-nightly ( 2018-03-28)).
There is already a PR to fix it .
Resolving? has been merged.
Oh indeed!
Actually it still happens with section headers. I have a small patch I'm testing out to deal with that.
Change:
<ins> error[E0599]: no function or associated item named `new` found for struct `TcpStream` in the current scope --> $DIR/fn-new-doesnt-exist.rs:4:28 | LL |    let stream = TcpStream::new(); |                            ^^^ function or associated item not found in `TcpStream` | note: if you're trying to build a new `TcpStream` consider using one of the following associated functions: TcpStream::connect TcpStream::connect_timeout --> $SRC_DIR/std/src/net/tcp.rs:LL:COL error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!