jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir_analysis::autoderef::{self, Autoderef}; use rustc_infer::infer::canonical::OriginalQueryValues; use rustc_infer::infer::canonical::{Canonical, QueryResponse}; <ins> use rustc_infer::infer::error_reporting::TypeAnnotationNeeded::E0282; </ins> use rustc_infer::infer::DefineOpaqueTypes; use rustc_infer::infer::{self, InferOk, TyCtxtInferExt}; use rustc_middle::middle::stability;

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. --It seems this is a particularly tricky interaction of , coercion and these two ; take away any one, and the compiler spits out a type annotation error as seen below. The compiler is also happy if is annotated as but I don't quite understand why this needs to be specified, given the inner casts on both branches. <!-- 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
reduced a bit
Regression in nightly-2020-06-24
This is minimized in the sense that spurious errors are avoided: The problem here is that the autoderef of a method is interacting strangely with the obligation registered by the line. This actually guides inference in such a way that an assertion in the compiler is not upheld -- that assertion is kinda nonsense though, so I'm just gonna rework it.
I've tried bisecting to a narrower point but didn't get far: commit[0] 2020-06-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[1] 2020-06-22: Auto merge of - Aaron1011:revert/move-fn-self-msg, r=Manishearth commit[2] 2020-06-23: Auto merge of - yoshuawuyts:socketaddr-from-string-u16, r=sfackler commit[3] 2020-06-23: Auto merge of - Dylan-DPC:rollup-b4wbp42, r=Dylan-DPC commit[4] 2020-06-23: Auto merge of - Manishearth:rollup-68dr8fz, r=Manishearth commit[5] 2020-06-23: Auto merge of - ollie27:rustdocaliasfilter, r=GuillaumeGomez So I guess one , or WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
<ins> // run-rustfix // Check that we try to correct `=>` to `>=` in conditions. #![allow(unused)] fn main() { let a = 0; let b = 1; if a => b {} //~ERROR } fn foo() { let a = 0; if a => 1 {} //~ERROR } fn a() { let a = 0; if 1 => a {} //~ERROR } fn bar() { let a = 0; let b = 1; if a => b && a != b {} //~ERROR } fn qux() { let a = 0; let b = 1; if a != b && a => b {} //~ERROR } fn baz() { let a = 0; let b = 1; let _ = a => b; //~ERROR } fn b() { let a = 0; let b = 1; match a => b { //~ERROR _ => todo!(), } } </ins>

Discussion:
When encountering code like , we currently emit But it should be closer to <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hi! I'd like to try working on this issue if nobody else is currently. claim
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-66906.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </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 was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.
Change:
<ins> <footer><p> Copyright &copy; 2011-2014 The Rust Project Developers. Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a> or the <a href="http://opensource.org/licenses/MIT">MIT license</a>, at your option. </p><p> This file may not be copied, modified, or distributed except according to those terms. </p></footer> </ins>

Discussion:
Per we should have the docs licensed correctly. Nominating.
I can have a look at this.
Change:
// Tell the compiler to link to either panic_abort or panic_unwind #![needs_panic_runtime] <del> // Always use alloc_system during stage0 since jemalloc might be unavailable or // disabled (Issue #30592) #![cfg_attr(stage0, feature(alloc_system))] </del> <ins> // Always use alloc_system during stage0 since we don't know if the alloc_* // crate the stage0 compiler will pick by default is available (most // obviously, if the user has disabled jemalloc in `./configure`). #![cfg_attr(any(stage0, feature = "force_alloc_system"), feature(alloc_system))] </ins> // Turn warnings into errors, but only after stage0, where it can be useful for // code to emit warnings during language transitions

Discussion:
Edit: see Seems to get past there fine if I remove .
Ok, works. That's the version rustbuild will download if left to its own devices. Bisecting built nightlies as my local rust gives this: nightly-2016-12-19 () - works [no nightlies] nightly-2016-12-29 - unrelated errors on some i128/u128 stuff before it gets to the relevant point [no nightlies] nightly-2017-01-04 () - broken
Note that this is really quick to reproduce (~1min), as it happens on the initial build of stage0 std. Here's the full log from : This issue may get a lot more attention once the stage0 downloaded compiler has its version bumped, as I suspect will be totally broken. Applying seems to fix it.
Ah I see, the more recent compiler is being detected as a local rebuild compiler, so rustbuild assumes it has a compiler with stage1 features and therefore performs a stage1 build, which seems to assume that jemalloc is available. On a positive note, this should never affect someone not using .
Ok I have a more solid understanding of the issue. Currently, a stage0-out libstd will never link against jemalloc. stage1-out is left to its own devices, linking against the default allocator for the compiler that's just been created (stage0-out) which is , system otherwise. However, a local rebuild uses for building the stage0 libstd, which means it uses the default allocator for the local rust. This tends to be we've disabled jemalloc, so it hasn't been built! Something along the lines of seems like the right approach, but I think some elaboration around the logic in this area is necessary in comments or something.
Change:
use rustc_middle::mir::visit::{MutVisitor, MutatingUseContext, PlaceContext, Visitor}; use rustc_middle::mir::*; use rustc_middle::ty::TyCtxt; <ins> use smallvec::SmallVec; </ins> use std::borrow::Cow; pub struct SimplifyCfg {

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. --(also reproduced in beta and nightly) <!-- 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<pNo backtrace generated </p</details
This is already fixed on nightly, I just tried it locally. Can you confirm?
Installed nightly last night but to double check:
Hmm... must be apple specific. Do you have a gdb handy that you could run on that last rustc invocation to obtain a stack trace?
Having problems getting it working, not normally a debugger person (been years since I've run gdb) and not much of a Mac person (work computer). I installed for nightly and I get Then when I run, I get
hmm... not sure what our gdb capabilities on mac are. I'll try to find someone who's building rustc on macs. Thanks for the attempt!
I'm looking into producing a build locally.
backtrace:
Looks like my CI saw a stack overflow on Windows as well
lol I recently (two days ago) looked at and went "oh this could stack overflow, why is this not a loop". I'll (try to) fix this without inserting more stacker invocations
Change:
// Because searching is incremental by character, only the most // recent search query is added to the browser history. if (browserSupportsHistoryApi()) { <ins> var newURL = getNakedUrl() + "?search=" + encodeURIComponent(query.raw) + window.location.hash; </ins> if (!history.state && !params.search) { <del> history.pushState(query, "", "?search=" + encodeURIComponent(query.raw)); </del> <ins> history.pushState(query, "", newURL); </ins> } else { <del> history.replaceState(query, "", "?search=" + encodeURIComponent(query.raw)); </del> <ins> history.replaceState(query, "", newURL); </ins> } }

Discussion:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Change:
P, Q, R(u32), <del> S { d1: u32, d2: u32 }, </del> <ins> S { d1: Option<u32>, d2: Option<i32> }, </ins> } // An enum with no fieldless variants. Note that `Default` cannot be derived

Discussion:
I tried this code: I expected to see this happen: code fails to compile. Instead, this happened: code compiles, and assertion fails. Changing order of enum variants to make go first fixes the issue: : It's reproducible in in Stable, Beta and Nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I have played around a bit with the example and got to compile an even bigger class of bad programs: You can reproduce this in the . As you can see, the compiler is tricked into thinking that implements . This works with sum and product types, as long as: is the first field (or variant) and are "wrapped" with the same type, i.e , or . I have little experience with internals. Maybe someone more experienced could direct us to where this magic happens?
Expanding the macro yields a looks like it only asserts ness for the first field - whoops! claim
Gonna hand it over to you as discussed on zulip release
claim
On 1.63.0 this failed to compile, as expected (): label regression-from-stable-to-stable
this was recently introduced when was doing derive optimizations.
I'll take a look today, thanks for the report.
Don't worry, we've found the issue already, just wanted to let you know.
See for the fix.
WG-prioritization assigning priority a posteriori () mostly to help tracking the fix progress. label -I-prioritize +P-high
Change:
<ins> const A: [&str; 1] = { "hello" }; //~^ ERROR mismatched types const B: &[u32] = &{ 1 }; //~^ ERROR mismatched types const C: &&[u32; 1] = &&{ 1 }; //~^ ERROR mismatched types fn main() {} </ins>

Discussion:
, we should provide a structured suggestion as we already do when . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems easy enough, claim
Change:
packages: &[], features: None, manifest_path: None, <ins> filters: &[], </ins> }, Test { name: "ripgrep",

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
<ins> // Copyright 2013 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. // Test that shadowed lifetimes generate an error. struct Foo<T>; impl<T> Foo<T> { fn shadow_in_method<T>(&self) {} //~^ ERROR type parameter `T` shadows another type parameter fn not_shadow_in_item<U>(&self) { struct Bar<T, U>; // not a shadow, separate item fn foo<T, U>() {} // same } } trait<T> Bar<T> { fn shadow_in_required<T>(&self); //~^ ERROR type parameter `T` shadows another type parameter fn shadow_in_provided<T>(&self) {} //~^ ERROR type parameter `T` shadows another type parameter fn not_shadow_in_required<U>(&self); fn not_shadow_in_provided<U>(&self) {} } fn main() {} </ins>

Discussion:
cc
It seems like the second part of this (type parameter shadowing) is backwards incompatible, but AFAICT, isn't implemented yet.
I suggest we leave it and go straight for the lint (as we plan to do eventually with the lifetime version). Then no backwards compatibility issues. Also, since type shadowing is allowed in every other language it is going to really surprise people if it is forbidden in Rust. And, it is the shadowed lifetimes which were causing the motivating confusion.
just for future visitors, type parameter shadowing (like the example in the RFC) does, in fact, produce a clear compiler error. The comments above and lack of linked "type parameter shadowing" PRs might otherwise suggest that type parameter shadowing was left as a lint rather than a compiler error.
Change:
if let LinkerFlavor::Gcc = flavor { match ld_impl { LdImpl::Lld => { <del> let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let lld_path = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .find(|p| { p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }).exists() }) .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-B"); arg.push(lld_path); arg }); </del> <ins> if sess.target.lld_flavor == LldFlavor::Ld64 { let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let ld64_exe = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .map(|p| { p.join(if sess.host.is_like_windows { "ld64.exe" } else { "ld64" }) }) .find(|p| p.exists()) .unwrap_or_else(|| sess.fatal("rust-lld (as ld64) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-fuse-ld="); arg.push(ld64_exe); arg }); } else { let tools_path = sess.host_filesearch(PathKind::All).get_tools_search_paths(false); let lld_path = tools_path .into_iter() .map(|p| p.join("gcc-ld")) .find(|p| { p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }) .exists() }) .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found")); cmd.cmd().arg({ let mut arg = OsString::from("-B"); arg.push(lld_path); arg }); } </ins> } } } else {

Discussion:
has progressed to the point where there is now a flag for linux builds. On a lark, I tested what happens on macos. Surprisingly, it wasn't immediately rejected. Unsurprisingly, it exploded. I'm not 100% sure if macos and linux are similar enough environments that the same mechanism should just work, but I think it should? <details<summarybuild log </summary</details
Oh interesting, ok so with it's blowing up in build scripts, but it seems to build (something with no dependencies or build scripts) fine!
(I do not have a readily available linux env to test if this failure mode is uniquely macos or just the usual "build-scripts and plugins have weird interactions with compiler flags" problem)
Using gets farther on rust-minidump's , but still blows up at the final link: <details<summarybuild log </summary</details<details<summaryfailing cc invocation broken up into lines</summary</details
Maybe your lld is too old? I can build my workspace with:
There is one binary lld and various symbolic links with different names. You have to pass for OSX and for linux. You are probably passing the wrong flavour, i.e. gnu.
Change:
<ins> fn main() {} struct S0<T>(T); impl<T> S0<T> { const C: S0<u8> = Self(0); //~^ ERROR mismatched types //~| ERROR mismatched types fn foo() { Self(0); //~^ ERROR mismatched types } } // Testing normalization. trait Fun { type Out; } impl<T> Fun for S0<T> { type Out = Self; } trait Foo<T> { fn foo(); } impl<T> Foo<T> for <S0<T> as Fun>::Out { fn foo() { Self(0); //~ ERROR mismatched types } } struct S1<T, U>(T, U); impl<T> S1<T, u8> { const C: S1<u8, u8> = Self(0, 1); //~^ ERROR mismatched types //~| ERROR mismatched types } struct S2<T>(T); impl<T> S2<T> { fn map<U>(x: U) -> S2<U> { Self(x) //~^ ERROR mismatched types //~| ERROR mismatched types } } </ins>

Discussion:
Summary from : used as a tuple-struct constructor function should use the fully type-substituted form from the block, but does not. Thus, today this code is accepted, but it should not be. (Fixing this would be a breaking-change, so we should take care in how we deploy it.) Original bug report follows: <!-- 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: In nightly rustc, compiles while yields a type mismatch error:
The one is incorrect, has all its generic parameters substituted, i.e. it's / in both cases, type or constructor function.
To be 100% clear here: I believe what is saying is that the compiler has a bug, and that the bug is that the code should be treated as a short-hand for: and thus should be yielding the same error that one sees for the cases in the code from the description. However, the code is not yielding an error at all.
T-compiler triage: leaving nominated for T-lang. Tagging as P-high priority to resolve whether the semantics described by is indeed what we want, and if so, how to address deploying a breaking-change to fix it.
cc I thought we had fixed this bug in (and to be clear, it's clearly a bug (as noted by in ). It should not compile.
Just to simplify a bit (still passes but shouldn't):
Just checked on godbolt and it seems to compile in every stable release since it was stabilized (). I haven't looked into the code again, but I don't really understand how didn't cover this. Did we forget to add a test with errors, and only tried to prevent ICEs, or something?
Change:
} if v.iter().any(|i| i.inner_impl().trait_.is_some()) { <ins> if let Some(impl_) = v .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(cache) == cx.cache.deref_trait_did) { sidebar_deref_methods(cx, out, impl_, v); } </ins> let format_impls = |impls: Vec<&Impl>| { let mut links = FxHashSet::default();

Discussion:
Steps to reproduce: down the sidebar looking for "Methods from Deref&lt;...&gt;" Expected result: Methods from Deref section comes immediately after Methods. Actual result: Methods from Deref section comes below Trait Implementations, Auto Trait Implementations, and Blanket Implementations. Compare vs , which has the correct ordering.
Ah, looks like this was intentional in , after conversation in . Removing C-bug and regression-from-stable-to-beta. Keeping this open as a discussion issue: I think putting "Methods from Deref" further down than trait implementations is wrong for String, because so many of its important methods are on . I'd like to either reconsider or find some way to make this work nicely for String. Vec is probably in the same boat, with its .
I'd like to voice that I also think this is a kind of regression. 99% of the time I go to a type's page, I'm looking for methods, not traits; I've gotten used to seeing 's methods directly under s, and it feels like a mistake moving away from this.
what do you think of reverting while we look for a better solution. From : The problem with this is sometimes the "Methods from Deref" section refers to a type in the crate. Particularly for and , about half of the most useful methods are on and , respectively. Those are types that are a critical part of the new user learning path, and it's a good user experience for those to be right next to the other methods, both in the sidebar and in the doc. I suspect there are other ways to solve the need expressed in without affecting the page layout of Vec and String in this way.
that's fine - was a response to , which has since been reverted.
FWIW, I originally opened that issue with something more like a directly configurable way of specifying the page layout order for your own crate in mind. I still think that would ultimately be the best solution here. Unsure what the best approach would be, though, as far as top level attribute vs. command-line flag vs. any other way of doing it. Other stuff like what is and isn't "collapsed" by default should probably be configurable also, I'd say.