jiebi/CodeConvo huggingface dataset:
Change:
} else { RustfmtState::Unavailable }; <del> } else { // If using a system toolchain for bootstrapping, see if that has rustfmt available. let host = config.build; let rustfmt_path = config.initial_rustc.with_file_name(exe("rustfmt", host)); let bin_root = config.out.join(host.triple).join("stage0"); if !rustfmt_path.starts_with(&bin_root) { // Using a system-provided toolchain; we shouldn't download rustfmt. *config.initial_rustfmt.borrow_mut() = RustfmtState::SystemToolchain(rustfmt_path); } </del> } // Now that we've reached the end of our configuration, infer the

Discussion:
On master branch with commit , replace with actual value and apply this diff: </detailsRun after that. Then run to check status of the repo. I expected to see this happen: Nothing should change. Instead, this happened: Many files changed dues to using wrong rustfmt. cc as in label T-infra <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I think custom rustc also overrides rustfmt, though probably shouldn't. Will investigate fixing.
Yeah, if you configure a rustc we currently default to the sibling rustfmt - that's probably a bug, we should use the python-downloaded rustfmt. The likely correct thing here is to move to setting RUSTFMT from on download, and then detecting that in similarly to rustc/cargo. We should probably treat it as an optional env variable for now though.
claim If no one has claimed it yet :)
Any starting point that I can get? Like the right file or something similar? :
Change:
<del> // compile-flags:--test -Z unstable-options </del> <ins> // compile-flags:--test </ins> // edition:2018 /// ```rust

Discussion:
I have a fresh Rust library, started with , and I have the following in : edition2018 /// assert_eq!(1 + 1, 999) /// I can and this library. The doctest is obviously never run because is false. The output from confirms this, showing that zero test were run. lead me to believe the doctest should still work, even if marked as . is:
That's really strange! It works on nightly! I think it is due to this code: Was this maybe forgotten to be stabilized when editions were stabilized?
This still happens with Rust . I created a minimal project that demonstrates this bug at .
I posted PR to fix this.
Change:
<ins> #![feature(extern_types)] #![feature(non_ascii_idents)] extern "C" { type 一; //~ items in `extern` blocks cannot use non-ascii identifiers fn 二(); //~ items in `extern` blocks cannot use non-ascii identifiers static 三: usize; //~ items in `extern` blocks cannot use non-ascii identifiers } fn main() {} </ins>

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
Change:
| LL | fn foo2<I>(x: <I as for<'x> Foo<&'x isize>>::A) |                     ^^^ expected identifier, found keyword <del> | help: you can escape reserved keywords to use them as identifiers | LL | fn foo2<I>(x: <I as r#for<'x> Foo<&'x isize>>::A) |                     ^^^^^ </del> error: expected one of `::` or `>`, found `Foo` --> $DIR/associated-types-project-from-hrtb-explicit.rs:10:29

Discussion:
Right now the raw ident suggestion when using a reserved keyword somewhere where it is not allowed is context free, leading to misleading output: The parser should perform some lookahead to see if it could actually continue parsing if a raw identifier had been supplied in its place and if so, only then suggest raw idents.
Or we shouldn't suggest using raw identifiers if we cannot do that easily and reliably.
Change:
fn main() { let y = 0; //~^ ERROR unknown start of token: u{37e} <del> //~^^ HELP unicode character ';' (Greek Question Mark) looks like ';' (Semicolon), but it's not </del> <ins> //~^^ HELP Unicode character ';' (Greek Question Mark) looks like ';' (Semicolon), but it is not </ins> }

Discussion:
This code: () Looks pretty identical to this code: But the first one doesn't compile because I accidentally used a unicode minus sign (−) instead of a dash (-). This happened to me when I pasted a constant from Wikipedia. We already produce an error about things like this in other cases. For example with an en space: We produce the following: Maybe we could do the same for the minus sign since it is a pretty confusing error to receive?
The unicode minus sign is already on the list of similar characters: However it looks like it doesn't work in this context.
Change:
<ins> // Verify that we do not trigger a LLVM assertion by creating zero-sized DWARF fragments. // // build-pass // compile-flags: -g -Zmir-opt-level=0 -Zmir-enable-passes=+ScalarReplacementOfAggregates // compile-flags: -Cno-prepopulate-passes #![crate_type = "lib"] pub struct ExtraSlice<'input> { slice: &'input [u8], extra: u32, } #[no_mangle] pub fn extra(s: &[u8]) { let slice = ExtraSlice { slice: s, extra: s.len() as u32 }; } struct Zst; pub struct ZstSlice<'input> { slice: &'input [u8], extra: Zst, } #[no_mangle] pub fn zst(s: &[u8]) { // The field `extra` is a ZST. The fragment for the field `slice` encompasses the whole // variable, so is not a fragment. In that case, the variable must have no fragment. let slice = ZstSlice { slice: s, extra: Zst }; } </ins>

Discussion:
Building Firefox for the thumbv7neon-linux-androideabi and i686-linux-android fails with a rust compiler crash: I wish I could give something more detailed, but I haven't had the time to try to yet. I however identified the regression to come from (Enable ScalarReplacementOfAggregates in optimized builds) and building with avoids the crash.
Duplicate of
going to close as such. thanks for reporting !
Change:
for this type; type is not a structure or  enumeration") } <ins> Err(ty::TypeHasDestructor) => { span_err!(tcx.sess, span, E0184, "the trait `Copy` may not be implemented for this type;  the type has a destructor"); } </ins> } } }

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
<ins> // Fix for issue: #122914 use std::future::Future; use std::pin::Pin; fn project(x: Pin<&'missing mut dyn Future<Output = ()>>) { //~^ ERROR use of undeclared lifetime name `'missing` let _ = x.poll(todo!()); } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object', 'error: internal compiler error: self-type for ObjectPick never dereferenced to an object' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
bisects to cc
Change:
But, unlike a move, we can still use `v` afterward. This is because an `i32` has no pointers to data somewhere else, copying it is a full copy. <ins> All primitive types implement the `Copy` trait and their ownership is therefore not moved like one would assume, following the ´ownership rules´. To give an example, the two following snippets of code only compile because the `i32` and `bool` types implement the `Copy` trait. ```rust fn main() { let a = 5; let _y = double(a); println!("{}", a); } fn double(x: i32) -> i32 { x * 2 } ``` ```rust fn main() { let a = true; let _y = change_truth(a); println!("{}", a); } fn change_truth(x: bool) -> bool { !x } ``` If we would have used types that do not implement the `Copy` trait, we would have gotten a compile error because we tried to use a moved value. ```text error: use of moved value: `a` println!("{}", a); ^ ``` </ins> We will discuss how to make your own types `Copy` in the [traits][traits] section.

Discussion:
As a new rust user I have struggled with a little problem: The ownership and borrowing rules are well explained in the docs but the copy trait and the types that implement them are not! In the doc primitive types are not listed as copy trait implementors. They should at least be mentioned there. It would be good to also add a little more info here: Maybe give some examples like in my question on stackoverflow: This is very important since it is an exception to the most important rule of the language Let me know if I have to make a pull request with a "change proposal" :)
Triage: no real change.
This .
points out that is not
This just confused me for the stable-soon never type, where I think it's likely that even experienced rustaceans would be wondering about implemented traits.
PR is working on it
Is it me, or do the docs still not mention the trait in (e.g.) and ?
Rust has a release cadence of 6 weeks. That commit was merged on Apr 4, starting on the nightly release. Rust 1.26 stable was released on Thu May 10 2018 and this was promoted to beta. . Rust 1.27 stable will be released on Thu Jun 21 2018, at which time this will show up in those docs.
Change:
probe::ProbeScope::TraitsInScope, None, ) { <del> Ok(pick) => pick.self_ty, </del> <ins> Ok(pick) => eraser.fold_ty(pick.self_ty), </ins> Err(_) => rcvr_ty, }; // Remove one layer of references to account for `&mut self` and

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 --
mcve Crashes on nightly and , stable 167:
claim
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-02 regressed nightly: nightly-2023-01-07 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 cc
Change:
<ins> // Copyright 2017 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. mod my_mod { #[derive(Clone, Copy, Eq, PartialEq, PartialOrd, Ord, Hash)] pub struct Name<'a> { source: &'a str, } pub const JSON: Name = Name { source: "JSON" }; } pub fn crash() -> bool { match (my_mod::JSON, None) { (_, Some(my_mod::JSON)) => true, (my_mod::JSON, None) => true, _ => false, } } fn main() {} </ins>

Discussion:
the compiler unexpectedly panicked. this is a bug. I tried this code (hyper = "0.11.9"): I expected to see this happen: code compiles (two top branches are incompatible) Instead, this happened: compiler crashed; re-ordering two top branches fixes the issue : Backtrace:
Slightly simplified version (it's not valid Rust code -- not all patterns are covered -- but it crashes the compiler): Backtrace with debug logging from rustc (RUSTBACKTRACE=full RUSTLOG=rustcconsteval):
Minified:
Change:
} self.infcx.probe(|_snapshot| { <del> if obligation.has_non_region_late_bound() { return; } </del> <ins> let poly_trait_predicate = self.infcx.resolve_vars_if_possible(obligation.predicate); let placeholder_trait_predicate = self.infcx.instantiate_binder_with_placeholders(poly_trait_predicate); </ins> <del> // The code below doesn't care about regions, and the // self-ty here doesn't escape this probe, so just erase // any LBR. let self_ty = self.tcx().erase_late_bound_regions(obligation.self_ty()); let poly_trait_ref = match self_ty.kind() { </del> <ins> let self_ty = placeholder_trait_predicate.self_ty(); let principal_trait_ref = match self_ty.kind() { </ins> ty::Dynamic(ref data, ..) => { if data.auto_traits().any(|did| did == obligation.predicate.def_id()) { debug!(

Discussion:
The type is not inferred to be by the above mentioned nightly release, c.f. Using the stable, the code compiles with out issue. EDIT: It seems to be related to GAT, i.e. a more minimal reproducer is: which similarly fails on nightly and builds on stable. <details<summaryMore details</summaryon the above-mentioned nightly version whereas stable is happy Simply asserting that is via e.g. works on stable and nightly. </details
The reproducer wouldn't compile on stable though?
Sorry, I must have messed something up when trying to whittle it down as the reproducer I started with definitely did compile on stable. Will try to trace my steps backwards.
And indeed using instead of makes it compile on stable. (I wanted to avoid to avoid the standard library but indeed is closer to the original code in question.) I updated the reproducer in the OP accordingly.
Great, thank you. So I believe this to be a different manifestation of from cc -- and therefore also to be fixed by
Stumbled on this separately in my own code. The simplest reproduction I was able to come up with is Removing makes it compile on nightly as well. Putting a bound on does not help.
Change:
pub use fn_queries::*; pub use machine::*; <del> /// Extracts a field of a (variant of a) const. // this function uses `unwrap` copiously, because an already validated constant must have valid // fields and can thus never fail outside of compiler bugs pub(crate) fn const_field<'tcx>( tcx: TyCtxt<'tcx>, param_env: ty::ParamEnv<'tcx>, variant: Option<VariantIdx>, field: mir::Field, value: &'tcx ty::Const<'tcx>, ) -> ConstValue<'tcx> { trace!("const_field: {:?}, {:?}", field, value); let ecx = mk_eval_cx(tcx, DUMMY_SP, param_env, false); // get the operand again let op = ecx.eval_const_to_op(value, None).unwrap(); // downcast let down = match variant { None => op, Some(variant) => ecx.operand_downcast(op, variant).unwrap(), }; // then project let field = ecx.operand_field(down, field.index()).unwrap(); // and finally move back to the const world, always normalizing because // this is not called for statics. op_to_const(&ecx, field) } </del> pub(crate) fn const_caller_location( tcx: TyCtxt<'tcx>, (file, line, col): (Symbol, u32, u32),

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
assert!(v6_1 < v6_3); assert!(v4_3 > v4_1); assert!(v6_3 > v6_1); <ins> // compare with an inferred right-hand side assert_eq!(v4_1, "224.120.45.1:23456".parse().unwrap()); assert_eq!(v6_1, "[2001:db8:f00::1002]:23456".parse().unwrap()); assert_eq!(SocketAddr::V4(v4_1), "224.120.45.1:23456".parse().unwrap()); </ins> } }

Discussion:
as a minimal example. Unclear whether this is a new trait impl or some regression elsewhere.
has been in 1.45 which would explain this:
There were roughly ~15-20 crates that failed in the crater run due to this, mostly in tests. I'm not sure whether we think that's sufficient reasoning to drop the impl, I get that it can be useful... cc (and relabeling as this is not an inference regression)
Can we add to the types? That would provide a path to patch the regression. Being able to easily compare a socketaddr to a string seems pretty valuable for testing, I'd rather see we make it easier than require the turbofish. for the PR that these impls
I’m not in favor since this would blur the difference between "this string does not parse as a valid socket address" v.s. "it does, but one not equal to that one". Code that doesn’t care about that difference can already use and compare strings.
mostly cared about PartialOrd and Ord impls (as you can tell from the PR title). Unlike PartialEq, none existed before on SocketAddr so they won't be problematic. I think the PR included new PartialEq impls only in support of heterogeneous PartialOrd (see ) which was ultimately removed from the PR anyway. I opened to revert the new PartialEq impls, leaving the PartialOrd and Ord impls from .
Change:
LL |     Arith = 1 + 1, |             ^^^^^ <del> error[E0029]: only `char` and numeric types are allowed in range patterns --> $DIR/patkind-litrange-no-expr.rs:20:13 | LL |                 $( $value ..= 42 => Some($name::$variant), )* // PatKind::Range |                               -- this is of type `{integer}` ... LL |     Arith = 1 + 1, |             ^^^^^ this is of type `_` but it should be `char` or numeric error: aborting due to 3 previous errors </del> <ins> error: aborting due to 2 previous errors </ins> <del> For more information about this error, try `rustc --explain E0029`. </del>

Discussion:
currently throws E0029: while it should infer the constant to be . modify labels: +T-compiler +A-inference claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think this is incorrect. doesn't refer to a specific constant, it's just an abstract associated constant. works fine.
Hmm, does work, though. But does not. It does seem inconsistent that works and doesn't.
is just , so type inference should kick in here. In fact you can write and inference works just fine. The issue only happens when used in range patterns. I am prototyping a fix right now and it seems that the issue is just that E0029 check happens a little bit early (before unification is performed).
Change:
// `val` dropped here while still borrowed // borrow might be used here, when `val` is dropped and runs the `Drop` code for type `std::sync::Weak` } <del> #[test] fn arc_from_vec_opt() { let mut v = Vec::with_capacity(64); v.push(0usize); let addr = v.as_ptr().cast::<u8>(); let arc: Arc<[_]> = v.into(); unsafe { assert_eq!( arc.as_ptr().cast::<u8>().offset_from(addr), (std::mem::size_of::<usize>() * 2) as isize, "Vector allocation not reused" ); } } </del>

Discussion:
Miri reports UB in the new test: On first sight, the error seems legitimate. That test got in Cc
Probably what happens is that in Miri, will always move the data to a new location, and then the way the test checks whether that happened causes UB. You should not call unless you are already 100% sure that both pointer point to the same allocation -- and in this case, you cannot be sure of that, since allocators do not promise that keeps the same allocation. In fact, it might be the case that even if keeps the data in-place, the allocation has a new provenance -- it is considered a new allocation at the same location, but all old pointers are invalid now and must be 'refreshed'. So this code probably has UB even if keeps the allocation in-place. I recall this was discussed somewhere at some point, and I think the C standard contains wording along these lines, but I forgot the details... Cc The fix is easy -- just do and later compare that with . The test will still fail in Miri though, and in other allocators that do not shrink in-place.
Yeah, the C standard is quite explicit about this, so for now we should follow suit. Opened
Might it be a good idea to the pointer comparison itself, so that Miri can check the actual implementation, even if it can't check the final assertion. I did suspect that other platforms might not have this behaviour - seems to show this. It might be best to feature gate the test and opt to only platforms with allocators that work like this.
Yes, but to be clear there are two bugs here: the test can fail in some platforms, such as Miri, when realloc doesn't shrink in-place the test has UB on all platforms because the two pointers are into different allocations (realloc conceptually creates a new allocation, even if it remains in-place), but is explicitly documented to only work on pointers within the same allocation
Is the comparison still UB? I'm currently working on a patch that Uses the cast for comparison Turns off this feature for non-GNU targets (since that's the only one I know for sure has the shrink-in-place behaviour) Disables the test on non GNU, and the comparison itself on Miri With that in mnd though, I'm wondering if this opt should just be removed entirely.

The perf wins I got in testing were pretty small for the amount of maintenance headache this seems likely to cause
returns regular integers, you can compare them in whatever way you want.