jiebi/CodeConvo huggingface dataset:
Code change:
without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog2(self) -> u32 { <del> match self.checked_ilog2() { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> self.checked_ilog2().expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 10 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is negative or zero it panics in debug mode and the return value /// is 0 in release mode. </del> <ins> /// This function will panic if `self` is less than or equal to zero. </ins> /// /// # Example ///

Related discussion:
text: ]
Also, since the methods are implemented for signed integers as well, another issue would be the log of negative values. For example for floating-point, would return &minus;&infin;, but would return NaN. So if would return some value for &minus;&infin;, would panic anyway, or return some value?
I don't think it makes sense to do anything other than panic in the case of negative values, which in turn is probably an argument for panicking on zero as well. I guess one could argue that "wrapping" could be interpreted as wrapping the preimage to fit in the function's domain (rather than just wrapping the image to fit in the range) but IMO that would be entirely unintuitive and unhelpful as well. After thinking about it a bit, it seems to me that simply cannot have a meaningful variant, because semantics (as reasonably interpreted) cannot answer the question "what should the result be for values for which the original function is undefined?" There are no elements in 's domain for which the function underflows or overflows.
That's only the case on old chips. As I linked in the OP (), that happens in the instruction generation very-last-phase of LLVM on old chips, and on newer chips it knows to emit a different instruction instead of the branching code: The good news is that it looks like newer LLVM has gotten smarter here. It used to be that, because of how the intrinsic gets translated, it would emit obviously-redundant assembly on old chips in some code patterns, as you could see in Rust 1.16:
is supposed to find the largest so that . Since computers use wrapping arithmetic, the equation is better put as . The largest satisfying this equation in the case is (aka ). So if we consider a wrapping to be the inverse of , makes perfect sense (and is very efficient on modern CPUs, as others have pointed out). I would also advocate for to be as a method which always has this behaviour. [Edit: it already behaves that way]
Note that's already how works . It's just that it wraps to in release right now -- this issue doesn't propose removing the panic in debug behaviour, just to figure out what the best value for release would be.
Code change:
without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog2(self) -> u32 { <del> match self.checked_ilog2() { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> self.checked_ilog2().expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 10 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is negative or zero it panics in debug mode and the return value /// is 0 in release mode. </del> <ins> /// This function will panic if `self` is less than or equal to zero. </ins> /// /// # Example ///

Related discussion:
text: Since, from the notes, it seems like the libs-api meeting today said "how about we panic instead of wrap", I'll try to answer my own question from above: I would propose the following rule: Conceptually, the result is first calculated in true ℤ (aka to infinite precision). Then for the non-prefixed versions If that result is undefined (, , etc), then it panics (regardless of compilation mode) If that result is defined and fits in the result type, it's returned. If that result is defined but not in-range for the result type, it panics if overflow checking is enabled, and wraps (mod 2<supN</supfor uN) if overflow checking is disabled. I think that's consistent with all the current precedent. ( also is good reading about the distinction I'm drawing here.)
I would redefine that to include cases where the result is defined but you can't wrap that to the result type, e.g. or . that would cover and
I agree, but was considering that implied by "in ℤ", as that set includes neither −∞ nor ⅈ. (Like how is , not a complex number.)
I'm not necessarily against panicking in that case. I just pointed out how it's a bit inconsistent with the other operations we have on integers. (Whether it makes sense for the other operations to have this difference in behavior between debug and release mode is an interesting discussion too, but I'm afraid that ship has sailed.) The reason we don't always panic on overflow for and etc. is performance. It's simply too costly to do. (We always panic on division by zero because that's both mathematically undefined (even modulo 2<supBITS</sup) and because on some platforms, the native division instruction will signal/abort/trap the program when the right hand side is zero.) We applied the same reasoning to things like and , although one might reasonably argue that for those it might be fine to always panic, since these are not as common as and . (You could then still use if you really want to make sure there's no check, if you're sure it's unnecessary.) That seems reasonable. It'd be nice if it'd still be easy to get the efficient calculation through some usage of or though.
Code change:
without modifying the original"] #[inline] #[track_caller] <del> #[rustc_inherit_overflow_checks] #[allow(arithmetic_overflow)] </del> pub const fn ilog2(self) -> u32 { <del> match self.checked_ilog2() { Some(n) => n, None => { // In debug builds, trigger a panic on None. // This should optimize completely out in release builds. let _ = Self::MAX + 1; 0 }, } </del> <ins> self.checked_ilog2().expect("argument of integer logarithm must be positive") </ins> } /// Returns the base 10 logarithm of the number, rounded down. /// /// # Panics /// <del> /// When the number is negative or zero it panics in debug mode and the return value /// is 0 in release mode. </del> <ins> /// This function will panic if `self` is less than or equal to zero. </ins> /// /// # Example ///

Related discussion:
text: It looks like llvm isn't smart enough today to turn into simply a count-leading-zeros and a subtract instruction. :(
We discussed this again in the libs-api meeting, and we concluded pretty much the same as rule, meaning that these functions should panic on zero in all compilation modes, since there's not a modulo-2<supN</sup-correct result.
Code change:
std::env::var("TARGET").is_ok_and(|v| v.contains("i586")) } <ins> #[cfg(target_arch = "x86_64")] fn f16(){ const_assert!((1f16).to_bits(), 0x3c00); const_assert!(u16::from_be_bytes(1f16.to_be_bytes()), 0x3c00); const_assert!((12.5f16).to_bits(), 0x4a40); const_assert!(u16::from_le_bytes(12.5f16.to_le_bytes()), 0x4a40); const_assert!((1337f16).to_bits(), 0x6539); const_assert!(u16::from_ne_bytes(1337f16.to_ne_bytes()), 0x6539); const_assert!((-14.25f16).to_bits(), 0xcb20); const_assert!(f16::from_bits(0x3c00), 1.0); const_assert!(f16::from_be_bytes(0x3c00u16.to_be_bytes()), 1.0); const_assert!(f16::from_bits(0x4a40), 12.5); const_assert!(f16::from_le_bytes(0x4a40u16.to_le_bytes()), 12.5); const_assert!(f16::from_bits(0x5be0), 252.0); const_assert!(f16::from_ne_bytes(0x5be0u16.to_ne_bytes()), 252.0); const_assert!(f16::from_bits(0xcb20), -14.25); // Check that NaNs roundtrip their bits regardless of signalingness // 0xA is 0b1010; 0x5 is 0b0101 -- so these two together clobbers all the mantissa bits // NOTE: These names assume `f{BITS}::NAN` is a quiet NAN and IEEE754-2008's NaN rules apply! const QUIET_NAN: u16 = f16::NAN.to_bits() ^ 0x0155; const SIGNALING_NAN: u16 = f16::NAN.to_bits() ^ 0x02AA; const_assert!(f16::from_bits(QUIET_NAN).is_nan()); const_assert!(f16::from_bits(SIGNALING_NAN).is_nan()); const_assert!(f16::from_bits(QUIET_NAN).to_bits(), QUIET_NAN); if !has_broken_floats() { const_assert!(f16::from_bits(SIGNALING_NAN).to_bits(), SIGNALING_NAN); } } </ins> fn f32() { const_assert!((1f32).to_bits(), 0x3f800000); const_assert!(u32::from_be_bytes(1f32.to_be_bytes()), 0x3f800000);

Related discussion:
text: This file is only and : , but we should add the other float types to this test. The change should wait for since that changes some of these semantics (this PR is almost merged). There are probably a handful of tests that only check and but could use updates with the new types. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Okay will do that
FYI you can comment to assign yourself an issue
claim
Code change:
suffix: &'pat [Pat<'tcx>], ) { let tcx = self.tcx; <del> let (min_length, exact_size) = match place .clone() .into_place(tcx, self.typeck_results) .ty(&self.local_decls, tcx) .ty .kind() </del> <ins> let (min_length, exact_size) = if let Ok(place_resolved) = place.clone().try_upvars_resolved(tcx, self.typeck_results) </ins> { <del> ty::Array(_, length) => (length.eval_usize(tcx, self.param_env), true), _ => ((prefix.len() + suffix.len()).try_into().unwrap(), false), </del> <ins> match place_resolved .into_place(tcx, self.typeck_results) .ty(&self.local_decls, tcx) .ty .kind() { ty::Array(_, length) => (length.eval_usize(tcx, self.param_env), true), _ => ((prefix.len() + suffix.len()).try_into().unwrap(), false), } } else { ((prefix.len() + suffix.len()).try_into().unwrap(), false) </ins> }; match_pairs.extend(prefix.iter().enumerate().map(|(idx, subpattern)| {

Related discussion:
text: Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.
Code change:
<ins> error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Related discussion:
text: I expected just a compiler error . Compiler panicked: Meta
This is fixed in the beta version (1.30).
Code change:
<ins> error[E0596]: cannot borrow data in a `&` reference as mutable --> $DIR/issue-52240.rs:9:27 | LL |     if let (Some(Foo::Bar(ref mut val)), _) = (&arr.get(0), 0) { |                           ^^^^^^^^^^^ cannot borrow as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>

Related discussion:
text: This lets you get a mutable reference to an immutable value under a specific case. Code: From what I can tell, the tuple and at least two depths of Enums are necessary, along with an on the right side. There's probably other variations, but that seems to work well enough. Expected output would be a compile error, instead output is This works on both stable and nightly
would fix this as well?
Fixed by . Off: I wonder why we can't ship nll yet. It would solve so many issues right now, because of the match ergonomics sigh Match ergonomics produces roughly 10% of all errors/unsoundness/ICEs atm (at least it feels like this)
Yes correctly fixed this issue.
Code change:
rscope: &RegionScope, span: Span, principal_trait_ref: ty::PolyTraitRef<'tcx>, <del> mut projection_bounds: Vec<ty::PolyProjectionPredicate<'tcx>>, // Empty for boxed closures </del> <ins> projection_bounds: Vec<ty::PolyProjectionPredicate<'tcx>>, // Empty for boxed closures </ins> partitioned_bounds: PartitionedBounds) -> ty::ExistentialBounds<'tcx> {

Related discussion:
text: It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).
Code change:
rscope: &RegionScope, span: Span, principal_trait_ref: ty::PolyTraitRef<'tcx>, <del> mut projection_bounds: Vec<ty::PolyProjectionPredicate<'tcx>>, // Empty for boxed closures </del> <ins> projection_bounds: Vec<ty::PolyProjectionPredicate<'tcx>>, // Empty for boxed closures </ins> partitioned_bounds: PartitionedBounds) -> ty::ExistentialBounds<'tcx> {

Related discussion:
text: Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/
Code change:
/// A free importable items suggested in case of resolution failure. struct ImportSuggestion { <ins> did: Option<DefId>, </ins> path: Path, }

Related discussion:
text: For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.
Code change:
"cargo_metadata 0.9.1", "clippy-mini-macro-test", "clippy_lints", <del> "compiletest_rs", </del> <ins> "compiletest_rs 0.5.0", </ins> "derive-new", "lazy_static 1.4.0", "regex",

Related discussion:
text: 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! And nominating for compiler team prioritization.
Code change:
<ins> error: pretty-print failed to write `/tmp/` due to $ERROR_MESSAGE error: aborting due to previous error </ins>

Related discussion:
text: If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim
Code change:
<ins> // Copyright 2016 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. // ignore-cross-compile #![crate_name = "foo"] pub trait SomeTrait {} pub struct SomeStruct; // @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#19' impl SomeTrait for usize {} // @has foo/trait.SomeTrait.html '//a/@href' '../src/foo/issue-43893.rs.html#22-24' impl SomeTrait for SomeStruct { // deliberately multi-line impl } </ins>

Related discussion:
text: It should work a bit like IDE's feature that finds everything that implements a given interface.
This should be a fairly small change (the most annoying part has already been done) so i'll open this up as a mentored issue. The bit that writes out the "Implementors" section is in . This is where the known implementors for a given trait are pulled out of the global context and listed out onto the rendered page. The bit that's responsible for creating links is , implemented on a local type. This kind of Item is easily made from the kind of Item that's otherwise worked on in , but there's a catch: The entries in the Implementors list aren't s. They're s, which are only a subset of the things you get on an Item. This is the "most annoying part" i mentioned earlier. Fortunately, i ran into this when creating the "Implementations on Foreign Types" section, so if you scroll up a little in , you can see so i could render the full impl block for them. The task for anyone who wants to take this on is to pull that up a little so that it's used for all the implementors, not just the foreign ones. With a in hand, combine it with the Context to create a and call to generate the link. ( This also helpfully includes the extra HTML bits that will flush the link to the right edge, which is really the final step.) And... that's it! The link should probably go between the and the where clause underneath it, so that it's aligned with the impl line and not the where clause. You may need to also close/open the that's wrapping the whole line to make sure the link itself isn't monospace. If you have any questions, let me know! Either comment here, or hop onto IRC in , or the impl period Gitter under .
Code change:
let gcx = self.infcx.tcx.global_tcx(); let mut orig_values = OriginalQueryValues::default(); <del> let c_data = self.infcx.canonicalize_query( </del> <ins> // HACK(matthewjasper) `'static` is special-cased in selection, // so we cannot canonicalize it. let c_data = self.infcx.canonicalize_hr_query_hack( </ins> &self.param_env.and(*data), &mut orig_values); debug!("QueryNormalizer: c_data = {:#?}", c_data); debug!("QueryNormalizer: orig_values = {:#?}", orig_values);

Related discussion:
text: Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.
Code change:
let gcx = self.infcx.tcx.global_tcx(); let mut orig_values = OriginalQueryValues::default(); <del> let c_data = self.infcx.canonicalize_query( </del> <ins> // HACK(matthewjasper) `'static` is special-cased in selection, // so we cannot canonicalize it. let c_data = self.infcx.canonicalize_hr_query_hack( </ins> &self.param_env.and(*data), &mut orig_values); debug!("QueryNormalizer: c_data = {:#?}", c_data); debug!("QueryNormalizer: orig_values = {:#?}", orig_values);

Related discussion:
text: Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.