jiebi/CodeConvo huggingface dataset:
Change:
get_future_output(obligation.predicate, obligation.cause.span) })? } <ins> ty::Alias(ty::Projection, _) => { return Some(Ty::new_error_with_message( self.tcx, closure_span, "this projection should have been projected to an opaque type", )); } </ins> ty::Alias(ty::Opaque, ty::AliasTy { def_id, args, .. }) => self .tcx .explicit_item_bounds(def_id) .iter_instantiated_copied(self.tcx, args) .find_map(|(p, s)| get_future_output(p.as_predicate(), s))?, ty::Error(_) => return Some(ret_ty), <del> _ => span_bug!( closure_span, "async fn coroutine return type not an inference variable: {ret_ty}" ), </del> <ins> _ => { span_bug!(closure_span, "invalid async fn coroutine return type: {ret_ty:?}") } </ins> }; let output_ty = self.normalize(closure_span, output_ty);

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()', 'error: internal compiler error: async fn coroutine return type not an inference variable: impl Future<Output = &'b ()' 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 [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in module [analysis] running analysis passes on this crate --
Also ices in Rust 2021 in case anybody was wondering. Further reduced:
(see below)
It's of course :upsidedownface:
fyi
Change:
<ins> error: lifetime parameters must be declared prior to type parameters --> $DIR/issue-80512-param-reordering-with-defaults.rs:3:18 | LL | struct S<T = (), 'a>(&'a T); |         ---------^^- help: reorder the parameters: lifetimes, then types, then consts: `<'a, T = ()>` error: aborting due to previous error </ins>

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
&self, impl_candidates: Vec<ImplCandidate<'tcx>>, trait_ref: ty::PolyTraitRef<'tcx>, <ins> body_id: hir::HirId, </ins> err: &mut Diagnostic, ) -> bool;

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
|                      ^^^^^^^^^ | = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref <ins> = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior </ins> = note: the method `to_string` exists but the following trait bounds were not satisfied: `*const u8 : std::string::ToString`

Discussion:
With we are now suggesting people to use when they have a raw pointer and need a reference. With gets some expanded documentation on UB avoidance. It might be a good idea to mention that also in the actual suggestion, so people don't have to open the docs to be aware of this. Cc
Can I take this on, since no one seems to have done it yet?
Sure, it's yours!
Change:
use abi::Abi; use common::{NodeIdAndSpan, CrateContext, FunctionContext, Block, BlockAndBuilder}; use monomorphize::Instance; <ins> use rustc::infer::normalize_associated_type; </ins> use rustc::ty::{self, Ty}; use session::config::{self, FullDebugInfo, LimitedDebugInfo, NoDebugInfo}; use util::nodemap::{DefIdMap, NodeMap, FnvHashMap, FnvHashSet};

Discussion:
When trying to compile nphysics on a nightly created on or after , the compiler errors. Before this date it is fine. Example code: Presumably was that broke things, as it's a commit on that day that touches trans. On Windows 64 bit GNU this is the output:
cc
You sure it's that innocent commit and not, you know, my changes to debuginfo, for MIR? Specifically, is gone, that could cause problems.
I can't reproduce on master (just rebased one of my branches containing unrelated changes, so I had a compiler to check with). EDIT: Still no reproduction, even after .
Ok so I was misinterpreting which crate was being compiled. nphysics compiles fine, but , which uses nphysics, doesn't. I'm trying to narrow down the code now.
Here's some of the rust log that I got when compiling on debug builds:
That's not really helpful, sadly, nightly doesn't use yet, so there's no output.
This bug is not in beta, correct?
I'm afraid that I can't test that as I'm using s.
Can you check the test from instead? Particularly interested about the nightlies you had issues with.
Sure, unfortunately that test case works fine for both pre and post-.
Ah, beats me then.
I'll try and find which part of my code hits the error.
So I did some digging and I was wrong again, it turns out it is the nphysics crate. This is a minimal test case:
It depends on the crate, but it's not the crate itself, and that testcase is still large in terms of how much it needs to monomorphize.
True, sorry but I am not knowledgeable at all in rustc or nphysics, so it's the best I can do :/
triage: P-high
Still need a good regression test.
triage: P-low
I'm going to go ahead and close this. It's somewhat unlikely we'll hit this again (at least, we haven't obviously done so in the past 3ish years), and coming up with a good test case when the current case is all of nphysics is likely to be quite hard.
Change:
if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }

Discussion:
I have my master branch set up to track the master branch of my fork (mainly because i don't want to accidentally pull in every git tag into my shallow clone), so doesn't updated when i run (presumably the remote was created by ? i don't remember creating it, and lots of code needs it (or another branch pointing to this repo) to work). as it turns out, uses the state of to determine if a file has been modified. so instead of it formatting every file that i modified, it formats every file anyone has modified in the last few months. at no point did anything warn me that i need to be updating a remote i didn't add. it should probably do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this could be addressed by checking the timestamp on .git/refs/remotes/upstream/master and warning if it is very old
claim
I ran into a similar issue where was building llvm from source instead of using the prebuilt ci version due to an outdated branch. Would it make sense to solve both issues in one go?
should be pretty easy, just call the same warning method for both build steps maybe it should be used for all build steps?
Change:
if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }

Discussion:
I am getting this on each invocation now, since very recently: This is in my main checkout, not in a worktree, so I am not quite sure what could even be so unusual about my setup that causes an error here. Cc
A bisect points at That's I am surprised about the date of this PR, I think I would have noticed this earlier if this happened for a month... so probably some other factor is also involved. Cc
It seems to try to read which indeed is not a file that exists here. I also noticed this line in So maybe checking these files is just futile since git doesn't always use a file to track these refs?
I think what happened is that has been run, and that indeed cleans up most of the files from . So the current approach in bootstrap of looking at these files is not reliable. IMO we should instead look at the commit date of the most recent commit in that branch. That also avoids having to directly mess with git's internal files.
yeah, i'm gonna accept defeat on this one. is kinda slow on my device, but only if the relevant files aren't in the i/o cache, and building rust takes a good while anyways.
is not the case anymore since . I am planning to revert and as they are not really required.
Seems like it will still be the case if upstream was configured and too old. But that could be fixed in a much better way (e.g., we could ignore upstream commit and use merge commit in current branch) compare to and
Change:
if !verify_rustfmt_version(build) { return Ok(None); } get_git_modified_files(&build.config.git_config(), Some(&build.config.src), &["rs"]) }

Discussion:
I am in this state (only 1 modified file): But I just tried to format and got this: Something is quite wrong here. Formatting of only changed files must be correct, otherwise some files in the tree will get spurious formatting changes in PRs. Perhaps is related? I have a vague memory of seeing this misbehavior occasionally in the past though I'm only now remembering to file an issue.
Don't we check formatting of all files in CI anyway?
Most likely. On CI, yes.
Interesting. I swear I've seen spurious formatting changes in PRs. Might be some other effect.
Should be closed by (GH didn't pick up the comment)
Change:
<ins> // Copyright 2015 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:issue24687_lib.rs extern crate issue24687_lib as d; fn main() { // Create a d, which has a destructor whose body will be trans'ed // into the generated code here, and thus the local debuginfo will // need references into the original source locations from // `importer` above. let _d = d::D("Hi"); } </ins>

Discussion:
I’m getting an ICE when compiling using
I was able to trace down the bug. It is due to me using a unicode character in the documentation of a function this somehow triggers the compiler bug. A minimal example is:
I believe Servo is also currently hitting this in the script crate during our current rust upgrade.
Yes, at least the failing assertion is the same. Removing non-ASCII characters from doc comments didn’t seem to help, though.
cc might this be another overflow error?
recommended on IRC to build with , but log output seems to be disabled in Nightly. So I built Rust with debugging enabled and tried again. (This took forever because of .) There was a lot of output, here is just the end of it:
This is lines / 299MB of output.
my current hypothesis is that this is the problem; it is at the very least very suspicious considering that five lines up in the previous statement we are normalizing the position to zero by subtracting the , not adding it.
(other good news: I have figured out how to make a regression test for this that will integrate into the rust test suite.)
Change:
| = note: `issue_56125` could refer to an extern crate passed with `--extern` = help: use `::issue_56125` to refer to this extern crate unambiguously <del> note: `issue_56125` could also refer to the unresolved item imported here --> $DIR/issue-56125.rs:19:9 </del> <ins> note: `issue_56125` could also refer to the module imported here --> $DIR/issue-56125.rs:20:9 </ins> | <del> LL |     use empty::issue_56125; //~ ERROR unresolved import `empty::issue_56125` |         ^^^^^^^^^^^^^^^^^^ = help: use `self::issue_56125` to refer to this unresolved item unambiguously </del> <ins> LL |     use issue_56125::*; //~ ERROR `issue_56125` is ambiguous |         ^^^^^^^^^^^^^^ = help: use `self::issue_56125` to refer to this module unambiguously </ins> error: aborting due to 4 previous errors

Discussion:
the code i tried: noticed there was a typo, fixed it, still getting an ICE i expected: cargo-generate/pull/135, to not compile and give an error about typo cargo-generate/pull/136, to compile (and no longer display 2018 warnings about path clarity) instead, what happened: system info:
i also get this on stable and earlier nightlies, if that is at all useful.
(also please feel free to let me know if i can provide any more info- this is my first time filing a compiler bug! thanks for all your hardwork and help <3)
Nominating -- we should keep focus on Rust 2018-related bugs like this, I think.
Did you? I mean, there is a typo, right? Do you mean, you expected a controller error? Specifically I see this in the diff: and I think it should be ?
I guess you are saying you get the same ICE from , which has a fix... did you try a cargo clean? (I'm wondering if it is related to incremental compilation.)
yeah, so i noticed the typo, and then fixed it (hence the 2 PRs- i included both on the offchance that there were 2 issues.) i expected the 2nd one to compile, and the first one (after i noticed the typo, to not compile but give an error re: the typo). i will run a cargo clean and see if it helps!
OK, thanks for the clarification.
just ran and then and have the same error message.
Fixed in
Change:
// Allow these methods to be used without import: #[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> pub impl<T:Owned,U:Owned> DuplexStream<T, U> { fn send(&self, x: T) { self.chan.send(x)

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "9f200f5b12eb75f8c1ed65abd4b2db8a6e1b138a20de009dacee265a2498f3f6" dependencies = [ <del> "libc 0.2.112", </del> <ins> "libc", </ins> ] [[package]]

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
} fn update_pass_mode(&mut self, ln: &str, revision: Option<&str>, config: &Config) { <del> let check_no_run = |s| { if config.mode != Mode::Ui && config.mode != Mode::Incremental { panic!("`{}` header is only supported in UI and incremental tests", s); } if config.mode == Mode::Incremental && !revision.map_or(false, |r| r.starts_with("cfail")) && !self.revisions.iter().all(|r| r.starts_with("cfail")) { panic!("`{}` header is only supported in `cfail` incremental tests", s); </del> <ins> let check_no_run = |s| match (config.mode, s) { (Mode::Ui, _) => (), (Mode::Codegen, "build-pass") => (), (Mode::Incremental, _) => { if revision.is_some() && !self.revisions.iter().all(|r| r.starts_with("cfail")) { panic!("`{s}` header is only supported in `cfail` incremental tests") } </ins> } <ins> (mode, _) => panic!("`{s}` header is not supported in `{mode}` tests"), </ins> }; let pass_mode = if config.parse_name_directive(ln, "check-pass") { check_no_run("check-pass");

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: code originally 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. --: When compile with , there is a which does not occur with `
Due to inlining of :
does the no_mangle attr have done kind of effect? can't check on mobile right now
I think it's more likely the struct's being ignored when performing that field access. cc
A slightly simplified example: It only arises when inlining a generic function (in this case ) that bitcasts a .
The difference seems to be that bitcasts a pointer to a vector, while the inlined bitcasts a vector directly. I suspect that the extra move that happens when is inlined causes vector value to be stored behind a pointer. I can reproduce the crash using just to force an extra move. As for why puts the vector behind a pointer, the default rust abi passes vector types by-ref to ensure that changing target features doesn't change the abi.
With that crashes at and without it gives the following LLVM ir:
It's interesting that the failure (in my example) required to be generic—that shouldn't affect the ABI of the monomorphized function, should it?
Indeed. It shouldn't affect the ABI.
The original no longer crashes since , but still does
Triage: The above mentioned example now compiles fine with the latest nightly, I guess is related. Marking as .
Change:
// Check if this is a binding pattern, if so, we can optimize and avoid adding a // `let <pat> = __argN;` statement. In this case, we do not rename the parameter. let (ident, is_simple_parameter) = match parameter.pat.kind { <del> hir::PatKind::Binding(hir::BindingAnnotation::Unannotated, _, ident, _) => { (ident, true) </del> <ins> hir::PatKind::Binding( hir::BindingAnnotation::Unannotated | hir::BindingAnnotation::Mutable, _, ident, _, ) => (ident, true), // For `ref mut` or wildcard arguments, we can't reuse the binding, but // we can keep the same name for the parameter. // This lets rustdoc render it correctly in documentation. hir::PatKind::Binding(_, _, ident, _) => (ident, false), hir::PatKind::Wild => { (Ident::with_dummy_span(rustc_span::symbol::kw::Underscore), false) </ins> } _ => { // Replace the ident for bindings that aren't simple.

Discussion:
<img width="1016" alt="rustdoc output screenshot" src="https://user-"This example was tested on Rust 1.46.0, but it has been broken for quite a while. For example, see ).
Relevant code: Not sure what's going wrong.
Thanks for the helpful hint, However, I'm not convinced this is the root cause because it's happening to all mutable by-value function arguments, not just to functions with as the first argument. For example, this free function emits similar results: <img width="1004" alt="Screen Shot 2020-09-15 at 9 56 26 AM" src="https://user-"I think the actual root cause may be deeper than the interpretation of types, but I can't tell for sure.
This example confirms that the behavior appears to be per-argument instead of per-function. It's not like one bad argument ruins the formatting of the entire function. <img width="983" alt="Screen Shot 2020-09-15 at 10 04 39 AM" src="https://user-"Perhaps we could investigate where in the code the text is being generated and work our way backwards to see what is triggering it?
Hmm, the only relevant location I could find through GitHub search is in in : Is operating on a desugared form of the AST? I don't think this is the case, since is being successfully displayed here. Is there something else I'm missing?
Here's the issue: Looks like it should use  instead. Are you interested in making a PR? ;)
Yes, rustdoc works on a desugared version and has to reconstruct the by hand.
Sure, I will prepare one right away. Thanks for investigating with me.
Change:
#![feature(closure_to_fn_coercion)] fn main() { <del> let bar: fn(&mut u32) = |_| {}; //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter </del> <ins> let bar: fn(&mut u32) = |_| {}; </ins> fn foo(x: Box<Fn(&i32)>) {} let bar = Box::new(|x: &i32| {}) as Box<Fn(_)>;

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 .