jiebi/CodeConvo huggingface dataset:
Change:
builder.copy(&builder.src.join(file), &dst_src.join(file)); } <del> // libtest includes std and everything else, so vendoring it // creates exactly what's needed for `cargo -Zbuild-std` or any // other analysis of the stdlib's source. Cargo also needs help // finding the lock, so we copy it to libtest temporarily. // // Note that this requires std to only have one version of each // crate. e.g. two versions of getopts won't be patchable. let dst_libtest = dst_src.join("library/test"); let dst_vendor = dst_src.join("vendor"); let root_lock = dst_src.join("Cargo.lock"); let temp_lock = dst_libtest.join("Cargo.lock"); // `cargo vendor` will delete everything from the lockfile that // isn't used by libtest, so we need to not use any links! builder.really_copy(&root_lock, &temp_lock); let mut cmd = Command::new(&builder.initial_cargo); cmd.arg("vendor").arg(dst_vendor).current_dir(&dst_libtest); builder.info("Dist src"); let _time = timeit(builder); builder.run(&mut cmd); builder.remove(&temp_lock); </del> // Create source tarball in rust-installer format let mut cmd = rust_installer(builder); cmd.arg("generate")

Discussion:
Since we run cargo vendor unconditionally to vendor libtest in libstd. We should either pass it '--offline' or add a way to conditionally do so to avoid using network when unnecessary
I am happy to accept a patch for this; if it is not small (e.g., just adding offline) we will likely end up wanting to revert on beta.
Is this really P-critical? I would think this is P-high since P-critical is usually reserved for severe user-facing bugs.
I consider inability for distros to build a particular version of Rust to be a release blocker.
Here what i've tried so far: - - None of those worked out, last failure:
With just the (without the generate-lockfile):
Ah, I didn't realize it was that bad! Sorry about that.
cc -- do we expect cargo vendor to work without network when vendoring a subset of a workspace? It looks like we're running into some trouble here to get it working, though I've not personally had time yet to test. cc as well
I believe Cargo is working as intended here, when you run in the workspace root it doesn't actually vendor the crates from because they're patched locally to the in-tree versions. Then when Cargo later vendors for libtest, it doesn't see the annotations so it tries to download them from the network. If you've passed and you're using a vendor directory that means Cargo can't download any more packages, so it provides this error. I think the fix here is to either get Cargo to see the for these crates during the libtest vendoring process or somehow get those crates vendored in whatever does the original vendor.
Will give the approach a try, thanks a lot for the explanation edit: assuming adding the patch section to e.g. libtest can work
I have posted a revert for the current release () since there were several issues on the Cargo side, too. Hopefully we'll try to avoid these issues when we try again.
Change:
```bash $ rustc src/main.rs --target=wasm32-unknown-unknown ``` <ins> ## Target Features `x86`,  and `ARMv8` are two popular CPU architectures. Their instruction sets form a common baseline across most CPUs. However, some CPUs extend these with custom instruction sets, e.g. vector (`AVX`), bitwise manipulation (`BMI`) or cryptographic (`AES`). Developers, who know on which CPUs their compiled code is going to run can choose to add (or remove) CPU specific instruction sets via the `-C target-feature=val` flag. Please note, that this flag is generally considered as unsafe. More details can be found in [this section](known-issues.md). </ins>

Discussion:
When discussing in the compiler team triage meeting, it became clear that target-features ought to be considered generally unsafe. We should document this fact in the and in the . Ideally, we'd also start listing out known gotchas. For example, in noted that: and had a . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Compiler triage meeting: Marking as P-medium
claim
The reference section about mentions this: The link to the section of the reference mentions this as well: So maybe the could point people to the reference?
That is one way in which targetfeature is unsafe, but it's not the one which was the subject of so just pointing at the reference as it is is insufficient. Plus, it's also more about than (where the compiler will hit you in the face with ). So the rustc book is a better place for it than the reference IMO.
I think that for users to better properly understand the UB involved, it might be more educational to say that stamps on all functions, but with the subtle difference that it doesn't make them , so no unsafe-check happens when this triggers UB. The reference does not document all current perils of using . In particular, it does not document that these can change the function call ABI, and that rustc neither checks that nor handles it correctly - we just currently assume people don't do that. Independently of whether we document that in the rustc book as well or not, that bit should also probably be documented in the reference, because it is easy to trigger this. On stable Rust, I think one can indeed only trigger this via and the reference should say so, but on nightly one can definitely trigger this with bare within a single Rust crate.
Change:
.get(arg_idx + 1) .map(|&(_, sp)| sp) .unwrap_or_else(|| { <del> // Subtract one to move before `)` call_expr.span.with_lo(call_expr.span.hi() - BytePos(1)) </del> <ins> // Try to move before `)`. Note that `)` here is not necessarily // the latin right paren, it could be a Unicode-confusable that // looks like a `)`, so we must not use `- BytePos(1)` // manipulations here. self.tcx().sess.source_map().end_point(call_expr.span) </ins> }); // Include next comma

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: 536 | Err(#[stable(feature = "rust1", since = "1.0.0")] E), [typeck] type-checking [analysis] running analysis passes on this crate --
Probably one of those cases... We should almost have an internal deny lint that bans explicit manipulations for suggestions. Possibly
Strongly agree. It's so easy to find these kinds of ICEs: simply needs to look for inside , out which ASCII character is meant to one's favorite Unicode table website that can list Confusables a Confusable whose is 1 and :boom:
For example, here's another one which I organically found while reviewing an unrelated PR: This code uses a Medium Right Parenthesis Ornament (U+2769) which is confusable with Right Parenthesis
I'll open an issue for the internal lint.
Change:
//      ``` // - the block has no attribute and was not created inside a macro // - if the block is an `anon_const`, the inner expr must be a literal <del> //      (do not lint `struct A<const N: usize>; let _: A<{ 2 + 3 }>;`) // </del> <ins> //   not created by a macro, i.e. do not lint on: //      ``` //      struct A<const N: usize>; //      let _: A<{ 2 + 3 }>; //      let _: A<{produces_literal!()}>; //      ``` </ins> // FIXME(const_generics): handle paths when #67075 is fixed. if let [stmt] = inner.stmts.as_slice() { if let ast::StmtKind::Expr(ref expr) = stmt.kind { if !Self::is_expr_delims_necessary(expr, followed_by_block, false) && (ctx != UnusedDelimsCtx::AnonConst <del> || matches!(expr.kind, ast::ExprKind::Lit(_))) </del> <ins> || (matches!(expr.kind, ast::ExprKind::Lit(_)) && !expr.span.from_expansion())) </ins> && !cx.sess().source_map().is_multiline(value.span) && value.attrs.is_empty() <del> && !expr.span.from_expansion() </del> && !value.span.from_expansion() && !inner.span.from_expansion() {

Discussion:
The false negative bisects to , so pretty obviously . FYI From skimming , that's an issue about const generics. It doesn't seem like the PR was supposed to have affected unused_braces situations outside of const generics position.
Change:
let compiler = self.compiler(self.top_stage, host); cmd.env("RUSTC_STAGE", compiler.stage.to_string()) .env("RUSTC_SYSROOT", self.sysroot(compiler)) <del> .env( "RUSTDOC_LIBDIR", self.sysroot_libdir(compiler, self.config.build), ) </del> <ins> // Note that this is *not* the sysroot_libdir because rustdoc must be linked // equivalently to rustc. .env("RUSTDOC_LIBDIR", self.rustc_libdir(compiler)) </ins> .env("CFG_RELEASE_CHANNEL", &self.config.channel) .env("RUSTDOC_REAL", self.rustdoc(host)) .env("RUSTDOC_CRATE_VERSION", self.rust_version())

Discussion:
To reproduce, make sure you have an entirely clean checkout -- I did . Then run This will go on for a while and ultimately fail with Notably, it doesn't seem to build LLVM at all -- which may be why it can't find a codegen-backend...
Turns out that works fine. However, stage 0 tests with doctests still seem pretty much broken. Can these even reasonably work without having a "bootstrap rustdoc"?
Cc
Note that it fails in stage 1 as well -- both of these fail:
Change:
/// // Precise field values are unspecified here /// assert!(!r.contains(&3) && !r.contains(&5)); /// ``` <ins> #[inline] </ins> #[stable(feature = "range_contains", since = "1.35.0")] pub fn contains<U>(&self, item: &U) -> bool where

Discussion:
I tried this code: Also godbolt link I expected to see this happen: I was trying this code to see what kind of assemble the compilers makes. I tried different optimize levels. I see with optimize levels and , that the bits are still there but not used in the function. function is self takes about 5 instructions and the code about 40 instruction, which is dead code. Instead, this happened: bits removed in all the optimize levels. I was using a similar code on a embedded device. FYI: It also happens with . Remove the before 247. I see this happen on stable and nightly both for x86_64 and thumbv6/v7.
This is, unfortunately, well known. and aren't necessarily smaller 'll be optimized out in (which is opt-level=2).
Please open issues if you see any more problems like this. I think this general situation is more of a problem than our issue tracker suggests. If you report them we'll be more aware of the trend, and we can paper over individual situations like this one. I think that's what my linked PR does.
maybe to clarify. With opt_level the assembly of the generated function is fine and optimized. But the bits are not removed and not used. so I am not sure if will help in this case.
does more than just apply an optimization hint. I disassembled the rlib files that come out of compiling that example code and confirmed that my PR does reduce the output to just one function.
Change:
<ins> // Regression test for issue #113736. // check-pass #![feature(lazy_type_alias)] enum Enum { Unit, Tuple(), Struct {}, } fn main() { type Alias = Enum; let _ = Alias::Unit; let _ = Alias::Tuple(); let _ = Alias::Struct {}; } </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. --: <!-- 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 --
can you please avoid using in the future and directly put the attributes in the source? It makes it easier to copy it to the playground or local invocation.
I've got a fix already, gonna open a PR later. claim
Minimized:
Change:
// gdb-command: print none // gdb-check:$12 = None <ins> // gdb-command: print some_fat // gdb-check:$13 = Some = {"abc"} // gdb-command: print none_fat // gdb-check:$14 = None </ins> // gdb-command: print nested_variant1 <del> // gdb-check:$13 = NestedVariant1 = {NestedStruct = {regular_struct = RegularStruct = {the_first_field = 111, the_second_field = 112.5, the_third_field = true, the_fourth_field = "NestedStructString1"}, tuple_struct = TupleStruct = {113.5, 114}, empty_struct = EmptyStruct, c_style_enum = CStyleEnumVar2, mixed_enum = MixedEnumTupleVar = {115, 116, false}}} </del> <ins> // gdb-check:$15 = NestedVariant1 = {NestedStruct = {regular_struct = RegularStruct = {the_first_field = 111, the_second_field = 112.5, the_third_field = true, the_fourth_field = "NestedStructString1"}, tuple_struct = TupleStruct = {113.5, 114}, empty_struct = EmptyStruct, c_style_enum = CStyleEnumVar2, mixed_enum = MixedEnumTupleVar = {115, 116, false}}} </ins> // gdb-command: print nested_variant2 <del> // gdb-check:$14 = NestedVariant2 = {abc = NestedStruct = {regular_struct = RegularStruct = {the_first_field = 117, the_second_field = 118.5, the_third_field = false, the_fourth_field = "NestedStructString10"}, tuple_struct = TupleStruct = {119.5, 120}, empty_struct = EmptyStruct, c_style_enum = CStyleEnumVar3, mixed_enum = MixedEnumStructVar = {field1 = 121.5, field2 = -122}}} </del> <ins> // gdb-check:$16 = NestedVariant2 = {abc = NestedStruct = {regular_struct = RegularStruct = {the_first_field = 117, the_second_field = 118.5, the_third_field = false, the_fourth_field = "NestedStructString10"}, tuple_struct = TupleStruct = {119.5, 120}, empty_struct = EmptyStruct, c_style_enum = CStyleEnumVar3, mixed_enum = MixedEnumStructVar = {field1 = 121.5, field2 = -122}}} </ins> use self::CStyleEnum::{CStyleEnumVar1, CStyleEnumVar2, CStyleEnumVar3}; use self::MixedEnum::{MixedEnumCStyleVar, MixedEnumTupleVar, MixedEnumStructVar};

Discussion:
Debuginfo for (and probably also ) enums is not correct if the pointer that doubles as discriminant is a fat pointer. Steps to reproduce: (1) Compile the following program with (2) Print the value of in LLDB with pretty printers enabled: This should print instead of . Maybe it's just the LLDB pretty printer that needs to be adapted.
Change:
<ins> //check-fail #![crate_type="lib"] fn r({) { Ok {             //~ ERROR mismatched types [E0308] d..||_=m } } //~^^^^^ ERROR expected parameter name, found `{` //~| ERROR expected one of `,`, `:`, or `}`, found `..` //~^^^^^ ERROR cannot find value `d` in this scope [E0425] //~| ERROR cannot find value `m` in this scope [E0425] //~| ERROR variant `Result<_, _>::Ok` has no field named `d` [E0559] </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, and the input is not syntactically correct (), so low priority. Affected versions: I tried nightly 2021-12-31 and stable 1.57 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Triage: this has been fixed since nightly-2022-12-09, marking as .
Change:
use rustc_data_structures::indexed_vec::IndexVec; use rustc::ty::ParamEnv; use rustc::ty::layout::{ <del> LayoutOf, TyLayout, LayoutError, LayoutCx, </del> <ins> LayoutOf, TyLayout, LayoutError, </ins> HasTyCtxt, TargetDataLayout, HasDataLayout, };

Discussion:
I saw that was closed when was merged so I thought it would fix the same error on my own code as well however as of nightly: it still happens. Code: Playground: From what I can tell its an alignment issue because changing id from a to a fixes the issue.
Change:
error[E0277]: the trait bound `f32: Termination` is not satisfied <del> --> $DIR/termination-trait-test-wrong-type.rs:6:1 </del> <ins> --> $DIR/termination-trait-test-wrong-type.rs:6:31 </ins> | <del> LL |   #[test] |   ------- in this procedural macro expansion LL | / fn can_parse_zero_as_f32() -> Result<f32, ParseFloatError> { LL | |     "0".parse() LL | | } | |_^ the trait `Termination` is not implemented for `f32` </del> <ins> LL | #[test] | ------- in this procedural macro expansion LL | fn can_parse_zero_as_f32() -> Result<f32, ParseFloatError> { |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Termination` is not implemented for `f32` </ins> | = note: required for `Result<f32, ParseFloatError>` to implement `Termination` note: required by a bound in `assert_test_result`

Discussion:
Edit: outstanding work is to change the span from pointing at the function body to point at the return type. adds a test for the case where a unit test returns a value that does not implement . The message currently talks about and has an ugly multi-line span: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
As long as we have the method signature around when we emit E0277, it has a field with the span for the return type, which should be used for this instead, but this will probably require some special casing this in that (already quite hairy) diagnostic code. Extending could be possible, but I would advice against doing so to avoid turning that attribute into a bigger monster than it already is.
Chiming in that this confused me as I was preparing for a Rust training session, where I expect it would confuse the students even more. Specifically, this should not talk about at all as it's plausible to cause people to look in the wrong spot.
CC
Just started learning Rust and came across this error while writing some tests- I absolutely agree "ungreat" is perfect word choice.
It could get even more confusing when : Rust 1.64
This issue is now (mostly) fixed on nightly by and should be closed I think. The error message is now correct but the span is still “ugly”. I've overlooked this issue and only closed its duplicate, namely .
Actually, let's keep this open only for the span change :)
Just wrap the return type with a struct and implement the Termination trait for that wrapper struct example
Note that this GitHub issue is about the subpar error message given by the compiler which should be fixed and not about potential solutions for user code when facing this message. claim
Change:
impl Foo<u32> for u32 { fn foo(&self, _: u32) -> u32 { self+43 } } impl Bar for () {} <del> unsafe fn fool<'a>(t: *const (Foo<u32>+'a)) -> u32 { let bar : *const Bar = t as *const Bar; </del> <ins> unsafe fn round_trip_and_call<'a>(t: *const (Foo<u32>+'a)) -> u32 { </ins> let foo_e : *const Foo<u16> = t as *const _; let r_1 = foo_e as *mut Foo<u32>; <del> (&*r_1).foo(0)*(&*(bar as *const Foo<u32>)).foo(0) </del> <ins> (&*r_1).foo(0) </ins> } #[repr(C)]

Discussion:
Much of the implementation work for rust-lang/rfcs has been done, but there remain some corner cases to fix: [ ] Casts between raw pointers to different traits are accepted but should not be (e.g. ) [ ] Double-check other cases, ensure adequate tests exist
triage: P-high -- I'm giving this high priority since accepting casts that we ought not to is a backwards compatibility risk, though it is mitigated by the fact that afaik the illegal casts yield an ICE (but I haven't done exhaustive testing)
The newly-illegal casts shouldn't be ICE-s (I mean, on nightly). Casts on stable are just randomly ICE-ey.
Change:
//! //! [rustc dev guide]:https://rustc-dev-guide.rust-lang.org/traits/resolution.html#candidate-assembly use rustc_hir as hir; <ins> use rustc_hir::def_id::DefId; use rustc_infer::traits::TraitEngine; </ins> use rustc_infer::traits::{Obligation, SelectionError, TraitObligation}; <ins> use rustc_lint_defs::builtin::DEREF_INTO_DYN_SUPERTRAIT; </ins> use rustc_middle::ty::print::with_no_trimmed_paths; <del> use rustc_middle::ty::{self, Ty, TypeFoldable}; </del> <ins> use rustc_middle::ty::{self, ToPredicate, Ty, TypeFoldable, WithConstness}; </ins> use rustc_target::spec::abi::Abi; <ins> use crate::traits; </ins> use crate::traits::coherence::Conflict; <ins> use crate::traits::query::evaluate_obligation::InferCtxtExt; </ins> use crate::traits::{util, SelectionResult}; use crate::traits::{Overflow, Unimplemented};

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: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- 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--(not applicable) <!-- 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
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.