jiebi/CodeConvo huggingface dataset:
Change:
<ins> struct A<T> { a: T, } struct B<T, U>(T, U); fn main() { match 0 { //~^ ERROR non-exhaustive patterns: `_` not covered [E0004] 0 => (), 1..=usize::MAX => (), } match (0usize, 0usize) { //~^ ERROR non-exhaustive patterns: `(_, _)` not covered [E0004] (0, 0) => (), (1..=usize::MAX, 1..=usize::MAX) => (), } match (0isize, 0usize) { //~^ ERROR non-exhaustive patterns: `(_, _)` not covered [E0004] (isize::MIN..=isize::MAX, 0) => (), (isize::MIN..=isize::MAX, 1..=usize::MAX) => (), } // Should not report note about usize not having fixed max value match Some(1usize) { //~^ ERROR non-exhaustive patterns: `Some(_)` not covered None => {} } match Some(4) { //~^ ERROR non-exhaustive patterns: `Some(_)` not covered Some(0) => (), Some(1..=usize::MAX) => (), None => (), } match Some(Some(Some(0))) { //~^ ERROR non-exhaustive patterns: `Some(Some(Some(_)))` not covered Some(Some(Some(0))) => (), Some(Some(Some(1..=usize::MAX))) => (), Some(Some(None)) => (), Some(None) => (), None => (), } match (A { a: 0usize }) { //~^ ERROR non-exhaustive patterns: `A { .. }` not covered [E0004] A { a: 0 } => (), A { a: 1..=usize::MAX } => (), } match B(0isize, 0usize) { //~^ ERROR non-exhaustive patterns: `B(_, _)` not covered [E0004] B(isize::MIN..=isize::MAX, 0) => (), B(isize::MIN..=isize::MAX, 1..=usize::MAX) => (), } // Should report only the note about usize not having fixed max value and not report // report the note about isize match B(0isize, 0usize) { //~^ ERROR non-exhaustive patterns: `B(_, _)` not covered [E0004] B(_, 0) => (), B(_, 1..=usize::MAX) => (), } } </ins>

Discussion:
Sorry about the long title :sweat_smile: Given the following code (): The current output is: Note how the first diagnostic, emitted when matching on a , contains additional information about why this exhaustive match does not pass the exhaustiveness check. Ideally, this information should be to the second diagnostic as well: modify labels: +A-exhaustiveness-checking +A-patterns +D-terse
Hm, even though has a different size on different architectures, should always be exhaustive, right? Then that code would be accepted, but the following would still error: We could have the error for this say "missing pattern: ", which would also work if there's a around it. That said, pretty sure what you describe also happens for enums too, and there we'll want to do what you suggest.
see also
I forgot this issue existed, but yeah this is a lint we want. I explained a bit about how this might be done in , if anyone wants to tackle this feel free to ping me
Change:
// This test checks that the core library of Rust can be compiled without enabling // support for formatting and parsing floating-point numbers. <del> use run_make_support::rustc; </del> <ins> use run_make_support::{rustc, source_root}; </ins> fn main() { rustc() .edition("2021") .arg("-Dwarnings") .crate_type("rlib") <del> .input("../../../library/core/src/lib.rs") </del> <ins> .input(source_root().join("library/core/src/lib.rs")) </ins> .cfg("no_fp_fmt_parse") .run(); }

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
if let Some(discr) = operand.layout.ty.discriminant_for_variant(bx.tcx(), index) { <del> let discr_val = bx.cx().const_uint_big(ll_t_out, discr.val); </del> <ins> let discr_layout = bx.cx().layout_of(discr.ty); let discr_t = bx.cx().immediate_backend_type(discr_layout); let discr_val = bx.cx().const_uint_big(discr_t, discr.val); let discr_val = bx.intcast(discr_val, ll_t_out, discr.ty.is_signed()); </ins> return ( bx, OperandRef {

Discussion:
Compiling this code on : results in ICE. Casting to anything smaller than /(, , , , , etc) also results in ICE. Casting to anything same size or larger(, , , , etc) works fine. Positive discriminant values also work fine. Version of rustc: (on rust playground) Compiler flags listed as used:
indicates that this was injected in Rust 1.40
Thanks for the report! Please always include the ICE message. This time, it seems to be
Change:
#[cfg(any( target_os = "android", target_os = "dragonfly", <del> target_os = "emscripten", </del> target_os = "freebsd", target_os = "fuchsia", target_os = "hurd",

Discussion:
Perhaps I'm holding it wrong? About a fifth of the rustc UI test suite to fail on wasm32-unknown-emscripten when trying to run . In all cases we get an error like this:
Does this target use some different main symbol name?
... do we need to pass --no-entry to lib builds? can you check if (some of) the failing tests are lib crates? Actually what am I doing, I can check
I can't get past the building test helpers for this target cross-compiling from msvc host, not sure what's up with that.
Huh. cc Can you make it any further?
Because there's an open PR for this.
In the open platform support docs PR this says It's recommended to test the  target instead for WebAssembly compatibility. ... so I don't know, is this expected failure?
See I was able to get past the build helpers stage by properly acquring the toolchain and making relevant env vars available to bootstrap. Didn't bother trying to diagnose past stage 1 std and tests because there's like a chain of failures. Notably I see
The failing link command includes: if we replace that with , then it links as expected. But then it fails to run it at: We should invoke with node.
So I guess for starters we should do:
Combined with setting the runner to this fixes most of the failing tests:
The failures seem to be: and seems like it hangs? sounds like an xfail.
Change:
// Do not account for the parameters we just bound for function lifetime elision. if let Some(ref mut candidates) = self.lifetime_elision_candidates { for (_, res) in function_lifetime_rib.bindings.values() { <del> candidates.remove(res); </del> <ins> candidates.retain(|(r, _)| r != res); </ins> } }

Discussion:
Instead, this happened: Successful compilation Tested on the playground, all versions and editions. Stable channel: 1.64.0 Beta channel: 1.65.0-beta.3 (2022-10-10 ) Nightly channel: 1.66.0-nightly (2022-10-19 ) I'm labeling this as a regression as I believe it is severe enough of an unplanned change (at best an accidental stabilization?) that I should draw attention to it, even though I haven't found a way to cause miscompilation for example. I also have not tried to do so at all yet. label +T-compiler +A-lifetimes +regression-from-stable-to-stable <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-01-01 to nightly-2022-10-01 regressed nightly: nightly-2022-07-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim
Actually, this behavior is correct as : There is exactly one lifetime used in the parameters (), so assigning it to the output lifetime is as expected. release-assignment
That verbiage but it compiles on no stable version of rustc prior to 1.64, so I don't think it's actually relevant. (The reference is also explicitly non-normative.) mirrors in specifying input positions, not counts. Regardless of documentation, as something that has not compiled on Rust 1.0--1.63 but compiles today, this is clearly a change in language behavior without FCP which I believe to be unintentional. label +T-lang
Ok, so we will consider this for now a regression that should be backported to stable (we're ~2 weeks away from the new release). WG-prioritization assigning priority (). label -I-prioritize +P-critical
Filed
Nominating for lang team to figure out what we should do with this. Will also ping on zulip.

Discussed in lang, dropping nomination. Agreement that we want to revert the change in behavior and backport that to 1.65 (and 1.64, but that's not happening given short time window). Considering whether we want to make the behavior change can happen in a follow-up proposal.
Change:
<ins> error: future cannot be sent between threads safely --> $DIR/unsend-future.rs:19:21 | LL |     require_handler(handler) |                     ^^^^^^^ future returned by `handler` is not `Send` | = help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `*const i32` note: future is not `Send` as this value is used across an await --> $DIR/unsend-future.rs:15:13 | LL |     let a = &1 as *const i32; |         - has type `*const i32` which is not `Send` LL |     async {}.await; |             ^^^^^^ await occurs here, with `a` maybe used later LL | } | - `a` is later dropped here note: required by a bound in `require_handler` --> $DIR/unsend-future.rs:11:23 | LL | fn require_handler<H: Handler>(h: H) {} |                       ^^^^^^^ required by this bound in `require_handler` error: aborting due to previous error </ins>

Discussion:
I tried this code: I expected to see this happen: build failed, because this future doesn't implement Send, so this function shouldn't implement Instead, this happened: build pass <!-- 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</detailscargo-bisect-rustc show the Regression in this bug is introduced by this PR <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +T-types
I think it's a very serious bug, should we revert this change?
claim
minimized ah, figured out the issue how did you catch this bug?
I try to find the minimized example of there is a ICE with a unsend future in this issue
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Isn't this a stable-to-beta regression since nightly just branched?
Just to clarify since we're in the confusing week where stable & beta are discontinuous version numbers:
Change:
// ignore-tidy-linelength #![feature(doc_cfg)] <ins> #![feature(doc_auto_cfg)] </ins> pub mod another_folder; pub mod another_mod;

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
adt_defined_here(cx, &mut err, scrut_ty, &witnesses); err.help( "ensure that all possible cases are being handled,  <del> possibly by adding wildcards or more match arms", </del> <ins> possibly by adding wildcards or more match arms", </ins> ); err.note(&format!("the matched value is of type `{}`", scrut_ty)); <ins> if (scrut_ty == cx.tcx.types.usize || scrut_ty == cx.tcx.types.isize) && !is_empty_match && witnesses.len() == 1 && witnesses[0].is_wildcard() { err.note(&format!( "`{}` does not have a fixed maximum value,  so a wildcard `_` is necessary to match exhaustively", scrut_ty, )); if nightly_options::is_nightly_build() { err.help(&format!( "add `#![feature(precise_pointer_size_matching)]`  to the crate attributes to enable precise `{}` matching", scrut_ty, )); } } </ins> err.emit(); }

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
Some(param) => param, _ => return, }; <ins> let param_def_id = self.tcx.hir().local_def_id(param.hir_id).to_def_id(); let preds = generics.where_clause.predicates.iter(); let explicitly_sized = preds .filter_map(|pred| match pred { hir::WherePredicate::BoundPredicate(bp) => Some(bp), _ => None, }) .filter(|bp| bp.is_param_bound(param_def_id)) .flat_map(|bp| bp.bounds) .any(|bound| bound.trait_ref().and_then(|tr| tr.trait_def_id()) == sized_trait); if explicitly_sized { return; } </ins> debug!("maybe_suggest_unsized_generics: param={:?}", param); match node { hir::Node::Item(

Discussion:
Given the following code: The current output is: Ideally, the diagnostic shouldn't suggest relaxing an explicit bound in the where clause. (There is already code that skips the suggestion for type parameters that have an explicit bound.) I can work on this in an in-progress pull request where I'm making other improvements to unsized suggestions. claim label +A-traits +A-typesystem +D-papercut <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Change:
position_independent_executables: true, pre_link_args, override_export_symbols: Some(EXPORT_SYMBOLS.iter().cloned().map(Cow::from).collect()), <ins> relax_elf_relocations: true, </ins> ..Default::default() }; Target {

Discussion:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do).

To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.
Change:
# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { // Put the value 0x200 in eax <del> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "{eax}"); </del> <ins> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "eax"); </ins> # } } ```

Discussion:
The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.
Change:
); } for target in targets { <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> } } TerminatorKind::Drop { target, unwind, .. } => { <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> if let Some(unwind) = unwind { <del> self.check_bb(location, *unwind); </del> <ins> self.check_edge(location, *unwind, EdgeKind::Unwind); </ins> } } TerminatorKind::DropAndReplace { target, unwind, .. } => { <del> self.check_bb(location, *target); </del> <ins> self.check_edge(location, *target, EdgeKind::Normal); </ins> if let Some(unwind) = unwind { <del> self.check_bb(location, *unwind); </del> <ins> self.check_edge(location, *unwind, EdgeKind::Unwind); </ins> } } TerminatorKind::Call { func, destination, cleanup, .. } => {

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:
LL |     let y = *x; |             ^^ move occurs because `*x` has type `Box<isize>`, which does not implement the `Copy` trait | <del> help: consider removing the dereference here | LL -     let y = *x; LL +     let y = x; | </del> help: consider cloning the value if the performance cost is acceptable | <del> LL -     let y = *x; LL +     let y = x.clone(); | </del> <ins> LL |     let y = (*x).clone(); |             +  +++++++++ </ins> error: aborting due to 1 previous error

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
// When we enter a module, record it, for the sake of `module!` pub fn expand_item(it: P<ast::Item>, fld: &mut MacroExpander) -> SmallVector<P<ast::Item>> { <del> let it = expand_item_multi_modifier(Annotatable::Item(it), fld); expand_annotatable(it, fld) </del> <ins> expand_annotatable(Annotatable::Item(it), fld) </ins> .into_iter().map(|i| i.expect_item()).collect() }

Discussion:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc
Change:
} fn main() { <del> let fut = call_asyncly(|x| async move { x + 1 }); </del> <ins> block_on::block_on(async { call_asyncly(|x| async move { x + 1 }).await; }); </ins> }

Discussion:
Importantly note that the closure passed to foo is ; does not ICE. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in ()