jiebi/CodeConvo huggingface dataset:
Change:
None => WalkBuilder::new(src.clone()), } .types(matcher) <del> .overrides(ignore_fmt) </del> <ins> .overrides(fmt_override) </ins> .build_parallel(); // there is a lot of blocking involved in spawning a child process and reading files to format.

Discussion:
The skipped files are files in the repo that are not tracked by git. It looks like they might still get to the "formatted modified file" counter? I have no other changed files in the repo, so I wonder what rustfmt is saying to have formatted here :sweat_smile:
It detects X files modified, but the fact that they are not tracked means that their rustfmt invocation will be skipped.
It's better to give different counts for skipped and formatted files?
Maybe soemthing like "formatted x files, skipped y untracked files" would make more sense.
The number is actually right, but it's the number of the files that have been modified in the current branch compared to the master branch: you have 86 untracked path in this case. Anywa, we can make it more explicit here.
Change:
command.arg("--test-file").arg(path); } } <del> builder.ensure(crate::doc::Std { target: self.target, stage: builder.top_stage }); </del> <ins> builder.ensure(crate::doc::Std { target: self.target, stage: builder.top_stage, format: DocumentationFormat::HTML, }); </ins> builder.run(&mut command); } else { builder.info("No nodejs found, skipping "src/test/rustdoc-js-std" tests");

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
/// Returns the source snippet as `String` corresponding to the given `Span` pub fn span_to_snippet(&self, sp: Span) -> Result<String, SpanSnippetError> { <del> self.span_to_source(sp, |src, start_index, end_index| src[start_index..end_index] .to_string()) </del> <ins> self.span_to_source(sp, |src, start_index, end_index| src.get(start_index..end_index) .map(|s| s.to_string()) .ok_or_else(|| SpanSnippetError::IllFormedSpan(sp))) </ins> } pub fn span_to_margin(&self, sp: Span) -> Option<usize> {

Discussion:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .
Change:
| DefKind::AnonConst | DefKind::OpaqueTy | DefKind::Impl <ins> | DefKind::Field | DefKind::TyParam </ins> | DefKind::Closure | DefKind::Generator => true, DefKind::Mod <del> | DefKind::Field </del> | DefKind::ForeignMod <del> | DefKind::TyParam </del> | DefKind::ConstParam | DefKind::Macro(..) | DefKind::Use

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. --I tried simplifying my code, but the code is quite complex and I wasn't able to recreate the ICE. Here is the repo which you can try building to see it for yourself: The main source of the issue is my Tensor structs which look similar to the below code. I have had issues with this . The ICE started happening after I convolution with fft. I to simplify writing the types. Maybe it's related? Sorry for the code mess; I didn't plan to show this code to other people. <!-- 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
Please add A-const-generics, F-constevaluatablechecked, and F-const_generics labels
Maybe related to , but I had this ICE already all the way back in 04/06/2021. Back then the error was
Smaller repro of ICE:
confirming potentially predates 1.56 nightly
Change:
assigned_map: FxHashMap<Place<'tcx>, FxHashSet<BorrowIndex>>, /// Locations which activate borrows. <del> /// NOTE: A given location may activate more than one borrow in the future /// when more general two-phase borrow support is introduced, but for now we /// only need to store one borrow index activation_map: FxHashMap<Location, BorrowIndex>, </del> <ins> activation_map: FxHashMap<Location, FxHashSet<BorrowIndex>>, </ins> /// Every borrow has a region; this maps each such regions back to /// its borrow-indexes.

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
let ocx = ObligationCtxt::new(&infcx); let opaque_ty = tcx.mk_opaque(def_id.to_def_id(), substs); <ins> // `ReErased` regions appear in the "parent_substs" of closures/generators. // We're ignoring them here and replacing them with fresh region variables. // See tests in ui/type-alias-impl-trait/closure_{parent_substs,wf_outlives}.rs. // // FIXME: Consider wrapping the hidden type in an existential `Binder` and instantiating it // here rather than using ReErased. let hidden_ty = tcx.bound_type_of(def_id.to_def_id()).subst(tcx, substs); let hidden_ty = tcx.fold_regions(hidden_ty, |re, _dbi| match re.kind() { ty::ReErased => infcx.next_region_var(RegionVariableOrigin::MiscVariable(span)), _ => re, }); </ins> let misc_cause = traits::ObligationCause::misc(span, hir_id); <del> match infcx.at(&misc_cause, param_env).eq(opaque_ty, hidden_type) { </del> <ins> match infcx.at(&misc_cause, param_env).eq(opaque_ty, hidden_ty) { </ins> Ok(infer_ok) => ocx.register_infer_ok_obligations(infer_ok), Err(ty_err) => { tcx.sess.delay_span_bug( span, <del> &format!("could not unify `{hidden_type}` with revealed type:n{ty_err}"), </del> <ins> &format!("could not unify `{hidden_ty}` with revealed type:n{ty_err}"), </ins> ); } }

Discussion:
Since the nightly 2022-09-11, the following code doesn't compile anymore. <!-- 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
Minimized it a little
searched nightlies: from nightly-2022-01-01 to nightly-2022-09-30 regressed nightly: nightly-2022-09-11 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
cc
I get the same ICE when using the current nightly in a complex Codebase. The works fine.
I think I minimized this to:

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found this error occurred by this commit through
Probably cc
Minimized: claim label F-typealiasimpl_trait T-compiler
This has caused crate and docs fail to build.
This just upgraded from bad diagnostics to ICE on latest nightly.
Change:
_ => (false, false, false), }; <del> // Type check the descriminant and get its type. </del> <ins> // Type check the discriminant and get its type. </ins> let scrutinee_ty = if force_scrutinee_bool { // Here we want to ensure: //

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
Change:
<del> //@ known-bug: rust-lang/rust#124891 type Tait = impl FnOnce() -> (); fn reify_as_tait() -> Thunk<Tait> { Thunk::new(|cont| cont) } struct Thunk<F>(F); impl<F> Thunk<F> { fn new(f: F) where F: ContFn, { todo!(); } } trait ContFn {} impl<F: FnOnce(Tait) -> ()> ContFn for F {} </del>

Discussion:
https://crater- https://crater- https://crater- https://crater- https://crater- https://crater- probably cc
Yeah Matthias also found . Think it hasn't been fixed b/c oli is on holiday -- I assume he will investigate when he's back next week.
MCVE in
WG-prioritization assigning priority (). I'll mark this as because it seems an unintended breaking change and therefore should probably be fixed before entering into stable. label -I-prioritize +P-critical

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation', 'error: internal compiler error: opaque types got hidden types registered from within subtype predicate: Alias(Opaque, AliasTy { args: [], defid: DefId(0:25 ~ ice[ee90]::Tait::{opaque}) }) vs Continuation' 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 [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate -- label +F-typealiasimpl_trait
bit smaller
Change:
} struct TempAnalyzer { <del> lvalue_temps: FnvHashSet<usize>, </del> <ins> lvalue_temps: BitVector, seen_assigned: BitVector </ins> } impl TempAnalyzer { <del> fn new() -> TempAnalyzer { TempAnalyzer { lvalue_temps: FnvHashSet() } </del> <ins> fn new(temp_count: usize) -> TempAnalyzer { TempAnalyzer { lvalue_temps: BitVector::new(temp_count), seen_assigned: BitVector::new(temp_count) } </ins> } fn mark_as_lvalue(&mut self, temp: usize) { debug!("marking temp {} as lvalue", temp); self.lvalue_temps.insert(temp); } <ins> fn mark_assigned(&mut self, temp: usize) { if !self.seen_assigned.insert(temp) { self.mark_as_lvalue(temp); } } </ins> } impl<'tcx> Visitor<'tcx> for TempAnalyzer {

Discussion:
In MIR we want values to be SSA, however ensuring that constraint in trans (i.e. in TempRef) is wrong, I think. Namely, for code like this: we will generate following MIR (graphviz version, because easier to visualise): ! which will result in Note how we assign twice, but the two branches are fully disjoint, and thus, for the purposes of data-flow is still SSA, but for the purposes of translator is assigned multiple times. If we want s to stay across translation of the whole function, we will need something like a in the MIR. cc
Another option would be to convert these temporaries into lvalues (i.e. variables). Could it be that the unfinished is supposed to do just that?
I am confused. We do not require temps to be SSA, either in Mir or trans... But in trans we optimize in those cases where we can (I.e., where temps are SSA). Right?
suggests they are SSA with borrowing and mutation possible. Might be me misinterpreting what SSA means, but what I mean is that these are not supposed to be assigned more than once, for some definitions of once.
I see. Yes, ok, I agree that comment was in error. I think though that you probably ought to update it in :) I would still expect temps to be "DSA" -- which afaik I just made up -- that is, no two writes can reach one another without exiting the "live scope" of the temporary, but I don't know that it's an important property. FWIW I think SSA usually implies that values are "pure values", i.e., you can't take their address and mutate them. But I know what you mean in any case.
er, ought to have updated it
I’ll keep updating the comment in mind in whatever PR that comes next.
Change:
use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_hir::def_id::{CrateNum, DefId}; use rustc_middle::middle::privacy::AccessLevels; <del> use rustc_middle::ty::TyCtxt; </del> <ins> use rustc_middle::ty::{self, TyCtxt}; </ins> use rustc_span::{sym, Symbol}; use crate::clean::{self, types::ExternalLocation, ExternalCrate, ItemId, PrimitiveType};

Discussion:
You'd expect the impl for the boxed type to show up, but it doesn't. I seem to recall rustdoc displays impls anytime the type is contained in the generics, though, so it's odd that it's not happening. Originally reported by (with ) .
also reported a case involving a impl that didn't show up on the trait's page. IIRC this issue is somewhat known already though.
I can't find a case where the impl is if the type is in the generics. Do you have an example maybe?
On Vec's page: !
That one's happening because of this thing. Notice that the generics on the trait count, but the generics on don't. We definitely need to fix this, specifically, for types, because that's how you wind up with impls that aren't actually documented anywhere.
Change:
/// A hash map implementation which uses linear probing with Robin /// Hood bucket stealing. /// <del> /// The hashes are all keyed by the thread-local random number generator /// on creation by default. This means that the ordering of the keys is /// randomized, but makes the tables more resistant to /// denial-of-service attacks (Hash DoS). No guarantees are made to the /// quality of the random data. The implementation uses the best available /// random data from your platform at the time of creation. This behavior /// can be overridden with one of the constructors. </del> <ins> /// By default, HashMap uses a somewhat slow hashing algorithm which can provide resistance /// to DoS attacks. Rust makes a best attempt at acquiring random numbers without IO /// blocking from your system. Because of this HashMap is not guaranteed to provide /// DoS resistance since the numbers generated might not be truly random. If you do /// require this behavior you can create your own hashing function using /// [BuildHasherDefault](../hash/struct.BuildHasherDefault.html). </ins> /// /// It is required that the keys implement the `Eq` and `Hash` traits, although /// this can frequently be achieved by using `#[derive(PartialEq, Eq, Hash)]`.

Discussion:
Today, the HashMap docs say: While this is accurate, it's burying the lede: we should say much more clearly what the tradeoffs are, and point more directly toward the custom hashing infrastructure. E.g.:
part of
I would be happy to work with anyone who wants to work on this issue.
is relevant to this bug -- now the docs should say that Rust uses a slow hash function by default "for DoS protection", but does not actually provide DoS protection.
I'd like to take a crack at this issue with your help. I won't be able to work on it today but I could tomorrow.
great! Can you swing by IRC tomorrow? That'd be easiest
The docs IRC channel correct? I'll swing by around 7pm EST maybe even slightly earlier On Wed, Aug 3, 2016, 17:17 Steve Klabnik wrote:
Yeah, any of them. That's a little late for me, but I'm sure that one of us can be helpful :smile: (And I'm also happy to do it asynchronously through this issue too, just sometimes real-time is a bit easier.)
I'll pop in around that time and if you're around great if not I'll point the channel to this issue to ask for help if I need it. I could pop on during work lunch break tomorrow and at least get a starting point from you if that works as well. Steve Klabnik wrote:
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. // Issue #16205. struct Foo { a: [Box<int>, ..3], } fn main() { let mut y = 1i; let x = Some(&mut y); for &a in x.iter() {    //~ ERROR cannot move out } let f = Foo { a: [box 3, box 4, box 5], }; for &a in f.a.iter() {  //~ ERROR cannot move out } let x = Some(box 1i); for &a in x.iter() {    //~ ERROR cannot move out } } </ins>

Discussion:
loops allow moving out of fixed size arrays. This code compiles and should not compile. segfault with channels I don't know how to make this test case smaller, but... This commit introduces a segfault. Seems bad.
From what I'm seeing here(debugger wise) the problem looks to stem from the call to in the function. Inside we enter the loop, make it through the first unsafe match and then the problem appears to occur in the branch when we try to match again.
Can you describe the system that you're running on as well as the cargo/rustc versions you're using? I've been unable to reproduce the segfault on the most recent nightly on both linux and osx.
Oh sorry, I'm running Windows here. Latest installer version. After restarting into Xubuntu and updating I recompiled there and got a segfault. I get rust from the hansjorg/rust PPA. I'm running off of a Toshiba Satellite L875D-S7210 with an AMD A6-4400M APU. Windows is 64bit and Xubuntu is 32bit.
Ah, found it. Nominating and cc this seems bad and related to the recent removal of for-loop desugaring.
Assigning P-backcompat-lang, 1.0 milestone.
Simpler reproduction (it's not related to fixed sized arrays, updating title):
If you want to see a segfault you have to do something in the loop and iterate twice: This prints 1 and 2, then stalls a bit, then segfaults.
Change:
<ins> // compile-flags: -O // min-llvm-version: 17 #![crate_type = "lib"] // CHECK-LABEL: @trailing_zeros_ge #[no_mangle] pub fn trailing_zeros_ge(val: u32) -> bool { // CHECK: %[[AND:.*]] = and i32 %val, 7 // CHECK: %[[ICMP:.*]] = icmp eq i32 %[[AND]], 0 // CHECK: ret i1 %[[ICMP]] val.trailing_zeros() >= 3 } // CHECK-LABEL: @trailing_zeros_gt #[no_mangle] pub fn trailing_zeros_gt(val: u64) -> bool { // CHECK: %[[AND:.*]] = and i64 %val, 15 // CHECK: %[[ICMP:.*]] = icmp eq i64 %[[AND]], 0 // CHECK: ret i1 %[[ICMP]] val.trailing_zeros() > 3 } </ins>

Discussion:
Typically, one would write to check whether is aligned to 8B. However, Clippy complains and says it would be nicer to write it as . Although it is disputable whether this is really more readable, the problem is that the code generated is significantly worse. For example, let's take this code: I expected to see the same optimal code generated. However, the compiler indeed generates separate instruction for instruction and additional compare, instead of a single instruction. Code generated on x64: Code generated on ARM: This happens with the newest Rust 1.67 as well as with older versions and in nightly. Checking of / and / with / operators against can be mapped to checking via a mask of / ones at the tail (for ) or head (for ) of the mask word and comparing against 0 for (which is implicitly done and set as ZERO/EQ flag in CPU flags after the TEST operation, i.e., it boils down to a single instruction) or the mask word for (which boils down to two instructions).
https://rust- Clippy does at least list it as a possible downside of the lint.
This was fixed by
Thanks. Any ETA estimate when it will land in Rust compiler (TBH I have no idea how and how often llvm is pulled)? I just tested with nightly and the code generated is still suboptimal.
Sorry, I also don't know when on Rust side. (I guess hopefully LLVM release would be in few weeks, as you may know )
This will land in Rust nightly around August with the LLVM 17 upgrade. Assigning to myself to check back when it's time.
Godbolt: Fixed by , needs codegen test.