jiebi/CodeConvo huggingface dataset:
Change:
"0x6a2c48091e6a2c48", "[0x56, 0x34, 0x12, 0x90, 0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56]", usize_isize_to_xe_bytes_doc!(), usize_isize_from_xe_bytes_doc!() } <del> widening_impl! { isize, i128, 64, signed } </del> } /// If 6th bit set ascii is upper case.

Discussion:
I had this question on the currently unreleased ; on signed carry (probably applies to substraction too ?); I have this test failing with the current code: Playground: Is the test correct ? A carry did happen in an intermediate calculation, but should the overall calculation report a carry ?
I agree that this is a bug. There's a carry when the calculation is done as unsigned, but this is not the same in signed. Another example: That incorrectly returns .
There's some discussion about that in the tracking issue, starting with
Yeah, it looks like I rehashed the same arguments, that's what I get for reading comments and doc too fast. Still, I think that this is surprising enough that it would be nice to address it somehow.
I agree this is a bug. It looks like it's implementing the signed version using the unsigned one, returning the same carry flag (), but that's incorrect. Here's another demonstration that it needs an update: you be up to making a fix PR, You can use to get assigned to this issue.
I have no bandwidth for making a fix right now. Since this was supposed to be helpers for bigint operations, my first idea was to just remove the signed variants. I have no idea if this would be appropriate. Anyone is welcome to do a proper fix, it shouldn't be too complicated.
A thought: What should do? It feels to me like the carryout from that should perhaps be , since the carry from that is different from the one in , which would imply that it couldn't be anymore. We do have a type that's -1, 0, or 1: . I can't decide if that's clever or horrible. Or should we just delete the signed versions for now?
I think should return , because signed and unsigned operations should give the same results, so should be computed as which gives , then truncated to 8-bits which gives . Then because gives , which can't be represented as an 8-bits signed number, then there is overflow to me. Now for the -1, 0, 1 overflow, I don't think it's necessary because the point of the bit is to indicate if it happened or not. The direction of overflow is indicated by the resulting value. If I am correct, then this raises another question: should intermediate overflow be detected or not ?

for example: gives a result of -128, so the output is the same as the input so no overflow. But if we break down the operations, overflows to 127, and then overflows back to -128. In this case should an overflow occur or not ? Considering my previous example, I personally think it intermediate overflow shouldn't be detected because it would be misleading: it would indicate that the sign of the source operands and the result are different while they are the same. Tho I'd like other's opinion.
I think so. The unsigned versions have clear semantics, but it gets weird with signed values, and as a "bigint helper" I'd be surprised to see one that uses signed digits in the first place.
Change:
<ins> error[E0283]: type annotations needed --> $DIR/region-overlap.rs:5:10 | LL | impl<'a> A for (&'static (), &'a ()) {} |          ^ cannot infer type for tuple `(&'static (), &'a ())` | = note: cannot satisfy `(&'static (), &'a ()): A` note: required by a bound in `A` --> $DIR/region-overlap.rs:4:1 | LL | trait A {} | ^^^^^^^ required by this bound in `A` error[E0283]: type annotations needed --> $DIR/region-overlap.rs:6:10 | LL | impl<'a> A for (&'a (), &'static ()) {} |          ^ cannot infer type for tuple `(&'a (), &'static ())` | = note: cannot satisfy `(&'a (), &'static ()): A` note: required by a bound in `A` --> $DIR/region-overlap.rs:4:1 | LL | trait A {} | ^^^^^^^ required by this bound in `A` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue
Change:
(hasher(&mut hcx, &cached_result), hasher(&mut hcx, &result)) }); let formatter = query.format_value(); <del> debug_assert_eq!( old_hash, new_hash, "Computed query value for {:?}({:?}) is inconsistent with fed value,n computed={:#?}nfed={:#?}", query.dep_kind(), key, formatter(&result), formatter(&cached_result), ); </del> <ins> if old_hash != new_hash { // We have an inconsistency. This can happen if one of the two // results is tainted by errors. In this case, delay a bug to // ensure compilation is doomed. qcx.dep_context().sess().delay_span_bug( DUMMY_SP, format!( "Computed query value for {:?}({:?}) is inconsistent with fed value,n computed={:#?}nfed={:#?}", query.dep_kind(), key, formatter(&result), formatter(&cached_result), ), ); } </ins> } } job_owner.complete(cache, result, dep_node_index);

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
cc
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-22 searched toolchains through Regression in
Change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! env { ($name:expr) => ({ /* compiler built-in */ }); ($name:expr,) => ({ /* compiler built-in */ }); } </ins> /// Optionally inspect an environment variable at compile time. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
pub fn __rust_begin_short_backtrace<F, T>(f: F) -> T where F: FnOnce() -> T, <del> F: Send, T: Send, </del> { <del> f() </del> <ins> let result = f(); // prevent this frame from being tail-call optimised away crate::hint::black_box(()); result } /// Fixed frame used to clean the backtrace with `RUST_BACKTRACE=1`. Note that /// this is only inline(never) when backtraces in libstd are enabled, otherwise /// it's fine to optimize away. #[cfg_attr(feature = "backtrace", inline(never))] pub fn __rust_end_short_backtrace<F, T>(f: F) -> T where F: FnOnce() -> T, { let result = f(); // prevent this frame from being tail-call optimised away crate::hint::black_box(()); result </ins> } pub enum RustBacktrace {

Discussion:
v.s. is less verbose, but I remember it also filtering out some stack frames in some previous compiler versions. (Only frame # 6 is really useful to me here.) Indeed, contains some code that looks for a symbol on the stack to find out what to filter. It looks like some functionality has regressed. Stepping through the program in gdb it looks like the function is called, but despite there’s apparently no stack frame (anymore?) for it. CC and for , , and .
contains a fix for this
Now being worked on in instead afaict?
It is.
This issue hasn't been active in almost two years, and so have the issues linked here. Is there any intention of resuming work on this? It's mostly a small papercut because currently when crashing, programs suggest: run with environment variable to display a backtrace. and after setting that, also claim that: Some details are omitted, run with for a verbose backtrace. even though no details were omitted at all (which is the issue of course)
A simple fix would be to just look for "std::rt::lang_start::{{closure}}" instead until the real solution to the disappearing function is found..
This single fix is likely to have the biggest positive effect on my use of Rust since async/await. Thank you so much!
Awesome! I'm happy to see this finally fixed :D Thanks to everyone who had a part in this fix :)
Change:
<ins> error[E0282]: type annotations needed --> $DIR/incompat-call-after-qualified-path-1.rs:25:6 | LL |   f(|a, b| a.cmp(b)); |      ^     - type must be known at this point | help: consider giving this closure parameter an explicit type | LL |   f(|a: /* Type */, b| a.cmp(b)); |       ++++++++++++ error[E0061]: this function takes 0 arguments but 1 argument was supplied --> $DIR/incompat-call-after-qualified-path-1.rs:25:3 | LL |   f(|a, b| a.cmp(b)); |   ^ --------------- unexpected argument | note: function defined here --> $DIR/incompat-call-after-qualified-path-1.rs:19:4 | LL | fn f() {} |    ^ help: remove the extra argument | LL -   f(|a, b| a.cmp(b)); LL +   f(); | error: aborting due to 2 previous errors Some errors have detailed explanations: E0061, E0282. For more information about an error, try `rustc --explain E0061`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'', 'thread 'rustc' panicked at 'range end index 1 out of range for slice of length 0'' 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 --
Regression in nightly-2022-06-04 commit[0] 2022-06-02: Auto merge of - nnethercote:lazify-SourceFile-lines, r=Mark-Simulacrum commit[1] 2022-06-02: Auto merge of - spastorino:simplify-universal-impl-trait-lowering, r=cjgillot commit[2] 2022-06-03: Auto merge of - matthiaskrgr:rollup-5cfxc85, r=matthiaskrgr commit[3] 2022-06-03: Auto merge of - c410-f3r:z-errors, r=petrochenkov commit[4] 2022-06-03: Auto merge of - cjgillot:remove-label-lt-shadow, r=petrochenkov commit[5] 2022-06-03: Auto merge of - Dylan-DPC:rollup-nswmgmx, r=Dylan-DPC commit[6] 2022-06-03: Auto merge of - lcnr:path-generics-diagnostics, r=estebank commit[7] 2022-06-03: Auto merge of - Dylan-DPC:rollup-2yxo7ce, r=Dylan-DPC commit[8] 2022-06-03: Auto merge of - bjorn3:serde_json, r=wesleywiser commit[9] 2022-06-03: Auto merge of - notriddle:notriddle/human-readable-signals, r=yaahc ERROR: no CI builds available between and within last 167 days
It appears I'm hitting this one as well. Tacking this on for good measure. <details</details
Looks like it was originally introduced by (and was renamed later to without any change in functionality). I'd PR a fix but I'm not entirely sure how it's supposed to work. Is this masking a deeper bug or can one simply do something like: Derp, missed there was a PR. indeed fixes this on my end. Thanks for the quick fix on this!
Change:
Some(sugared_span.map_or(attr.span, |span| span.with_hi(attr.span.hi()))); } <del> if attrs.peek().map(|next_attr| next_attr.is_doc_comment()).unwrap_or_default() { </del> <ins> if attrs.peek().map_or(false, |next_attr| next_attr.is_doc_comment()) { </ins> continue; }

Discussion:
Other expressions work as expected: it reports just one error, for the whole sequence of doc comment lines. () Errors:
( is a rustc lint.)
True, but I as well since it's a rustdoc-related lint.
Change:
<ins> //@ known-bug: rust-lang/rust#130310 use std::marker::PhantomData; #[repr(C)] struct A<T> { a: *const A<A<T>>, p: PhantomData<T>, } extern "C" { fn f(a: *const A<()>); } fn main() {} </ins>

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
<del> // 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. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // 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. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2011-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> static PI: f64 = 3.141592653589793; static SOLAR_MASS: f64 = 4.0 * PI * PI;

Discussion:
See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial (except artifacts as empty lines): OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () On 07/09/2014 09:59, Daniel Micay wrote: Developer | Willing Consulting +1 760 456 9366 |
Change:
pub fn exported_symbols(&self, tcx: TyCtxt<'a, 'tcx, 'tcx>) -> Vec<(ExportedSymbol<'tcx>, SymbolExportLevel)> { <del> let lazy_seq: LazySeq<(ExportedSymbol<'tcx>, SymbolExportLevel)> = LazySeq::with_position_and_length(self.root.exported_symbols.position, self.root.exported_symbols.len); lazy_seq.decode((self, tcx)).collect() </del> <ins> if self.proc_macros.is_some() { // If this crate is a custom derive crate, then we're not even going to // link those in so we skip those crates. vec![] } else { let lazy_seq: LazySeq<(ExportedSymbol<'tcx>, SymbolExportLevel)> = LazySeq::with_position_and_length(self.root.exported_symbols.position, self.root.exported_symbols.len); lazy_seq.decode((self, tcx)).collect() } </ins> } pub fn get_rendered_const(&self, id: DefIndex) -> String {

Discussion:
: : Steps to reproduce: This is failing when the crate attempts to import the crate (which is a crate). That is, if I modify 's file to only contain: rustc will ICE. <details<summaryBacktrace:</summary</details
I suspect this is a duplicate of , but I only count 2 #[procmacro] and 1 #[procmacro_attribute] in the repository.
The crate only has 1 and 1 . If I comment both of them out, the compiler still ICEs. The crate used to compile a couple weeks ago, so this was a fairly recent change.
To give some bounds on this: the crate compiles with . It fails with . I would bisect this with rustup to determine which nightly the issue started with, but .
Derp, I just remembered I could remove the component. Okay, doing that, I was able to bisect the nightlies: Last working version: First failing version:
I just did a git bisect, and it looks like commit (from PR ) is the source of the breakage. cc
visited for triage. Going to try to followup with . Assigning to self to keep myself honest about that claim.
also, P-high
Am looking at this.
Minified: // #[allow(unused)] // enum ProcMacroHack { // Input = (stringify!(ARGS), 0).1, // } // The problem is caused by containing "host" defids and being used in [trans]. I don't think that this field has any business containing host libraries when compiling a proc macro, but I'll ask for confirmation. [trans]:
visited for triage. Seems like PR handles this. Leaving as P-high
Change:
/// [`len`]: #method.len /// /// Note: This example shows the internals of `&str`. `unsafe` should not be <del> /// used to get a string slice under normal circumstances. Use `as_slice` </del> <ins> /// used to get a string slice under normal circumstances. Use `as_str` </ins> /// instead. #[stable(feature = "rust1", since = "1.0.0")] mod prim_str { }

Discussion:
has been renamed to as discussed in , but the old name is still referenced in the docs:
Change:
} } } else { <del> match p.parse_arg_general(named_args) { </del> <ins> match p.parse_arg_general(named_args, false) { </ins> Ok(arg) => Ok(Some(arg)), Err(mut e) => { e.emit();

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.
Change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] pub fn remove(&mut self, index: usize) -> T { <ins> #[cold] #[inline(never)] fn assert_failed(index: usize, len: usize) -> ! { panic!("removal index (is {}) should be < len (is {})", index, len); } </ins> let len = self.len(); <del> assert!(index < len); </del> <ins> if !(index < len) { assert_failed(index, len); } </ins> unsafe { // infallible let ret;

Discussion:
I've spotted, that panic message could've provided details on what values led to this panic, instead of mentioning condition only. Generally speaking this and some other s in Vec could've been more detailed. If it's okay to step in, I'd like to offer my help. In case of I'd suggest calling this instead I find this more informative than Candidates for improval: aforementioned : : : :
Does triaging mean a green light for this suggestion?
No, I just apply the relevant labels. :)
Though this is a small change with little time required to fix, so I'd just make the PR if I were you. :)
Note: uses the same kind of assertion in (as the old check had aliasing issues). Depending on which PR lands first, we should make sure it gets the same panic message as the others.
I think it makes sense to follow the message, that is being currently printed, when trying to access element out of bounds via . Current message template is . I followed this idiom to keep it consistent.
Change:
E0247, // found module name used as a type E0248, // found value name used as a type E0249, // expected constant expr for array length <del> E0250  // expected constant expr for array length </del> <ins> E0250, // expected constant expr for array length </ins> } __build_diagnostic_array! { DIAGNOSTICS }

Discussion:
Example: I left a FIXME at the relevant part of the code.
Nominating for something.
I can mentor...
I'm willing to have a look if the mentor offer stands
I already have a proposed fix, I just need to clean it up and add a test.
thanks for volunteering. The offer is still up but has been working on it. I'm happy to help with other bugs too.
Change:
#[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] impl<A: Step + One + Clone> DoubleEndedIterator for ops::Range<A> where <ins> for<'a> &'a A: Add<&'a A, Output = A>, </ins> for<'a> &'a A: Sub<&'a A, Output = A> { #[inline]

Discussion:
I tried printing all valid s by doing and was surprised to find it only printed up to 254. I'm unsure if this is supposed to be this way ( can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.
The problem is the next method of RangeFrom: It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a flag to RangeFrom.
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range).
Seems similar to .
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.)
Ruby has both exclusive and inclusive ranges
The origin is related to the for-loop idiom in C. corresponds to the range. It has some nice properties such as how it iterates over exactly elements, whereas an inclusive range does and would require you to say, for example, for the indices of a vector if were inclusive. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language.
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from to , inclusive?
cc , which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating .
so just to be clear, with the above PR merged, now panics. Is this the intended behavior?