jiebi/CodeConvo huggingface dataset:
Change:
self.check_repeat_element_needs_copy_bound(element, count, element_ty); <del> self.register_wf_obligation( Ty::new_array_with_const_len(tcx, t, count).into(), expr.span, traits::WellFormed(None), ); </del> <ins> let ty = Ty::new_array_with_const_len(tcx, t, count); self.register_wf_obligation(ty.into(), expr.span, traits::WellFormed(None)); </ins> <del> Ty::new_array_with_const_len(tcx, t, count) </del> <ins> ty </ins> } fn check_repeat_element_needs_copy_bound(

Discussion:
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
Regression in nightly-2023-06-02 Regression in cc
Change:
<ins> // compile-flags: -Zsave-analysis #![feature(type_alias_impl_trait)] trait Trait {} trait Service { type Future: Trait; } struct Struct; impl Service for Struct { type Future = impl Trait; //~ ERROR: could not find defining uses } fn main() {} </ins>

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
<ins> // aux-build:issue-91763-aux.rs #![deny(elided_lifetimes_in_paths)] extern crate issue_91763_aux; #[issue_91763_aux::repro] fn f() -> Ptr<Thing>; //~^ ERROR hidden lifetime parameters in types are deprecated fn main() {} </ins>

Discussion:
<details<summary<strongBacktrace</strong</summary<p</p</details
This bisects to &mdash; regressed nightly: nightly-2021-12-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There was an issue with similar ICE that has been fixed recently Does this problem still repro with latest nightly ?
Yes this one still reproduces as of that nightly, which contains .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Change:
_ => { // For all other pointee types we should already have returned None // at the beginning of the function. <del> panic!("fat_pointer_kind() - Encountered unexpected `pointee_ty`: {:?}", pointee_ty) </del> <ins> panic!( "fat_pointer_kind() - Encountered unexpected `pointee_tail_ty`: {:?}", pointee_tail_ty ) </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. --glacier <!-- 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. --: Note: you need a build with rustc debug assertions enabled! <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<del> Subproject commit e3cfb61ece273d59b62fb959ed17c99c04941d82 </del> <ins> Subproject commit ded5a52639a78907523b74a9d3ed8e3824c88ca5 </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! cc the PR reviewer, and nominating for compiler team prioritization.
Triage meeting: Tagged as P-medium, appears to have PR.
Change:
bad: data[7..=6]; message: "out of range"; } <ins> in mod boundpair_len { data: [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(6), Bound::Unbounded)] == []; good: data[(Bound::Unbounded, Bound::Included(5))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Unbounded, Bound::Excluded(6))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(0), Bound::Included(5))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(0), Bound::Excluded(6))] == [0, 1, 2, 3, 4, 5]; good: data[(Bound::Included(2), Bound::Excluded(4))] == [2, 3]; good: data[(Bound::Excluded(1), Bound::Included(4))] == [2, 3, 4]; good: data[(Bound::Excluded(5), Bound::Excluded(6))] == []; good: data[(Bound::Included(6), Bound::Excluded(6))] == []; good: data[(Bound::Excluded(5), Bound::Included(5))] == []; good: data[(Bound::Included(6), Bound::Included(5))] == []; bad: data[(Bound::Unbounded, Bound::Included(6))]; message: "out of range"; } </ins> } panic_cases! {

Discussion:
These feel like an omission to me, given how is implemented for this type: And if we really want to go for feature parity, then also has impls for , but I think that's mostly for the sake of methods like , and it really doesn't make sense here. Edit: Then again, considering that RangeArgument is going to have methods that return , maybe is worth it. (secretly, I just want the standard library to implement my bounds-checking and length-computation for me in my n-dimensional array, so that I can just write and trust that it's correct. But shhhhhh, don't tell anyone)
On second thought, after seeing how meager libcore's test suite is for the existing indexing operations, I have decided that I should stop trusting the standard library and start contributing to it myself. Working on a PR. Edit: awww, looks like there's actually a good reason why there's no tests with or . (the first takes forever on debug, the second sets forth The End of All Times) Edit 2: How on earth does not appear a single time in the tests for slice or str!?!
do you still have plans to make a PR for this feature?
Nope, totally forgot about this! Feel free to take the reins. (looking back, it seems I went ahead with the test suite PR (), but that took long enough to merge that by the time it was done I must have moved on to other things.)
Change:
<ins> error[E0308]: mismatched types --> $DIR/restrict-assoc-type-of-generic-bound.rs:9:12 | LL | pub fn foo<A: MyTrait, B>(a: A) -> B { |                        -           - expected `B` because of return type |                        | |                        expected this type parameter LL |     return a.bar(); |            ^^^^^^^ expected type parameter `B`, found associated type | = note: expected type parameter `B` found associated type `<A as MyTrait>::T` help: consider further restricting this bound | LL | pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B { |                      +++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response
Change:
def downloading_llvm(self): opt = self.get_toml('download-ci-llvm', 'llvm') <ins> # This is currently all tier 1 targets (since others may not have CI # artifacts) # https://doc.rust-lang.org/rustc/platform-support.html#tier-1 supported_platforms = [ "aarch64-unknown-linux-gnu", "i686-pc-windows-gnu", "i686-pc-windows-msvc", "i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu", "x86_64-apple-darwin", "x86_64-pc-windows-gnu", "x86_64-pc-windows-msvc", ] </ins> return opt == "true"  <del> or (opt == "if-available" and self.build == "x86_64-unknown-linux-gnu") </del> <ins> or (opt == "if-available" and self.build in supported_platforms) </ins> def _download_stage0_helper(self, filename, pattern, tarball_suffix, date=None): if date is None:

Discussion:
From Switching to static linking would preclude any of the improvements from , so it would be better to use dynamic linking instead which would allow any contributor to get started without building LLVM from source or using system LLVM. That said, it sounds like dynamic linking will be very hard to do on other platforms. cc
Cc - do we know what the right way to bring the issues (bugs?) I found to LLVM developers? Are there active maintainers of LLVMs build system?
LLVM’s bugzilla is pretty much the only place for bug reports. If its something less defined than a precise bug report, talking it out on the mailing lists is the way to go.
In which way is static linking making downloaded LLVM impossible?
I don't think it's impossible to download/ship the statically linked LLVM, it's something I want to explore. That said, we want to move to dynamically linking LLVM because we ideally want to be applying ThinLTO to LLVM everywhere, not just on x86_64-unknown-linux-gnu, and since LTO happens at link-time, we want that to happen once, not on the multiple LLVM links occurring during CI.
Change:
<ins> trait A { const C: usize; fn f() -> ([u8; A::C], [u8; A::C]); //~^ ERROR: type annotations needed: cannot resolve //~| ERROR: type annotations needed: cannot resolve } fn main() {} </ins>

Discussion:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Running the following code triggers an internal compiler error and the error message says that it's a bug and I should report it, so I'm doing that now:
mcve:
Note, that this does not ICE anymore on nightly, instead it gives me: Can this be closed

I'm experimenting with a parser combinator and ran into an issue with closure lifetime inference. This might be a duplicate of , since it uses a similar (but simpler) mechanism to produce the same error message. However, in the code below the error is potentially a lot further away, and since I need to return values from the closure I'm having trouble finding any way to make it work by explicitly specifying a signature. Since it involves more moving parts, I'm also not sure how to confirm if the underlying issue is the same. I removed all parts that aren't involved in triggering the error message (the original use case has trait methods with related return types). It comes down to the following error message: And here is the triggering code:
After some experimentation, I tried a possible fix, which lead to an ICE. I changed to which gives me: My is: And here is the :
The ICE reduced:
Triage: still ICEs
Still ICEs:
The reduced example doesn't show the ICE, from 1.35.0 (tested on godbolt). Marked as E-needstest
And the original code is now accepted, so adding tests is enough to close this ticket.
Change:
assert_eq!(lexer.next_token().tok, token::Literal(token::Char(token::intern("a")), None)); } <ins> #[test] fn crlf_comments() { let sh = mk_sh(); let mut lexer = setup(&sh, "// testrn/// testrn".to_string()); let comment = lexer.next_token(); assert_eq!(comment.tok, token::Comment); assert_eq!(comment.sp, ::codemap::mk_sp(BytePos(0), BytePos(7))); assert_eq!(lexer.next_token().tok, token::Whitespace); assert_eq!(lexer.next_token().tok, token::DocComment(token::intern("/// test"))); } </ins> }

Discussion:
Image says it all really, running rustdoc on files with windows style line-endings inserts (or doesn't strip?) additional newline characters, screwing up alignment with the line numbers: ! This only seems to affect regular comments, doc comments are fine. Edit: since it's not really obvious from the image due to the nature of the bug, it should look like this:
Change:
/// This trait is meant to map equivalences between raw structs and their /// corresponding rust values. <del> pub trait Repr<T> { </del> <ins> pub unsafe trait Repr<T> { </ins> /// This function "unwraps" a rust value (without consuming it) into its raw /// struct representation. This can be used to read/write different values /// for the struct. This is a safe method because by default it does not

Discussion:
Here's the definition Implementing is done like so: A safe implementation invokes a transmute between arbitrary types. Perhaps is more appropriately an unsafe trait?
Agreed. Unsafe trait is the way to go.
Change:
<ins> error: any use of this value will cause an error --> $DIR/dangling_raw_ptr.rs:3:1 | LL | / const FOO: *const u32 = { //~ ERROR any use of this value will cause an error LL | |     let x = 42; LL | |     &x LL | | }; | |__^ type validation failed: encountered dangling pointer in final constant | = note: #[deny(const_err)] on by default error: aborting due to previous error </ins>

Discussion:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.
Change:
(sig, kind) } ty::TyInfer(ty::TyVar(vid)) => self.deduce_expectations_from_obligations(vid), <ins> ty::TyFnPtr(sig) => (Some(sig.skip_binder().clone()), Some(ty::ClosureKind::Fn)), </ins> _ => (None, None), } }

Discussion:
Type inference for the expected type of arguments doesn't work when coercing from a closure expression. For example, this code does not compile (at least, not without an explicit annotation):
Some brief mentoring instructions to fix this: The expected type for closure arguments are deduced using various bits of code in . In particular, the function examines the expected type (which will be in this case). Right now, it only works for trait objects like . It needs to be extended to also check for fn pointers (the variant). Please feel free to ping me on IRC or gitter with questions! (Or ask in #rustc)
I'd like to work on this issue
great! :) Let me know if my instructions suffice, or if you feel you need some more help. I do try to keep up with GH notifications, so you can ask questions here, but you'll definitely get a "snappier" response on IRC or gitter.
OK, so, reading a bit more into that code, I see that it's use of is a bit... icky (I can say that since I wrote it). But I'm just going to go with it. Here is a slightly more detailed account of what needs to be changed: In , when we match a , this variable will be a . This means that it's a function signature, i.e., has the types of arguments and return type. The "Poly" bit means that this function signature may have some higher-ranked regions (e.g., , which is really shorthand for -- the "poly" bit is talking about the ). In fact, if you trace it out, you will see that is really a type alias for , where basically corresponds to the . Now, this function is setup to return a . The "ickiness" I was referring at the beginning with respect to is that, although the first part of this tuple is just , it really should be , because this signature may still refer to bound regions. If you kind of trace it out, you'll see that we wind up adding a binder back on, but in a kind of far-apart part of the code. Sort of a mess, but let's ignore that. So, the meaning of this return: the first part of the tuple is expected fn signature. We basically want to supply the that we extracted from the , more on that in a second.

the second part is the "kind" of closure (by value, etc). This is irrelevant here, since it refers specifically to how the closure deals with its environment, and if we are coercing to a fn ptr, we know that there cannot be an environment. We could just return ; we could also yield , since any valid instance will satisfy the trait (which is the most general trait -- a fn that can be called through a shared reference). Therefore, I think we want to return something like .
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. // aux-build:xcrate-reachable.rs #![feature(conservative_impl_trait, generator_trait)] extern crate xcrate_reachable as foo; use std::ops::Generator; fn main() { foo::foo().resume(); } </ins>

Discussion:
I've hit an ICE with the new generator support that has just landed (nightly 2017-08-29). I've reduced it to the following : This is essentially the same issue as . I can't reproduce the original ICE with closures as described there, but I run into it with generators.
I believe this ICE is more related to "impl Trait" rather than generators, but we'll find out!
I think also needs to be adapted for generators.
looks like ! Thanks for the pointer!
Change:
// Rename directory, so that root folder of tarball has the correct name t!(fs::rename(&dst_src, &plain_dst_src)); <ins> // Create the version file write_file(&plain_dst_src.join("version"), build.version.as_bytes()); </ins> // Create plain source tarball let mut cmd = Command::new("tar"); cmd.arg("-czf").arg(sanitize_sh(&distdir(build).join(&format!("{}.tar.gz", plain_name))))

Discussion:
Can we include the output of into the source archives? It can be important for beta and nightly. Ideally the download page should also display them.
This should be a pretty easy bug to tackle for anyone aspiring to do so. Let's just create a file called in our tarballs with basically the output of
This will require editing the makefiles in as well as the rustbuild build system in . The version info is in . I realized that the installers already include this info in a file called 'version', so we can just duplicate that logic. Use the same lower case naming for consistency.
Change:
// fn try_identity(_1: std::result::Result<u32, i32>) -> std::result::Result<u32, i32> { //     debug x => _1; //     let mut _0: std::result::Result<u32, i32>; <del> //     let mut _2: isize; //     let _3: i32; //     let _4: u32; </del> <ins> //     let _2: i32; //     let _3: u32; </ins> //     scope 1 { <del> //         debug y => _4; </del> <ins> //         debug y => _3; </ins> //     } //     scope 2 { <del> //         debug err => _3; </del> <ins> //         debug err => _2; </ins> //         scope 3 { //             scope 7 { <del> //                 debug t => _3; </del> <ins> //                 debug t => _2; </ins> //             } //             scope 8 { <del> //                 debug v => _3; </del> <ins> //                 debug v => _2; </ins> //             } //         } //     } //     scope 4 { <del> //         debug val => _4; </del> <ins> //         debug val => _3; </ins> //         scope 5 { //         } //     }

Discussion:
The doesn't have any effect. (Labeling because this prevents codegen of the like . Which may result in a few extra instructions being emitted to move registers and jump to the return block for cg_clif.) modify labels: +A-mir +A-mir-opt +A-cranelift
We already have a pass that propagates the terminator, it should be possible to make it handle as well. (however can leave sideeffects visible to the caller, so maybe this should be a proper dead code elimination pass instead)
For background, this is a side-effect of (see the MIR diagram in the PR summary) and . The MIR for the above example used to contain a frivolous open drop of . After my changes to drop elaboration, all branches of the open drop become no-op s, which are then removed by the pass. The read of the discriminant as part of the open drop remains, however. To my knowledge, we don't have a dead-code elimination pass for the MIR, which would be the proper way to handle this.
Change:
/// If code is not 0 (successful exit status), exit status is 101 (rust's default error code.) /// If the test is running and code is an error code, it will cause a panic. fn detail_exit(code: i32) -> ! { <del> // Successful exit if code == 0 { std::process::exit(0); } if cfg!(test) { </del> <ins> // if in test and code is an error code, panic with staus code provided if cfg!(test) && code != 0 { </ins> panic!("status code: {}", code); } else { <del> std::panic::resume_unwind(Box::new(code)); </del> <ins> //otherwise,exit with provided status code std::process::exit(code); </ins> } }

Discussion:
I ran and got this panic, although the rustfmt output had already been printed: Notably after running , the panic stops (and doesn't panic either). But reintroducing something where rustfmt will suggest changes brings the panic in back. See previous discussion at . cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is a regression from only exits the process when run from the main thread.
The fix is to use instead.
claim
So, to be clear, the fix is to replace the detail::exit with process::exit right?
no - within detailexit, change resumeunwind to process::exit