jiebi/CodeConvo huggingface dataset:
Change:
n /= 10; exponent += 1; } let (added_precision, subtracted_precision) = match f.precision() { Some(fmt_prec) => { // number of decimal digits minus 1

Discussion:
<!-- 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: I expected this all to be fine. Instead, the final assertion fails, and the formatting is done like this in the final case: Not sure why 2 decimal places are returned, looks like a bug. This bug also exists in the beta or nightly versions, running in Rust Playground. Discussion: Edit: after looking around the compiler code for the first time I think the problem is somewhere in either or . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
No. The relevant code is actually the one for formatting integers in scientific notation, not floats. I. e. the relevant code is the code first introduced in As I mentioned in the linked URLO thread, I believe perhaps integer formatting in scientific notation should be fully identically behaving to the (seemingly "correct", and also historically older) formatting implementation for floats. This is a potential test we might want passing: but as of now, this kind of test fails in a lot of cases: In this test result, besides the behavior described in this issue, resulting in the wrong number of digits, there’s also the rounding behavior that is different between displaying floats and ints here. I’m not sure whether or not this difference is wanted. If it is_ wanted, it should be properly documented (on that note, I couldn’t easily find any documentation on the rounding used for floats, either), if it isn’t, it would be yet another issue or bug.
I would like to try and fix this bug claim
Change:
<ins> // Regression test for issue #89938. // check-pass // compile-flags: --crate-type=lib #![feature(const_precise_live_drops)] pub const fn f() { let _: Option<String> = None; let _: &'static Option<String> = &None; } </ins>

Discussion:
This only occur in . <!-- 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
ok yea, I can totally see how we got here. Const checking used to happen before promotion, but constpreciselivedrops is happening after, but re-uses const checking machinery. I think we can safely change to return if , as the promoted can't possibly have any of the three qualifs that exist. My reasoning for that is that in order for a promoted to have been created, it must already be free of things that drop, or things that can be mutated and it can't be part of a pattern either, so we don't care about non-derived PartialEq impls. cc
Is this also true for promoteds inside const/static bodies, which can call arbitrary const fn?
hmm good point, there may be a non-const drop value in a promoted there. But... using may be a breaking change. I guess we need to recurse into the MIR of the promoted.
The promoted is a though... so I think there can be const drops (even const drops that panic), but no non-const drops?
Vec::new is const fn and not const drop
But AFAIK it is also not promoted even in const/static bodies?
Sorry, I misread your comment. You were saying this specific issue is for a promoted in a . We need to check whether, with precise drops, we can end up with promoteds that are problematic, as we delayed some of the drop checks. I don't think we delay the drop checks for promotion, so we should be good on that end. All other const checks are guaranteed to happen before promotion, so we can ignore them here. If we want to make this all explicit, we could add an in_promoted function to Qualif and have all other qualifs keep panicking.

Wait, we are promoting things and then checking if that was a good idea? That doesn't work, as it could lead to compile errors in code that would have been fine had we not promoted.
We aren't. Or... we shouldn't. But we need to make sure before we can enable precise drops
That sounds good to me. We can also fallback to type-based reasoning, after all promoted are references, so they don't need drop.
Ralf is right, we should never have to look into promoteds, they must be correctly constructed or not at all. So we don't need an per se, we can just add an associated constant and panic if it is not set and return false otherwise
FWIW, that's how I understood your earlier proposal, with returning false and panicking everywhere else.
Yea, either const or fn is fine, it just seems like a function sends the wrong message, as it could mean you could actually add logic in it
Change:
// Load size/align from vtable. let vtable = info.unwrap(); let size = meth::VirtualIndex::from_index(ty::COMMON_VTABLE_ENTRIES_SIZE) <del> .get_usize(bx, vtable); </del> <ins> .get_usize(bx, vtable, t); </ins> let align = meth::VirtualIndex::from_index(ty::COMMON_VTABLE_ENTRIES_ALIGN) <del> .get_usize(bx, vtable); </del> <ins> .get_usize(bx, vtable, t); </ins> // Size is always <= isize::MAX. let size_bound = bx.data_layout().ptr_sized_integer().signed_max() as u128;

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
<ins> // Copyright 2015 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. trait Foo {} impl<'a> Foo for Foo+'a {} //~^ ERROR the object type `Foo + 'a` automatically implements the trait `Foo` fn main() {} </ins>

Discussion:
Compiling the above (admittedly ill-typed) file will cause My version is
cc didn't easily find a dup of this.
Looks like I am hitting a similar issue. Repro:
your code compiles with code still ICEs though
I have a similar issue with:
With the latest nightly, your example doesn't ICE, but errors instead:
So that would be wrong...? Should I make a new issue?
Why would that be wrong? implementors don't have a associated type, so is correctly rejected (the first error). The second error pops up because of a typo (I just noticed) it says Resouces in .
Oh, woops - the example was meant to be:
that compiles with the latest nightly ()
Yay!
Change:
.collect_referenced_late_bound_regions(&poly_trait_ref) .into_iter() .filter_map(|br| match br { <del> ty::BrNamed(_, name) => Some(GenericParamDef { </del> <ins> ty::BrNamed(_, name) if name != kw::UnderscoreLifetime => Some(GenericParamDef { </ins> name, kind: GenericParamDefKind::Lifetime { outlives: vec![] }, }),

Discussion:
The correct behavior is for both crates' docs to render as: <img src="https://user-" height="100"However, recent versions of nightly rustdoc render as the above, while rendering incorrectly as: <img src="https://user-" height="100"I believe this is a bug because that is not valid syntax in Rust.
bisects to in nightly-2022-06-23 ( &mdash;
Example affecting the standard library docs: not affected. <img src="https://user-" height="100"- broken. <img src="https://user-" height="100"
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. // compile-flags: -Z identify_regions -Z span_free_formats // ignore-tidy-linelength // Regression test for #43457: an `EndRegion` was missing from output // because compiler was using a faulty means for region map lookup. use std::cell::RefCell; fn rc_refcell_test(r: RefCell<i32>) { r.borrow_mut(); } fn main() { } // END RUST SOURCE // START rustc.node5.SimplifyCfg-qualify-consts.after.mir // // fn rc_refcell_test(_1: std::cell::RefCell<i32>) -> () { //     let mut _0: (); //     scope 1 { //         let _2: std::cell::RefCell<i32>; //     } //     let mut _3: std::cell::RefMut<'17dce, i32>; //     let mut _4: &'17dce std::cell::RefCell<i32>; // //     bb0: { //         StorageLive(_2); //         _2 = _1; //         StorageLive(_4); //         _4 = &'17dce _2; //         _3 = const <std::cell::RefCell<T>>::borrow_mut(_4) -> bb1; //     } // //     bb1: { //         drop(_3) -> bb2; //     } // //     bb2: { //         StorageDead(_4); //         EndRegion('17dce); //         _0 = (); //         StorageDead(_2); //         return; //     } // } </ins>

Discussion:
The following code compiles to MIR without any (this is right before the pass): Cc
Cc
Indeed, even the shows no for that borrow. Looking further now.
Very weird: It seems like at the time that control reaches this statement in , there is no destruction scope attached to it...? still looking... (I'm not aware of a place where a destruction scope would be later...)
A ha! The destruction scope exists, but during the HIR -HAIR translation, we fail to find it, because the way we look up the destruction scope is with some code that looks like this: but the that we got for that is , so the lookup doesn't have a chance of working. Now to figure out what is returning here (or if we perhaps should be using a different key for the lookup?)
that I should not be attempting to do in the first place here (which then goes south when I fail to find the appropriate to use), because the itself now carries the appropriate directly, thanks to (specifically ) Will fix!
Change:
//    in which case it will wait for the Enter key to be pressed before ///   continuing #[stable(feature = "rust1", since = "1.0.0")] <del> pub fn read_line(&mut self, buf: &mut String) -> io::Result<usize> { </del> <ins> pub fn read_line(&self, buf: &mut String) -> io::Result<usize> { </ins> self.lock().read_line(buf) } }

Discussion:
Currently, takes as . Why is that? The implementation simply locks and calls on the guard, and locking doesn't need a mutable . So this is unnecessary, and the doc doesn't say why this was done. (Nor does the source.) So I propose for this to be changed to . Looks like an oversight of some refactoring to me.
I imagine it's like that because the signature was copied off of the trait - changing it to take seems fine to me personally. cc
Yeah I think it'd be fine to switch to
Is it quicker for one of you to just do that, or should I submit a PR?
Go for it!
See .
Change:
<del> Subproject commit fd8101247749c5be6850d5cb5096f01a1867e5ba </del> <ins> Subproject commit eb5ff1791be706d173b4f4c29e9c0529b4235c0e </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
Change:
<ins> error[E0433]: failed to resolve: unresolved import --> $DIR/suggest-import-issue-120074.rs:12:35 | LL |     println!("Hello, {}!", crate::bar::do_the_thing); |                                   ^^^ unresolved import | help: a similar path exists | LL |     println!("Hello, {}!", crate::foo::bar::do_the_thing); |                                   ~~~~~~~~ help: consider importing this module | LL + use foo::bar; | help: if you import `bar`, refer to it directly | LL -     println!("Hello, {}!", crate::bar::do_the_thing); LL +     println!("Hello, {}!", bar::do_the_thing); | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'', 'thread 'rustc' panicked at 'index out of bounds: the len is 1 but the index is 1'' 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: [resolverforlowering_raw] getting the resolver for lowering --
I suspect this could be cc
what's the command line to reproduce it? I build nightly version and cannot reproduce it by only compiling the code. also I checked playground:
Ok, got it, we can not use 2021 edition in the command line.
Change:
} // Test some tuples. <del> fn f9<X: ?Sized>(x1: Box<S<X>>, x2: Box<E<X>>) { </del> <ins> fn f9<X: ?Sized>(x1: Box<S<X>>) { </ins> f5(&(*x1, 34)); //~^ ERROR `X: std::marker::Sized` is not satisfied } <del> fn f10<X: ?Sized>(x1: Box<S<X>>, x2: Box<E<X>>) { f5(&(32, *x2)); </del> <ins> fn f10<X: ?Sized>(x1: Box<S<X>>) { f5(&(32, *x1)); </ins> //~^ ERROR `X: std::marker::Sized` is not satisfied }

Discussion:
Backtrace: This seems to occur when using a non-struct type that contains an unsized type. This is probably because  only handles and the base unsized types. This should be extended to handle enums and tuples as well.
This is still happening. Does this mean we should avoid using DSTs for complex custom types for now?
Visiting for triage This is still an issue:
ICE also happens with a tupled trait object:
I've seen this too with: Reproducer: Version: Backtrace:
No longer reproduces but the other tests do.
cc
Is this the same as or related to ?
leads to . As mentioned inline, using the correct type works (). I'm using the Ubuntu PPA "rust-nightly", version ~~vivid.
Does not compile for other reasons that the ICE anymore. I've adjusted to the following and could not reproduce it anymore.
Another example hitting this same ICE:
Bugs similar to this one have been reported numerous times (most of the references to this issue are duplicates). Although it would be nice for reporters to search for similar issues before filing a new one, it's hard to blame them, since the ICE message from rustc tells people to file an issue. This issue itself was opened over two years ago. Separate from fixing the underlying problem, we should at least investigate displaying a real error instead of an ICE.
Change:
} } <ins> #[stable(feature = "socket_addr_from_str", since = "1.5.0")] impl FromStr for SocketAddrV4 { type Err = AddrParseError; fn from_str(s: &str) -> Result<SocketAddrV4, AddrParseError> { match Parser::new(s).read_till_eof(|p| p.read_socket_addr_v4()) { Some(s) => Ok(s), None => Err(AddrParseError(())), } } } #[stable(feature = "socket_addr_from_str", since = "1.5.0")] impl FromStr for SocketAddrV6 { type Err = AddrParseError; fn from_str(s: &str) -> Result<SocketAddrV6, AddrParseError> { match Parser::new(s).read_till_eof(|p| p.read_socket_addr_v6()) { Some(s) => Ok(s), None => Err(AddrParseError(())), } } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl FromStr for SocketAddr { type Err = AddrParseError;

Discussion:
I need to parse an ipv4 address. I feel like these impls are missing seeing as we have impls of for , and .
Change:
<ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `for<'r> fn(&'r X) -> _` ... LL |         |x| x |         ----- found signature of `fn(_) -> _` | = note: the return type of a function must have a statically known size error[E0271]: type mismatch resolving `for<'r> <[closure@$DIR/issue-57611-trait-alias.rs:21:9: 21:14] as std::ops::FnOnce<(&'r X,)>>::Output == &'r X` --> $DIR/issue-57611-trait-alias.rs:17:5 | LL |     type Bar = impl Baz<Self, Self>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter, found concrete lifetime | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors Some errors have detailed explanations: E0271, E0631. For more information about an error, try `rustc --explain E0271`. </ins>

Discussion:
The following code fails to compile (): with the following error If you make this modification, it compiles fine:
I think maybe cc or ?
I wonder whether this is a dupe of ?

Minimised, reproducible example: See Backtrace
Hello I'm getting the same ICE, but without any unstable features. I don't have a minimized example, though, but it may be another data point when searching for the problem. It's this commit: The commit happens with The code is not correct, it wouldn't compile even if the compiler didn't panic. It doesn't happen on stable, but I guess it's because it bails out sooner on closures taking references:
This still produces an error on the latest nightly (not sure if it's supposed to compile or not), but no longer ICEs.
Change:
if let Some(next_module) = binding.module() { module = Some(ModuleOrUniformRoot::Module(next_module)); record_segment_res(self, res); <del> } else if res == Res::ToolMod && i + 1 != path.len() { </del> <ins> } else if res == Res::ToolMod && !is_last && opt_ns.is_some() { </ins> if binding.is_import() { <del> self.tcx .sess .struct_span_err( ident.span, "cannot use a tool module through an import", ) .span_note(binding.span, "the tool module imported here") .emit(); </del> <ins> self.tcx.sess.emit_err(errors::ToolModuleImported { span: ident.span, import: binding.span, }); </ins> } let res = Res::NonMacroAttr(NonMacroAttrKind::Tool); return PathResult::NonModule(PartialRes::new(res));

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
works with any tool attr also compiles but it probably... shouldn't.
label +S-bug-has-mcve
Triaged with . Steps performed: Reproduced: Formatted: No change, already formatted Reduced: Bisected: Regression in nightly-2022-04-17 couldn't nail down the particular commit: <details<summaryDetails</summary<prustc version: Icemelter version: v0.2.0 Icemelter command line: Do you have feedback about this report? Please ! </p</details
another one `
Change:
if ctxt.may_break { // No way to know whether it's diverging because <del> // of a `break` or an outer `break` or `return. </del> <ins> // of a `break` or an outer `break` or `return`. </ins> self.diverges.set(Diverges::Maybe); }

Discussion:
Having the following main function results in an illigal instruction on stable, beta and nighlty. It should be noted that when is not used after the loop, the illigal instruction does not occur Interestingly putting the same while-loop in a function works fine:
Update: A more simple version that also results in an illigal instruction: after some more trying, it can be shortened to this (and works for functions other than in main, as shown here: ) : adding a statement at the end of main seems to 'fix' the problem
Checking with godbolt, 1.25 and above: results in undefined instruction (this issue) 1.18 to 1.24: ICE with broken MIR 1.17: becomes no-op 1.16 and below: Error "use of undeclared label "
Err the last example is even featured in (introduced in ), but why this seems not tested at all . Edit: It generates an at MIR level. <details<summaryThe initial MIR already contains an unreachable.</summary</details<details<summary-Zunpretty=hir,typed</summary</details
It's because in the example that is tested, there's no semicolon: Why that makes a difference, I haven't determined yet.
The problem is, for some reason, the type checker inferred to have type , and thus the rest of the block is . However, without the the inferred type is just as expected.
Maybe slightly off-topic, but why are references to the label even allowed in the condition, rather than solely the body? You don't achieve extra expressiveness, as it's equivalent to returning false in the condition, and it makes things more complicated.
having code like this results in an ICE:
Because it is consistent with the desugaring of the while loop to a which is a valid and fairly sensible code.
I think the bug in in the type-checker then: it should not be giving the type of , clear. — you interested in fixing? I can give a few tips...
Marking as P-medium: technically a regression, but a very old one, and kind of a corner case. Still, I'll try to leave some notes on how to fix.
yeah, I can have a look into this. Might be a little delayed, but definitely within the next couple of weeks.
Change:
assert_eq!(s, d); } <ins> #[test] fn test_drain() { let mut s = String::from("αβγ"); assert_eq!(s.drain(2..4).collect::<String>(), "β"); assert_eq!(s, "αγ"); let mut t = String::from("abcd"); t.drain(..0); assert_eq!(t, "abcd"); t.drain(..1); assert_eq!(t, "bcd"); t.drain(3..); assert_eq!(t, "bcd"); t.drain(..); assert_eq!(t, ""); } </ins> #[bench] fn bench_with_capacity(b: &mut Bencher) { b.iter(|| {

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has