jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0060]: this function takes at least 1 argument but 0 arguments were supplied --> $DIR/mismatch-args-vargs-issue-130372.rs:9:9 | LL |         test_va_copy(); |         ^^^^^^^^^^^^-- argument #1 of type `u64` is missing | note: function defined here --> $DIR/mismatch-args-vargs-issue-130372.rs:5:22 | LL | unsafe extern "C" fn test_va_copy(_: u64, mut ap: ...) {} |                      ^^^^^^^^^^^^ ------ help: provide the argument | LL |         test_va_copy(/* u64 */); |                     ~~~~~~~~~~~ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0060`. </ins>

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:
} } } else { <del> // Cross-crate closure types should only be // visible in codegen bug reports, I imagine. p!(write("@{:?}", did)); </del> <ins> p!(write("@{}", self.tcx().def_path_str(did))); </ins> if substs.as_generator().is_valid() { let upvar_tys = substs.as_generator().upvar_tys();

Discussion:
Follow-up of Consider this example: It emits the stderr on my local (x86_64-unknown-linux-gnu): But on some other environment on CI, e.g. or , it emits it with a tiny difference: It's ideal to have the same diagnostics on all the environment. See also:
s shouldn't be leaked in user output.
Yeah, other places look like: Perhaps we emit accidentally in somewhere.
that makes me think that we probably have some instead of somewhere.
The relevant code is: I don't find any difference between here and similar places yet. thoughts?
the place to look at is: CC The same applies to closures, but we are likely not displaying them this way anywhere (or we've just gotten lucky).
Change:
use time::Duration; use sync::{Once, ONCE_INIT}; <ins> const NANOS_PER_SEC: i64 = 1_000_000_000; </ins> pub struct SteadyTime { t: libc::LARGE_INTEGER, }

Discussion:
The of uses a 64 bit multiplication that will overflow frequently. Using floats would be the easy way out, but it would reduce precision to 53 bits.
As a datapoint, this is literally what . Where is a . But we're multiplying by an extra 1000.
In fairness to Microsoft, they're operating on a time difference computed mod 2^64, so as long as the interval length is reasonable (less than a few thousand hours for a typical tick rate) it can't overflow. But computes an absolute time rather than a difference, so overflows are guaranteed to happen at some point. The 1000x factor only makes it more noticeable.
Since we're dealing with absolute time (and therefore something large), it's probably not unreasonable to divide first, or maybe even partially multiply by . Something like: maybe? What are "typical" and "extreme" tick rates and absolute ticks like? An incredibly robust implementation could presumably branch on the size of ticks to determine the optimal split of the .
The x86_64 architecture has the 64 bit MUL instruction whose result is effectively a 128 bit integer which never overflows. Likewise, the DIV instruction takes an effectively 128 bit integer as the dividened. i386 offers (u32, u32) -u64 MUL and (u64, u32) -(u32, u32) DIV/MOD, so we should be able to implement 64 bit MUL and DIV without overflow. Windows RT runs on ARMv7 (=~ Cortex-A). It has (u32, u32) -u64 UMULL but lacks DIV and we have to call a division routine. Perhaps we can forget about it for now...
We could use techniques similar to . Of course, in this case, we also have the multiplier, which together with the "magic constant" is going to overflow even a 128 bit register, but multiplication can be done "in parts".
Don't OSX and iOS have a similar problem and ? What is the typical value of seems to suggest that is can be large, just like on Windows.
^
Change:
<ins> // only-x86_64-unknown-linux-gnu #![feature(const_transmute)] const ZST: &[u8] = unsafe { std::mem::transmute(1usize) }; //~ ERROR cannot transmute between types of different sizes, or dependently-sized types </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. --code from <!-- 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
label -T-compiler +T-rustdoc
MCVE: I expect this is the same sort of issue as where rustdoc ignores errors that the compiler requires to be emitted. Assigning P-low by the same rationale as
I found a similar duplicate.
Triage: fixed by , marking as .
Change:
/// Returns the size of a type in bytes. /// <ins> /// More specifically, this is the offset in bytes between successive /// items of the same type, including alignment padding. /// </ins> /// # Examples /// /// ```

Discussion:
Discussion of with the lang team led to inspection of the documentation for and () just says "returns the size of a type in bytes." Understanding what this means (and deciding whether it is true or not) depends on how one interprets the word "size" in that sentence. () is worse. Why? Because it adds the additional paragraph: This is much more specific, but the specifics are wrong in terms of that the implementation does. The quoted text is describing the notion of "size" as . But Rust's implementation of ends up eventually calling out to LLVM's , which: At this point we cannot change the name nor the behavior of -- which is fine, since as I understand it, the behavior of basically matches that of in the C/C++ language family. But we should: the documentation for , to make it clear what its behavior is (for this, we might as well point out that it is behaving like "stride" in Swift's terms) should either fix the documentation for so it no longer outright lies, or replace that single intrinsic with a pair of intrinsics that are analogous to Swift's and . (With respect to , if we do introduce an analogous distinction, we will have to choose a name other than "size" for the quantity that is not forcibly rounded up to a multiple of the alignment. Maybe "length", "fill", or "utilization"...) Neither of the above items are incredibly high priority, since the docs are not currently lying (just vague), and is unstable. But it would probably be good to address at least one of the two, for these reasons: to avoid users making invalid inferences about 's behavior (and thus manually rounding up its results to each type's alignment), and to avoid some well-meaning Rust developer cut-and-pasting the docs over into .
I'd like to take this one if is alright with it.
Change:
LL |         pub fn also_undocumented1() {} |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 19 previous errors </del> <ins> error: missing documentation for a function --> $DIR/lint-missing-doc.rs:189:5 | LL |     pub fn extern_fn_undocumented(f: f32) -> f32; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: missing documentation for a static --> $DIR/lint-missing-doc.rs:194:5 | LL |     pub static EXTERN_STATIC_UNDOCUMENTED: u8; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: missing documentation for a foreign type --> $DIR/lint-missing-doc.rs:199:5 | LL |     pub type ExternTyUndocumented; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 22 previous errors </ins>

Discussion:
It seems like this lint should fire if you have an declaration without docs on it. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-lint T-compiler C-bug
I think I know what causes this and will write a more general fix here this week. claim
the fix wasn't more general but it's a fix none the less
Change:
fn((uint, Option<V>)) -> Option<(uint, V)>> } <ins> #[unstable] pub struct Drain<'a, V> { iter: FilterMap< (uint, Option<V>), (uint, V), Enumerate<vec::Drain<'a, Option<V>>>, fn((uint, Option<V>)) -> Option<(uint, V)>> } #[unstable] impl<'a, V> Iterator for Drain<'a, V> { type Item = (uint, V); fn next(&mut self) -> Option<(uint, V)> { self.iter.next() } fn size_hint(&self) -> (uint, Option<uint>) { self.iter.size_hint() } } #[unstable] impl<'a, V> DoubleEndedIterator for Drain<'a, V> { fn next_back(&mut self) -> Option<(uint, V)> { self.iter.next_back() } } </ins> #[stable] impl<'a, V> Iterator for Keys<'a, V> { type Item = uint;

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
fn bar /* 0#0 */() { let x /* 0#0 */ = 1; y /* 0#1 */ + x /* 0#0 */ } fn y /* 0#0 */() { } <ins> /* Expansions: 0: parent: ExpnId(0), call_site_ctxt: #0, kind: Root 1: parent: ExpnId(0), call_site_ctxt: #0, kind: Macro(Bang, foo) SyntaxContexts: #0: parent: #0, outer_mark: (ExpnId(0), Opaque) #1: parent: #0, outer_mark: (ExpnId(1), SemiTransparent) */ </ins>

Discussion:
E.g. becomes Specifically, the syntax contexts of and are linked (the s refer to the same identifier, even with hygiene) but this is not represented in the output at all, so one might interpret them as being distinct identifiers.
There is no more pretty=hygene, was it replaced with something?
Closing. is apparently no longer a thing, and the output looks sufficiently different with that I don't think it's the same.
There is a FIXME related to this issue, Now that the issue is closed can the FIXME be fix, or made more specific?
Looks like is a thing though so reopening... output today is below. I'm not completely sure whether this is fixed or not --- the output looks the same for the two s, I guess? Not sure which are being referred to either...
Change:
<ins> error[E0407]: method `from` is not a member of trait `Fn` --> $DIR/issue-87558.rs:6:5 | LL |     fn from() {} |     ^^^^^^^^^^^^ not a member of trait `Fn` error[E0183]: manual implementations of `Fn` are experimental --> $DIR/issue-87558.rs:3:6 | LL | impl Fn(&isize) for Error { |      ^^^^^^^^^^ manual implementations of `Fn` are experimental | = help: add `#![feature(unboxed_closures)]` to the crate attributes to enable error[E0229]: associated type bindings are not allowed here --> $DIR/issue-87558.rs:3:6 | LL | impl Fn(&isize) for Error { |      ^^^^^^^^^^ associated type not allowed here error: aborting due to 3 previous errors Some errors have detailed explanations: E0183, E0229, E0407. For more information about an error, try `rustc --explain E0183`. </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. --<!-- 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
So, will fix this ICE. But the coherence code should probably not be passing escaping bound vars to begin with. As for prioritization, this is an ICE that occurs only after an error that, if fixed, will solve the ICE. I say low or medium.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
didn't fix this ICE; it's actually different than others and utterly broken (as expected)
No longer ICEs since
Change:
continue; } <del> let result = select.select(&Obligation::new(dummy_cause.clone(), new_env, pred)); </del> <ins> // Call infcx.resolve_type_vars_if_possible to see if we can // get rid of any inference variables. let obligation = infcx.resolve_type_vars_if_possible( &Obligation::new(dummy_cause.clone(), new_env, pred) ); let result = select.select(&obligation); </ins> match &result { &Ok(Some(ref vtable)) => {

Discussion:
When I tried to build docs for , I got a panic. Here is the reduced test case: With the above code, when I run I get this panic: rustc 1.27.0-nightly ( 2018-04-18) binary: rustc commit-hash: commit-date: 2018-04-18 host: x86_64-pc-windows-msvc release: 1.27.0-nightly LLVM version: 6.0
Strange... Will take a look as soon as possible.
So the call is performed . I'll need help from (or anyone in the team who knows about the type) in order to fix this issue.
Reduced further:
I'd like to work on this.
Thank you so much! I verified that with the latest Rust Nightly I no longer get any errors.
Change:
<ins> // check-pass // Test to check that pointee trait doesn't let region variables escape into the cache #![feature(ptr_metadata)] trait Bar: Sized + 'static {} struct Foo<B: Bar> { marker: std::marker::PhantomData<B>, } impl<B: Bar> Foo<B> { fn foo<T: ?Sized>(value: &T) { std::ptr::metadata(value); } } fn main() {} </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. --I recently updated my nightly toolchain and our project (still not open-sourced) ICE'd. I managed to reduce the problem to a minimal working example: <!-- 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</detailsI ran a quick : searched nightlies: from nightly-2022-03-01 to nightly-2022-03-24 regressed nightly: nightly-2022-03-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe offending line is the , so we should probably tag this with the appropriate feature tag. (Sorry if I messed anything up, I'm completely new to Rust ICE bug reports!) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
probably due to my PR claim
I get the same error on code that I got minimized to:
Same error with this example:
Same error I got with this example Defining it in a trait is fine though But adding a function body results in a crash
Change:
fn main() { for _ in unimplemented!() as Void {} //~^ ERROR unreachable pattern <ins> //~^^ ERROR unreachable pattern </ins> }

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
}; use rustc_session::lint; use rustc_span::sym; <del> use rustc_span::{MultiSpan, Span, Symbol}; </del> <ins> use rustc_span::{MultiSpan, Span, Symbol, DUMMY_SP}; </ins> use rustc_trait_selection::infer::InferCtxtExt; use rustc_data_structures::stable_map::FxHashMap;

Discussion:
produces: It expanded the macro. This only happens when the macro invocation is the entire body of the closure.
cc
Working on a fix.
Change:
<ins> // check-pass // Verify that variant count intrinsic can still evaluate for types like `Option<T>`. #![feature(variant_count)] pub struct GetVariantCount<T>(T); impl<T> GetVariantCount<T> { pub const VALUE: usize = std::mem::variant_count::<T>(); } const fn check_variant_count<T>() -> bool { matches!(GetVariantCount::<Option<T>>::VALUE, GetVariantCount::<Option<()>>::VALUE) } fn main() { assert!(check_variant_count::<()>()); } </ins>

Discussion:
For example: Similar to , but with a different intrinsic. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We can probably just put call in front of that if statement. A more precise way to implement this would be to exhaustively match on and forbid , , , , and here. This way we the intrinsic can still be evaluated for which is probably desirable.
claim
Hello, I'm interested in taking the desirable approach. How is the arm for variants like should be handled? Which macro is more appropriate for this situation?
I quickly grepped for and ended up with here. That only works once you know what to search for though.
Change:
ConstValue::Scalar(val) | ConstValue::ScalarPair(val, _) => val, }; if let Ok(ptr) = val.to_ptr() { <del> let is_array_ptr = const_val.ty .builtin_deref(true) .and_then(|t| t.ty.builtin_index()) .map_or(false, |t| t == tcx.types.u8); assert!(is_array_ptr); </del> tcx.alloc_map.lock().unwrap_memory(ptr.alloc_id).bytes.as_ref() } else { bug!("unexpected non-ptr ConstantValue")

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
job::setup(self); } <ins> // Download rustfmt early so that it can be used in rust-analyzer configs. let _ = &builder::Builder::new(&self).initial_rustfmt(); </ins> self.maybe_update_submodules(); if let Subcommand::Format { check, paths } = &self.config.cmd {

Discussion:
As of is not downloaded until the user runs . The rustc dev guide suggests setting the formatter to the rustfmt that is downloaded for stage0 in the build directory, but that is no longer downloaded with any other commands. (sorry for the delay in making this issue) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Hi have you had time to work on this? Let me know if anything is confusing and I'm happy to help out :)
Thank you!! Sorry for the delay in catching up. Am I correct that this Issue is about "at some point, make sure to automatically download rustfmt"? If so, I'm still not sure which file to fix. I think I somehow understood that this Issue is related to (i.e., no dependence on python scripts?)
That was the motivation for , right, we want to move all the logic out of the python script eventually. Not just at some point - it should be done on every invocation of bootstrap (assuming it hasn't been downloaded yet). Right now we only download it when someone runs x.py fmt. If you look at the PR I linked, it's currently in - I think moving it a line early to would be a good approach.
Is this picked up or shall i work on it?
no, is already working on it.
cool
Change:
= note: required because of the requirements on the impl of `CoerceUnsized<Box<dyn bar>>` for `Box<{integer}>` = note: required by cast to type `Box<dyn bar>` <del> error[E0283]: type annotations needed --> $DIR/test-2.rs:9:8 | LL |     10.dup::<i32>(); |        ^^^ cannot infer type for type `{integer}` | note: multiple `impl`s satisfying `{integer}: bar` found --> $DIR/test-2.rs:5:1 | LL | impl bar for i32 { fn dup(&self) -> i32 { *self } fn blah<X>(&self) {} } | ^^^^^^^^^^^^^^^^ LL | impl bar for u32 { fn dup(&self) -> u32 { *self } fn blah<X>(&self) {} } | ^^^^^^^^^^^^^^^^ error[E0283]: type annotations needed --> $DIR/test-2.rs:11:8 | LL |     10.blah::<i32, i32>(); |        ^^^^ cannot infer type for type `{integer}` | note: multiple `impl`s satisfying `{integer}: bar` found --> $DIR/test-2.rs:5:1 | LL | impl bar for i32 { fn dup(&self) -> i32 { *self } fn blah<X>(&self) {} } | ^^^^^^^^^^^^^^^^ LL | impl bar for u32 { fn dup(&self) -> u32 { *self } fn blah<X>(&self) {} } | ^^^^^^^^^^^^^^^^ error: aborting due to 7 previous errors </del> <ins> error: aborting due to 5 previous errors </ins> <del> Some errors have detailed explanations: E0038, E0107, E0283. </del> <ins> Some errors have detailed explanations: E0038, E0107. </ins> For more information about an error, try `rustc --explain E0038`.

Discussion:
When I run this code (via ): I get the output I expected (i.e., a single line of output that says "My number is 42"). However, if I run this code (via the same with no other changes): I get two compiler errors. The first error indicates that is not in scope - this makes sense, I have not defined anywhere. However, the second error indicates (provided below) does not make sense: It appears that, when there are no other compiler issues, the compiler can infer a type for just fine. However, as soon as any other compiler issue appears, it loses the ability to infer type. That doesn't make sense to me - the ability to infer type should be unrelated to any other compiler errors present. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I partially fixed this for and in , but not in general. I am dissatisfied with this error message. I'll look into fixing it. claim
Change:
|              ^^^^ `{float}` is not an iterator | = help: the trait `Iterator` is not implemented for `{float}` <ins> = note: if you want to iterate between `start` until a value `end`, use the exclusive range syntax `start..end` or the inclusive range syntax `start..=end` </ins> = note: required for `{float}` to implement `IntoIterator` error: aborting due to 12 previous errors

Discussion:
rust version: Do you think it would be useful to add a hint here? Something in the lines of <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
i was hoping this to be my first PR to the compiler, if accepted as necessary. :D I need some guidance as to where this code might be though...
claim
hups sorry
I was testing the bot feature
The 'is not an iterator' message comes from the attribute. One solution would be to add a new case to that attribute which detects literals of the form (where both sides are numeric) and suggests the iterator syntax.
thanks!
is this in the right direction?