jiebi/CodeConvo huggingface dataset:
Change:
///     surprising results upon inspecting the bit patterns, ///     as the same calculations might produce NaNs with different bit patterns. /// <del> /// When the number resulting from a primitive operation (addition, /// subtraction, multiplication, or division) on this type is not exactly /// representable as `f32`, it is rounded according to the roundTiesToEven /// direction defined in IEEE 754-2008. That means: </del> <ins> /// When a primitive operation (addition, subtraction, multiplication, or /// division) is performed on this type, the result is rounded according to the /// roundTiesToEven direction defined in IEEE 754-2008. That means: </ins> /// /// - The result is the representable value closest to the true value, if there ///   is a unique closest representable value.

Discussion:
The Rust documentation on states (emphasis mine): However, this does not specify the behavior for . This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be: In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of should be .
IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.
I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?
Something along the lines of "is not exactly representable as a distinct f32" perhaps?
I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums. "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.
Change:
<ins> error[E0133]: access to union field is unsafe and requires unsafe function or block --> $DIR/union-pat-in-param.rs:6:12 | LL | fn fun(U { a }: U) { |            ^ access to union field | = note: the field may not be properly initialized: using uninitialized data will cause undefined behavior error[E0133]: access to union field is unsafe and requires unsafe function or block --> $DIR/union-pat-in-param.rs:14:24 | LL |     let closure = |U { a }| { |                        ^ access to union field | = note: the field may not be properly initialized: using uninitialized data will cause undefined behavior error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0133`. </ins>

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 to see this happen: rustc rejecting this code. We are transmuting arbitrary types without unsafe, this is clearly unsound. Instead, this happened: rustc accepted this code, and it SIGSEGVs at runtime. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to have regressed between 1.76 and 1.77. In 1.76 (and below) it gave: It's probably related to the THIR unsafeck which in .
I'll take a look at this. I think I may have found out what's going on. claim
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening for beta nomination.
Fix backported via
Change:
let mut def_collector = DefCollector::new(&mut self.definitions); def_collector.visit_macro_invoc = Some(visit_macro_invoc); <del> def_collector.with_parent(def_index, |def_collector| if !const_integer { </del> <ins> def_collector.with_parent(def_index, |def_collector| { if const_integer { if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); } } </ins> expansion.visit_with(def_collector) <del> } else if let Expansion::Expr(ref expr) = *expansion { def_collector.visit_ast_const_integer(expr); </del> }); } }

Discussion:
This crate compiles fine with beta (0.13.0-beta.1) and stable (0.12.0).
Last nightly that worked: nightly-2016-09-27
Could be a duplicate of , cc
I have a fresh build from master, fixed this as well.
Yay!

Version: rustc 1.13.0-nightly ( 2016-09-27) thinks you may have some insight into this...
This was probably caused by -- I'll investigate.
Fixed in -- thanks for the report!
Change:
} // `x..y` where `x >= y`. The range is empty => error. (RangeEnd::Excluded, _) => { <del> self.tcx.sess.emit_err(LowerRangeBoundMustBeLessThanUpper { span }); </del> <ins> let mut lower_overflow = false; let mut higher_overflow = false; if let Some(hir::Expr { kind: hir::ExprKind::Lit(lit), .. }) = lo_expr && let rustc_ast::ast::LitKind::Int(val, _) = lit.node { if lo.eval_bits(self.tcx, self.param_env, ty) != val { lower_overflow = true; self.tcx.sess.emit_err(LiteralOutOfRange { span: lit.span, ty, max: max() }); } } if let Some(hir::Expr { kind: hir::ExprKind::Lit(lit), .. }) = hi_expr && let rustc_ast::ast::LitKind::Int(val, _) = lit.node { if hi.eval_bits(self.tcx, self.param_env, ty) != val { higher_overflow = true; self.tcx.sess.emit_err(LiteralOutOfRange { span: lit.span, ty, max: max() }); } } if !lower_overflow && !higher_overflow { self.tcx.sess.emit_err(LowerRangeBoundMustBeLessThanUpper { span }); } </ins> PatKind::Wild } // `x..=y` where `x == y`.

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
) { let res = binding.res(); if filter_fn(res) { <del> let def_id = res.def_id(); let has_self = match def_id.as_local() { Some(def_id) => { self.r.delegation_fn_sigs.get(&def_id).map_or(false, |sig| sig.has_self) } None => self .r .tcx .fn_arg_names(def_id) .first() .is_some_and(|ident| ident.name == kw::SelfLower), }; if has_self { return Some(AssocSuggestion::MethodWithSelf { called }); } else { match res { Res::Def(DefKind::AssocFn, _) => { </del> <ins> match res { Res::Def(DefKind::Fn | DefKind::AssocFn, def_id) => { let has_self = match def_id.as_local() { Some(def_id) => self .r .delegation_fn_sigs .get(&def_id) .map_or(false, |sig| sig.has_self), None => self .r .tcx .fn_arg_names(def_id) .first() .is_some_and(|ident| ident.name == kw::SelfLower), }; if has_self { return Some(AssocSuggestion::MethodWithSelf { called }); } else { </ins> return Some(AssocSuggestion::AssocFn { called }); } <del> Res::Def(DefKind::AssocConst, _) => { return Some(AssocSuggestion::AssocConst); } Res::Def(DefKind::AssocTy, _) => { return Some(AssocSuggestion::AssocType); } _ => {} </del> } <ins> Res::Def(DefKind::AssocConst, _) => { return Some(AssocSuggestion::AssocConst); } Res::Def(DefKind::AssocTy, _) => { return Some(AssocSuggestion::AssocType); } _ => {} </ins> } } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'', 'thread 'rustc' panicked at 'DefId(2: ~ core[ef64]::ops::index::Index::Output) does not have a "fnargnames"'' 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: [fnargnames] looking up function parameter names for [resolverforlowering_raw] getting the resolver for lowering --
cc
Change:
let owner = self.tcx.hir_owner_nodes(id.owner).as_owner()?; let node = owner.nodes[id.local_id].as_ref()?; let hir_id = HirId { owner: id.owner, local_id: node.parent }; <ins> // HIR indexing should have checked that. debug_assert_ne!(id.local_id, node.parent); </ins> Some(hir_id) } }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: with rustc this runs in a couple ms: with rustc this seems to hang somewhere in ( I killed the process after waiting for 5 minutes :upsidedownface: )
reduced: RIP
I think this is caused by cc
Clearly a well tested feature :stuckouttongue: I'll take a look.
The old code looked like this: The new code looks like this: because is no longer optional. The infinite recursion happens because the call returns a that is the same as the . When I printed that ID out it looks like this: An easy fix is to check if is the same as and return if so. But I don't know if that's just papering over a deeper problem. Is it an underlying bug that can return the same node it is given?
Change:
hi = self.span; self.bump(); <del> let index = n.as_str().parse::<usize>().ok(); </del> <ins> let invalid_msg = "invalid tuple or struct index"; let index = index_ident.as_str().parse::<usize>().ok(); </ins> match index { Some(n) => { <ins> if n.to_string() != index_ident.as_str() { let mut err = self.struct_span_err(self.prev_span, invalid_msg); err.span_suggestion(self.prev_span, "try simplifying the index", n.to_string()); err.emit(); } </ins> let id = respan(dot_span.to(hi), n); let field = self.mk_tup_field(e, id); e = self.mk_expr(lo.to(hi), field, ThinVec::new()); } None => { let prev_span = self.prev_span; <del> self.span_err(prev_span, "invalid tuple or tuple struct index"); </del> <ins> self.span_err(prev_span, invalid_msg); </ins> } } }

Discussion:
The following compiles, but I think it shouldn't?
The field name is converted to a number too eagerly. This doesn't happen in struct expressions and patterns.
Change:
/// Base functionality for all errors in Rust. #[stable(feature = "rust1", since = "1.0.0")] <del> pub trait Error: Debug + Display + Send { </del> <ins> pub trait Error: Debug + Display { </ins> /// A short description of the error. /// /// The description should not contain newlines or sentence-ending

Discussion:
The trait was recently changed, once again, to inherit from . This was done mostly because suspect that many people will wind up using , especially once incorporated downcasting, worried that, after setting up such APIs, people would end up wanting to send between threads and not be able to, and, suspected that most errors would or could be made anyway. However, there are some cases in important libraries like Iron that involve non- errors, at least at the moment. We need to make a final decision here. Should we instead require people to know about and use when they need it?
cc
cc :)
note that this is blocking iron from building, so a swift decision would be quite appreciated
My feeling, as summarized to over IRC: better to be more general. If it turns out that people forget the Send a lot (and they probably will), we can always introduce an alias or something for , and converting from to ought to... mostly be compatible.
Does anyone think this needs an RfC? Though I believe the original RfC doesn't mention the bound so perhaps it's okay.
Yeah, I would consider this a relatively minor implementation detail. It's gone back and forth a few times since the original reform. I'm personally OK changing it a final time without an RFC.
Change:
<ins> // Regression test for <https://github.com/rust-lang/rust/issues/92859>. #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![crate_name = "foo"] // @has 'foo/trait.Foo.html' pub trait Foo: Sized { const WIDTH: usize; fn arrayify(self) -> [Self; Self::WIDTH]; } impl<T: Sized> Foo for T { const WIDTH: usize = 1; // @has - '//*[@id="tymethod.arrayify"]/*[@class="code-header"]'  // 'fn arrayify(self) -> [Self; Self::WIDTH]' fn arrayify(self) -> [Self; Self::WIDTH] { [self] } } </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --With the experimental feature (), there's a compiler issue that surfaces during documentation generation but not a regular build. In the code example below, produces an unhelpful error message. <!-- 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. --: The error on running is: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Isn't it the same as ?
No, I don't think so, that initial instance did not require to be enabled (we controlled for that variable using ).
looks fixed to me, marking as needs-test
Change:
<ins> // #120427 // This test checks that when a single cfg has a value for user's specified name // // check-pass // compile-flags: -Z unstable-options // compile-flags: --check-cfg=cfg(foo,values("my_value")) --check-cfg=cfg(bar,values("my_value")) #[cfg(my_value)] //~^ WARNING unexpected `cfg` condition name: `my_value` fn x() {} fn main() {} </ins>

Discussion:
The user wanted something with "linux", and there is a name-value cfg that has the value "linux", so they probably wanted that. No response
Change:
let self_ty = ty::lookup_item_type(self.tcx, def_id).ty; match ty::get(self_ty).sty { ty::ty_enum(def_id, _) | <del> ty::ty_struct(def_id, _) => { </del> <ins> ty::ty_struct(def_id, _) | ty::ty_trait(box ty::TyTrait{ def_id, ..}) => { </ins> if def_id.krate != ast::LOCAL_CRATE { span_err!(self.tcx.sess, item.span, E0116, "cannot associate methods with a type outside the 

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
<del> //@ known-bug: rust-lang/rust#130372 pub fn variadic_fn(n: usize, mut args: ...) {} reuse variadic_fn; fn main() { variadic_fn(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' 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 -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
<ins> use std::net::TcpStream; fn main() { let stream = TcpStream::new(); //~ ERROR no function or associated item named `new` found } </ins>

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
<del> //@ known-bug: rust-lang/rust#126416 trait Output<'a, T: 'a> { type Type; } struct Wrapper; impl Wrapper { fn do_something_wrapper<O, F>(&mut self, _: F) where F: for<'a> FnOnce(<F as Output<i32>>::Type), { } } fn main() { let mut wrapper = Wrapper; wrapper.do_something_wrapper(|value| ()); } </del>

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<strongICE location label +F-unboxedclosures
Regression in nightly-2024-03-22
Minimized: <details<summaryError output</summary</details labels -F-unboxed_closures
duplicate of ?
it would be nice if you could check the bugtracker before posting something, as right now about 30-50% of your bugreports are just re-reports of ices we already know about it seems :upsidedownface:

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: relating different kinds: (Alias(Projection, AliasTy { args: [?3t, !101.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'"), i32], defid: DefId(0:6 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::Output::Type), usealiastynewinstead: () }),) !71.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'")', 'error: internal compiler error: relating different kinds: (Alias(Projection, AliasTy { args: [?3t, !101.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'"), i32], defid: DefId(0:6 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::Output::Type), usealiastynewinstead: () }),) !71.Named(DefId(0:16 ~ C20C3EF57DBBF6727FABBD162A0D132F6096AD3675C924B540DA66E336EE31F0[a82c]::{impl}::dosomethingwrapper::'), "'")' 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 -- label +F-unboxedclosures <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in nightly-2024-02-15 cc :sweat_smile:
an ICE in the middle of constructing an error, these can usually be solved with some tainting, I'll investigate
I can take a look at this since it's been a month hehe claim