jiebi/CodeConvo huggingface dataset:
Change:
/// /// [`String`]: crate::string::String /// [`dealloc`]: crate::alloc::GlobalAlloc::dealloc <ins> /// [*fit*]: crate::alloc::Allocator#memory-fitting </ins> /// /// # Examples ///

Discussion:
has this to say about a better way to turn a into a : A strict reading, if I understand correctly, says that these two statements are contradictory. The documentation says that it is safe to create a and then use to create a out of its pointer. But the documentation says that, when creating a , must have previously been allocated via precisely and only , not for some other type —not even if happens to be transmutable from , not even if and are ABI-compatible, not only if is a wrapper around , but only itself. I suspect it was meant to say it must have previously been allocated by , not ; after all, if it could only have been allocated by in the first place, the next bullet point would be redundant (because obviously has the same alignment as ).
label A-docs
Relevant: looks like it will fix this if approved, by explicitly allowing allocation using something other than Vec<T(which can be a Vec<Uor even manual allocation)
Hm, that PR does remove the text I pointed out, but it also adds this text: Isn’t that equally problematic (albeit a slightly different but related problem, since it’s talking about the contents of the memory rather than its ), since it is actually fine for them to be properly initialized values of some other type that is suitably bytewise-compatible (for a proper choice of wording for “suitably compatible”) with but is not actually itself? Or does “properly initialized values of type ” actually also cover that (i.e. does it mean “bytes containing valid representations of ” and not “memory regions which have been constructed as s”?).
Rust doesn't have typed memory, types only have effect on accesses, so if some memory can be interpreted as some type T and it's valid at that type, it's a properly initialized value of type T. Nothing remembers the "original type" of some data. Just like how you can cast a to a and use them interchangeably. This is a safe operation if you use , too.
Change:
<ins> // compile-flags: --crate-type=lib -O -Cdebuginfo=2 -Cno-prepopulate-passes // min-llvm-version: 15.0 # this test uses opaque pointer notation #![feature(stmt_expr_attributes)] pub struct S([usize; 8]); #[no_mangle] pub fn outer_function(x: S, y: S) -> usize { (#[inline(always)]|| { let _z = x; y.0[0] })() } // Check that we do not attempt to load from the spilled arg before it is assigned to // when generating debuginfo. // CHECK-LABEL: @outer_function // CHECK: [[spill:%.*]] = alloca %"[closure@{{.*.rs}}:9:23: 9:25]" // CHECK-NOT: [[ptr_tmp:%.*]] = getelementptr inbounds %"[closure@{{.*.rs}}:9:23: 9:25]", ptr [[spill]] // CHECK-NOT: [[load:%.*]] = load ptr, ptr // CHECK: call void @llvm.lifetime.start{{.*}}({{.*}}, ptr [[spill]]) // CHECK: call void @llvm.memcpy{{.*}}(ptr {{align .*}} [[spill]], ptr {{align .*}} %x </ins>

Discussion:
When generating a variable debuginfo, rustc emits an expression describing the address of a source variable. Since , rustc also evaluates this expression. The expression can contain indirections, and it is not always valid to evaluate it. Consider a source variable that is described indirectly in terms of a base local. The source variable will be introduced at the beginning of a function, but at this point the base local might be uninitialized. For example: Note that has and metadata but loaded value is uninitialized. (This leads to end-to-end miscompilation with -Cdebuginfo=2). cc
A variant that demonstrates complete end-to-end miscompilation can be found in
Even without the metadata, this load could violate constraints. So just removing the metadata is not a proper fix. EDIT: Or does this always load from an that doesn't have any other pointers to it yet? Then it should be fine in terms of aliasing.
Change:
<ins> // Copyright 2012-2013 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 non constant exprs fail for array repeat syntax fn main() { fn bar(n: usize) { let _x = [0; n]; //~^ ERROR attempt to use a non-constant value in a constant [E0435] //~| NOTE non-constant value } } </ins>

Discussion:
rustc 1.0.0 - 1.11.0: rustc 1.12.0 - 1.15.0: rustc 1.16.0 - present: Can we have the first one back please?
To clarify, the problem is in the note:
Note introduced in , using the exact wording from . Rust 1.12 fully transitioned to MIR, which made the repeat count no longer special, thus losing the special error message. I think the note should be reworded to "non-constant used as constant".
The error message today speaks the truth and does so quite well. Closing.
The span label is still pretty nonsensical.
Okay, I'll reopen. Can you provide the exact wording you'd expect? (I personally don't really see any point for a span label, but ... ).
Either remove the label or just "non-constant value" seems to make more sense to me. It's the "with constant" that is weird IMO.
I'll PR.
I just came here after googling and want to say that the first error message is a lot easier to understand!
Change:
<ins> // run-rustfix // Check that the HELP suggestion is `l(vec![])` instead of `l($crate::vec::Vec::new())` fn l(_a: Vec<u8>) {} fn main() { l(vec![], vec![]) //~^ ERROR this function takes 1 argument but 2 arguments were supplied //~| HELP remove the extra argument } </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): Caused by this line introduced in I found a similar issue in the past, this pull request fixes it: Unfortunately, this one looks like a spurious failure. It can be reproduced in the playground using nightly 2022-04-18, but when I try it locally using the same nightly version there is no ICE. This is the error message: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this still reproducible? I didn't get the ICE, maybe theres some extra flags needed?
The playground seems to reliably reproduce it. And I can reproduce it sometimes using : But that is not always reliable. Given that the error message is "SourceNotAvailable", I guess this is related to how the toolchain is installed (the rust-src component?). Because at one point I tried the latest nightly with cargo-bisect-rustc and it did not ICE, but some days later I tried the same nightly using the same command and it did ICE. But I would just assume that while there is an in the code this issue is not fixed.
I'm currently using rustc 1.62.0-nightly ( 2022-04-25) and from the 10 times I tried executing the code, all of them generated an ICE.
I think I see this issue too. I also had to go back to 2022-04-18 to be able to compile my code.
I opened a pull request with a one line change that may fix this, but I have no way to reproduce it locally (compiling the example code works fine even without the changes of that pull request). The playground can still reproduce the issue as of nightly 2022-04-29, so we can use it to check if this issue is really fixed after that pull request is merged.
So I accidentally closed this issue by adding the words "may to the pull request description, but fortunately it looks fixed, as you can see thanks to the glacier bot.
Change:
<ins> error[E0428]: the name `NotSM` is defined multiple times --> $DIR/multiple-types-with-same-name-and-derive.rs:15:1 | LL | struct NotSM; | ------------- previous definition of the type `NotSM` here ... LL | struct NotSM<T>(T); | ^^^^^^^^^^^^^^^^^^^ `NotSM` redefined here | = note: `NotSM` must be defined only once in the type namespace of this module error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/multiple-types-with-same-name-and-derive.rs:10:10 | LL | #[derive(PartialEq, Eq)] |          ^^^^^^^^^ expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/multiple-types-with-same-name-and-derive.rs:8:8 | LL | struct NotSM; |        ^^^^^ error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/multiple-types-with-same-name-and-derive.rs:10:10 | LL | #[derive(PartialEq, Eq)] |          ^^^^^^^^^ expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/multiple-types-with-same-name-and-derive.rs:8:8 | LL | struct NotSM; |        ^^^^^ = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/multiple-types-with-same-name-and-derive.rs:10:21 | LL | #[derive(PartialEq, Eq)] |                     ^^ expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/multiple-types-with-same-name-and-derive.rs:8:8 | LL | struct NotSM; |        ^^^^^ error[E0107]: struct takes 0 generic arguments but 1 generic argument was supplied --> $DIR/multiple-types-with-same-name-and-derive.rs:10:10 | LL | #[derive(PartialEq, Eq)] |          ^^^^^^^^^ expected 0 generic arguments | note: struct defined here, with 0 generic parameters --> $DIR/multiple-types-with-same-name-and-derive.rs:8:8 | LL | struct NotSM; |        ^^^^^ = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error[E0609]: no field `0` on type `&NotSM` --> $DIR/multiple-types-with-same-name-and-derive.rs:15:17 | LL | struct NotSM<T>(T); |                 ^ unknown field error: aborting due to 6 previous errors Some errors have detailed explanations: E0107, E0428, E0609. For more information about an error, try `rustc --explain E0107`. </ins>

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. --: The message is kinda bad and trying to highlighting code that only exists behind the derive (is not visible to the user) Debug ice: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
}, } <ins> impl<'tcx> PatternKind<'tcx> { /// If this is a `PatternKind::AscribeUserType` then return the subpattern kind, otherwise /// return this pattern kind. fn with_user_type_ascription_subpattern(self) -> Self { match self { PatternKind::AscribeUserType { subpattern: Pattern { box kind, ..  }, ..  } => kind, kind => kind, } } } </ins> #[derive(Clone, Copy, Debug, PartialEq)] pub struct PatternRange<'tcx> { pub lo: ty::Const<'tcx>,

Discussion:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.
Change:
found_fields.insert(index); } None => { <del> let name = pprust::path_to_str(path); </del> // Check the pattern anyway, so that attempts to look // up its type won't fail check_pat(pcx, field.pat, ty::mk_err()); tcx.sess.span_err(span, format!("struct `{}` does not have a field named `{}`", <del> name, </del> <ins> ty::item_path_str(tcx, class_id), </ins> token::get_ident(field.ident)).as_slice()); } }

Discussion:
This is one of those bugs where an earlier error is leading to poor error reporting later on in the output. So it should not be considered high priority. Nonetheless, it would be nice if we could strive for error messages to be sane when considered in isolation, which this example violates: Transcript: The issue is that the second message claims that does not have a field named , but it clearly does. I could understand this message if it said vec2 does not have a field named .
Change:
// lldb-command:run // lldb-command:v some <del> // lldb-check:[...] Some(&0x12345678) </del> <ins> // lldb-check:[...] Some(&0x[...]) </ins> // lldb-command:v none // lldb-check:[...] None // lldb-command:v full <del> // lldb-check:[...] Full(454545, &0x87654321, 9988) </del> <ins> // lldb-check:[...] Full(454545, &0x[...], 9988) </ins> // lldb-command:v empty // lldb-check:[...] Empty // lldb-command:v droid <del> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x43218765 } </del> <ins> // lldb-check:[...] Droid { id: 675675, range: 10000001, internals: &0x[...] } </ins> // lldb-command:v void_droid // lldb-check:[...] Void

Discussion:
Since GDB used on CI is recent enough to run the new tests. However, there are three failures that have been ignored in : <details<summary<codetestsdebuginfomethod-on-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfooption-like-</code(happened only on 32-bits)</summary</details<details<summary<codetestsdebuginfoby-value-non-immediate-argument</code</summary</details
modify labels: +O-windows-gnu +A-debuginfo
The by-value-non-immediate-argument is Upon further inspection, I am now confident that the enums test failures are actually a change in layout with targets. Such nonsense is typical of the debuginfo tests. Take this example program, using the enum extracted from the test: Which we can run on any target that can print using Miri x8664-pc-windows-msvc, x86-64-pc-windows-gnu, and x8664-unknonw-linux-gnu all print 1. s390x-unknown-linux-gnu and i686-pc-windows-gnu print 0 i686-unknown-linux-gnu reports UB, didn't bother figuring out where its discriminant is at but uh that's sus So I think the debuggers in the tests are correctly reporting that the discriminant value for change between platforms.
Oh I see! says this: As far as I can tell, this test has been broken since it was written. You can't rely on field order like this, and indeed as I demonstrated above, fields get reordered differently across targets. The structs and enums also have different field ordering on a single target.
Change:
.use_in_not_of = try using `in` here instead .add_in = try adding `in` here <ins> parse_missing_expression_in_for_loop = missing expression to iterate on in `for` loop .suggestion = try adding an expression to the `for` loop </ins> parse_missing_comma_after_match_arm = expected `,` following `match` arm .suggestion = missing a comma here to end this `match` arm

Discussion:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim
Change:
// ignore-debug: the debug assertions get in the way // compile-flags: -O -Z merge-functions=disabled <ins> // min-llvm-version: 16 </ins> #![crate_type = "lib"] // Ensure that trivial casts of vec elements are O(1) pub struct Wrapper<T>(T); <ins> // previously repr(C) caused the optimization to fail </ins> #[repr(C)] pub struct Foo { a: u64,

Discussion:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.
Change:
}, _ => { match constructor_covered_by_range( <ins> cx.tcx, </ins> constructor, &value.val, &value.val, RangeEnd::Included, value.ty, ) {

Discussion:
The previous version of the crate fails to compile with the error (see the build log). No error nor warning was present in the 1.25 release. Since is actually , the error is wrong and should be fixed. regressed from stable to beta () cc
cc -- initial git log dive notes that this could be related to miri transition? Not sure.
Jup it's a regression. :
Not yet fixed on beta, this needs a backport.
Backported to beta! Thanks!
Change:
<ins> error[E0507]: cannot move out of `*x` which is behind a shared reference --> $DIR/move-out-of-ref.rs:11:9 | LL |         *x; |         ^^ move occurs because `*x` has type `Ty`, which does not implement the `Copy` trait | note: if `Ty` implemented `Clone`, you could clone the value --> $DIR/move-out-of-ref.rs:7:1 | LL | struct Ty; | ^^^^^^^^^ consider implementing `Clone` for this type ... LL |         *x; |         -- you could clone this value error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0507`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
ty::RawPtr(ty::TypeAndMut { ty: pointee_type, .. }) | ty::Ref(_, pointee_type, _) => { pointer_or_reference_metadata(cx, t, pointee_type, unique_type_id) } <del> ty::Adt(def, _) if def.is_box() => { </del> <ins> // Box<T, A> may have a non-ZST allocator A. In that case, we // cannot treat Box<T, A> as just an owned alias of `*mut T`. ty::Adt(def, substs) if def.is_box() && cx.layout_of(substs.type_at(1)).is_zst() => { </ins> pointer_or_reference_metadata(cx, t, t.boxed_ty(), unique_type_id) } ty::FnDef(..) | ty::FnPtr(_) => subroutine_type_metadata(cx, unique_type_id),

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. --for example: <!-- 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. --: rustc needs to be built with debug assertions!! <!-- 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 --
might be related to
Probably related to (or in the same spirit) -- debuginfo code may not account for non-ZST allocator on .
Actually mentioning that issue, it gives me a probable fix. claim
Change:
//    address                unspec loopbk privt  linloc global multicast brdcast doc check(&[0, 0, 0, 0],         true,  false, false, false, false,  false,    false,  false); check(&[0, 0, 0, 1],         false, false, false, false, true,   false,    false,  false); <del> check(&[1, 0, 0, 0],         false, false, false, false, true,   false,    false,  false); </del> <ins> check(&[0, 1, 0, 0],         false, false, false, false, true,   false,    false,  false); </ins> check(&[10, 9, 8, 7],        false, false, true,  false, false,  false,    false,  false); check(&[127, 1, 2, 3],       false, true,  false, false, false,  false,    false,  false); check(&[172, 31, 254, 253],  false, false, true,  false, false,  false,    false,  false);

Discussion:
Tracking issue for First needs to be implemented, then go through an FCP! Looks like the is being implemented over at
This issue is now entering a cycle-long final comment period for stabilization
Discussed recently, the libs team decided to stabilize.