jiebi/CodeConvo huggingface dataset:
Change:
#[rustc_const_unstable(feature = "const_ascii_ctype_on_intrinsics", issue = "68983")] #[inline] pub const fn is_ascii_control(&self) -> bool { <del> self.is_ascii() && (*self as u8).is_ascii_control() </del> <ins> match *self { '0'..='x1F' | 'x7F' => true, _ => false, } </ins> } }

Discussion:
I noticed this check: and wondered why it's there. Then someone told me it's there because of the . If you pass a non-ASCII char, the would corrupt that char. That's why the check is there before it. But then I wondered: why isn't this just cast to a bigger data type that includes all Unicode code points? This method (and others) are slower than they have to be. Also see this discussion in Discord with more valuable information:
(I can’t seem to find the relevant part in the middle of this discord stream…) I’m not sure what you mean by “corrupt”. is well defined: it takes the numerical value of the code point (same as ), then truncates to keep the lower 8 bits. equals 0x41, but so does . We want to reject the latter since U+1F041 is not an ASCII upper-case letter. If is implemented in terms of , the ASCII range check is necessary. (It could be a range check to, for example with .) But maybe doesn’t need to be implemented in terms of . Maybe it could duplicate the logic instead. Once upon a time was implemented with a lookup table of 256 entries. A flat lookup table for all of Unicode would be way too big. But these days it’s based on matching a range pattern. Doing the same with a range pattern could also work. That said, would it actually be faster? Maybe the optimizer already does its job well. If you want to work on this, consider adding some benchmark to show that code duplication is worth it.
Oh it seems the Discord link is a bit buggy. Try searching for in the search bar on the Discord server. Then you should get to my message with the discussion below it. One guy also posted this comparison of the instructions generated:
I think the minimal standard here should be a benchmark before we change the implementation. Can you provide that?
I'm not that experienced with Rust yet, sorry. I just wanted to point out this possible performance regression. Shouldn't the instruction amount difference as shown on Godbolt suffice to know that it's slower? vs.
Looking at the assembly, it seems that the problem is the check. These three functions produce : So, it seems that the check is unnecessary. I could make a PR for this.

Here are some benchmarks: So it seems that removing the check has a measurable performance difference.
is incorrect. The conversion should happen not for the ASCII check but for the , and the pattern use byte literals like . (Though I expect this won’t affect results much.)
Change:
<ins> error[E0046]: not all trait items implemented, missing: `RefTarget` --> $DIR/ice-type-error-in-tail-124031.rs:9:1 | LL |     type RefTarget; |     -------------- `RefTarget` from trait ... LL | impl Trait for () {} | ^^^^^^^^^^^^^^^^^ missing `RefTarget` in implementation error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0046`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection', 'error: internal compiler error: SizeSkeleton::compute(&Other): layout errored (Unknown(Alias(Projection, AliasTy { args: [Other], defid: DefId(2:2049 ~ core[a6f4]::ptr::metadata::Pointee::Metadata) }))), yet tail is not a type parameter or a projection' 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: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
that's true, it's a type error (should be a quick fix)
you may also enjoy this gem: (found somewhere else)
Ah, this ( ) one bisects to fyi ^^
claim
Change:
mod tuple; mod unit; <ins> #[stable(feature = "core_primitive", since = "1.43.0")] pub mod primitive; </ins> // Pull in the `core_arch` crate directly into libcore. The contents of // `core_arch` are in a different repository: rust-lang/stdarch. //

Discussion:
I got a bug report on Diesel from someone who has a database column called . This lead to us attempting to generate the following code: which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be , which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for , , and all the numeric types.
Since the module already exists, the type cannot be called . But it can be aliased as I guess.
would make sense as well
Related: The reason these primitives are not put into prelude was because but I think this is no longer a problem? (cc
Tagging this as a library issue. The solution (if it happens on our side) is to add a module or (and reexport it from as well) as described in In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen. It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in and ).
I agree that primitives should be exposed at some absolute path. sounds reasonable.
I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows and references ? Do we need one for every type?
I would start with a PR that has: Implementation, Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this, One run-pass test for a shadowed bool as you suggested.
Sounds good. I'll try to get that PR done this week.
Does this need a feature gate?
Yes I believe so.
Triage: not aware of anything happening here.
Change:
<ins> // compile-flags: -W help // check-pass // // ignore-tidy-linelength // // normalize-stdout-test: "( +name  default  meaningn +----  -------  -------n)?( *[[:word:]:-]+  (allow  |warn   |deny   |forbid )  [^n]+n)+" -> "    $$NAMES  $$LEVELS  $$MEANINGS" // normalize-stdout-test: " +name  sub-lintsn +----  ---------n( *[[:word:]:-]+  [^n]+n)+" -> "    $$NAMES  $$SUB_LINTS" // normalize-stdout-test: " +rustdoc::all(  (rustdoc::[[:word:]-]+, )*rustdoc::[[:word:]-]+)?" -> "    rustdoc::all  $$GROUPS$4" </ins>

Discussion:
I tried this code: I expected to see this happen: Rustdoc prints a list of all lints, the same way rustc does. Instead, this happened: Rustdoc ignored the flag. <!-- 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. --: rustdoc 1.53.0-nightly ( 2021-04-03) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
option is parsed into , but is then ignored: It should be pretty straightforward to instead call when this flag is set. claim
Make sure you call init_lints first, or it will be missing rustdoc's own lints.
Re adding a test for this... is there any way to have check only for whether some substring appears within stderr? Else every time a lint is /removed, or its level modified, the test will need updating—which seems far too brittle to me?
I mean, personally that seems ok to me as long as you can update it with . But if you think it's a hassle you could use .
Change:
#![feature(in_band_lifetimes)] #![feature(crate_visibility_modifier)] #![feature(or_patterns)] <del> #![feature(str_strip)] </del> #![feature(option_zip)] #![recursion_limit = "512"] // For rustdoc

Discussion:
Cc Will fill the content later. Creating this so that can be merged and tracked.
The code generated by is really complicated and inefficient. Godbolt link: Should we add / method directly to or trait?
Oof that does indeed look pretty bad.
I whipped up that fix here: Not sure if it's actually the ideal fix, but figured it would be a good point to launch the discussion from.
Ok, the code should be far more optimized now. What remains to be done? The main issue description has yet to be filled in.
On , I'm seeing that is much faster than , at least for newlines only. Is this only because I'm stripping off a very small amount of text, or is this function more optimized than (assuming that I didn't screw something up)? See "Standard strip suffix" versus "Standard trim end", with "unix" having the input of and "win" being : !
Ah, yeah, looks the optimizations I made to stripprefix/stripsuffix in are optimizations that don't exist for : I wonder if could be reimplemented as a loop over ... By the way, since I'm here, (or anyone else on the Rust team), what remains to be done for this issue?
If you want to change the implementation this is a good time. Else, the thing left is stabilisation with the libs team approving it (if needed) but i'd wait for some time to check if there are any other issues.
The implementation is now faster than the existing similar stable functions and , so I think we're in a good spot implementation wise. Would you be able to add a note about the progress and when we expect to start the stabilization discussion in the issue description? (Or whatever normally goes in there?)
you can submit a stabilisation PR by following the instructions here:
Change:
if self.polytypes_unify(polytype_a.clone(), polytype_b) { let session = self.crate_context.tcx.sess; session.span_err( <del> self.span_of_impl(implementation_b), </del> <ins> self.span_of_impl(implementation_a), </ins> format!("conflicting implementations for trait `{}`", ty::item_path_str(self.crate_context.tcx, trait_def_id))); <del> session.span_note(self.span_of_impl(implementation_a), "note conflicting implementation here"); </del> <ins> if implementation_b.did.crate == LOCAL_CRATE { session.span_note(self.span_of_impl(implementation_b), "note conflicting implementation here"); } else { let crate_store = self.crate_context.tcx.sess.cstore; let cdata = crate_store.get_crate_data(implementation_b.did.crate); session.note( "conflicting implementation in crate `" + cdata.name + "`"); } </ins> } } })

Discussion:
Some days ago, I wrote some code involving char as HashMap key. At that time, char didn't implement the IterBytes trait, so I implemented it locally myself. After updating rust, my code failed to compile with a somewhat less than obvious error. Example: Produces the following errors: Note that there is no way to know that the problem is the duplicate implementation of IterBytes.
Reproduced as of
Bumping to 0.7, though.
Not critical for 0.7. Nominating for milestone 5, production-ready.
accepted for production-ready milestone
Still reproduces: It has a bunch of other non-bug errors too, but it still exhibits this bug.
Accepted for P-high.
Change:
<del> // Verifies that during compiler_builtins compilation the codegen units are kept // unmerged. Even when only a single codegen unit is requested with -Ccodegen-units=1. // // compile-flags: -Zprint-mono-items=eager -Ccodegen-units=1 #![compiler_builtins] #![crate_type="lib"] #![feature(compiler_builtins)] mod atomics { //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_1[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_1() {} //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_2[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_2() {} //~ MONO_ITEM fn compiler_builtins::atomics[0]::sync_3[0] @@ compiler_builtins-cgu.0[External] #[no_mangle] pub extern "C" fn sync_3() {} } mod x { //~ MONO_ITEM fn compiler_builtins::x[0]::x[0] @@ compiler_builtins-cgu.1[External] #[no_mangle] pub extern "C" fn x() {} } mod y { //~ MONO_ITEM fn compiler_builtins::y[0]::y[0] @@ compiler_builtins-cgu.2[External] #[no_mangle] pub extern "C" fn y() {} } mod z { //~ MONO_ITEM fn compiler_builtins::z[0]::z[0] @@ compiler_builtins-cgu.3[External] #[no_mangle] pub extern "C" fn z() {} } </del>

Discussion:
I'm currently doing some benchmarks and I've seen that is taking a really long time to calculate on wasm. Turns out that none of the helper functions it uses are inlined at all, so it does a ton of unnecessary calls and misses a lot of potential optimizations: The same is probably true for the Float trait.
It seems like initially had a lot more inline annotations but removed them later on. That may have regressed the performance on wasm, but I'm not entirely sure. This makes me wonder if compiler-builtins is even compiled with LTO at all as it supposedly is meant to be?!
Looks like this is indeed a regression that started with Rust 1.44, which switched from compiler-builtins 0.1.25 to 0.1.27, which is where this PR is part of. These are the instructions in 1.43: cc
There's been a few various changes around codegen units handling and compiler-builtins recently, and it looks like this is caused by compiling this crate with . The compiler but with only one CGU.
Ok I've transferred this to the rust-lang/rust repository since this isn't a bug with compiler-builtins itself I believe but rather how we build compiler-builtins. I believe this is an accidental regression from because only part of the compiler knows that compiler-builtins is built with more than one CGU, the rest of the compiler thinks it's one CGU (respecting CLI flags). I'll be opening a PR shortly to fix this.
Assigning as and removing .
Change:
// CHECK: define i8 @match1{{.*}} // CHECK-NEXT: start: <del> // CHECK-NEXT: %1 = icmp ugt i8 %0, 1 // CHECK-NEXT: %2 = zext i8 %0 to i64 // CHECK-NEXT: %3 = add nsw i64 %2, -1 // CHECK-NEXT: %_2 = select i1 %1, i64 %3, i64 0 // CHECK-NEXT: switch i64 %_2, label {{.*}} [ </del> <ins> // CHECK-NEXT: %1 = {{.*}}call i8 @llvm.usub.sat.i8(i8 %0, i8 1) // CHECK-NEXT: switch i8 %1, label {{.*}} [ </ins> #[no_mangle] pub fn match1(e: Enum1) -> u8 { use Enum1::*;

Discussion:
I tried this code (reduced from a much larger test): () I expected to see this happen: runs with 0 exit code and no output Instead, this happened: This code works on stable and beta, and as recently as . This reproduces with the 2022-11-16 nightly on the playground. this was introduced by . modify labels: +regression-from-stable-to-nightly -regression-untriaged <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That looks like a real miscompilation :( cc
WG-prioritization assigning priority (). label -I-prioritize +P-high
I've found the problem; it is indeed an issue with my code in . I'll have a PR with a fix some time today.
Since there is some work in progress to fix this: assign
Change:
<del> Subproject commit d9e38f57c125c5ac50397ec8a006fe49f17cd96c </del> <ins> Subproject commit 732825dcff6d1f115225305ce5e0c9c9d876a0ff </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[derive(Debug, Clone, PartialEq)] pub struct AddrParseError(()); <ins> #[stable(feature = "addr_parse_error_error", since = "1.4.0")] impl fmt::Display for AddrParseError { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { fmt.write_str(self.description()) } } #[stable(feature = "addr_parse_error_error", since = "1.4.0")] impl Error for AddrParseError { fn description(&self) -> &str { "invalid IP address syntax" } } </ins>

Discussion:
I was writing a generic argument parse validator for my program, which involved matching errors from FromStr::parse. After constraining the error type to Error, I ran into an issue when creating a validator for parsing IP addresses:
Fixed in
Change:
cargo.env("CFG_VERSION", builder.rust_version()); cargo.env("CFG_RELEASE_NUM", &builder.version); cargo.env("DOC_RUST_LANG_ORG_CHANNEL", builder.doc_rust_lang_org_channel()); <ins> if let Some(ref ver_date) = builder.rust_info().commit_date() { cargo.env("CFG_VER_DATE", ver_date); } if let Some(ref ver_hash) = builder.rust_info().sha() { cargo.env("CFG_VER_HASH", ver_hash); } </ins> let info = GitInfo::new(builder.config.omit_git_hash, &dir); if let Some(sha) = info.sha() {

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim
Change:
<ins> // Copyright 2014 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. // error-pattern:internal error: entered unreachable code: uhoh fn main() { unreachable!("uhoh") } </ins>

Discussion:
In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.
Change:
impl<T> Drop for InPlaceDrop<T> { #[inline] fn drop(&mut self) { <del> if mem::needs_drop::<T>() { unsafe { ptr::drop_in_place(slice::from_raw_parts_mut(self.inner, self.len())); } </del> <ins> unsafe { ptr::drop_in_place(slice::from_raw_parts_mut(self.inner, self.len())); </ins> } } }

Discussion:
dilbert-feed is ICEing on beta with error: internal compiler error: could not fully normalize https://crater-
Full error log:
I'll bisect this one
Doesn't happen on the latest commit by on .
I can still reproduce with :
It may just be an instance of me not doing something right, I used:
gives me searched toolchains through regression in So this would have regressed in , cc
The PR did introduce some additional uses of inside specialized implementations. itself it is a stable function so I am not aware of any restrictions on its use. Perhaps this is some interaction with specialization?
Both sites where it is used are of this pattern: They're just there as hints to to let llvm DCE the dropinplace earlier. So if needed removing them should be safe.
Assigning as and removing .
Assigning myself to revert on beta (and potentially nightly, depending on if we can get a fix soon).
Do we know if removing fixes the problem? We also could use an MVCE, right?
MCVE would be good, yes.
I hit (what seems like) this ICE with in a pretty small experiment, would it be useful to try reducing that?
Yes, it would be -- even if it's a separate issue we can just open that :) MCVE is always useful.
ping cleanup This issue needs an MVCE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Here's my nightly MCVE: Interestingly, it goes away when putting all of the code into one crate. <details<summaryFull error message (with <codeRUST_BACKTRACE=1</code):</summary</details
Hmm, this may be a distinct problem, but maybe not. Hard to tell.
I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE. (Also, it would be good to have a single-crate MCVE, but perhaps the multicrate nature is critical here?)
cc , which may be the same underlying bug (but pre-existing?)

hey , did you manage to land a revert of on beta (and nightly?)?
If reverting the PR proves difficult more targeted options would be either removing the use of or only removing / stubbing while leaving the rest of the machinery unchanged. But the former may be insufficient since it also uses similar methods such as and .
Do we think given that we're likely to fix the regression here at least in and we should close this bug? Neither of those PRs fixes the underlying issue (whatever it is) since the lack of normalization is almost certainly still present, but we also don't have (AFAIK) a good test case here for the bug.
I expect so.