jiebi/CodeConvo huggingface dataset:
Change:
} fn doctraititem(w: &mut fmt::Formatter, cx: &Context, item: &clean::Item, <del> link: AssocItemLink, render_static: bool, </del> <ins> link: AssocItemLink, render_static: bool, is_default_item: bool, </ins> outer_version: Option<&str>) -> fmt::Result { let shortty = shortty(item); let name = item.name.as_ref().unwrap();

Discussion:
I use documentation on my trait impls to tell users about how my types behave: This documentation is not rendered anymore. I expect to see it under the entry for the implementation of the type. I think this was lost after (the otherwise very awesome!) documentation changes by
Note: Documentation on top of the item itself is properly rendered. If you too agree this is adequate, please close the issue again.
Just for reference: this also leaves the (perhaps not entirely obvious) operator impls on HashSets undocumented. Also see on this issue.
Yes, is dup of this. It is hiding stable parts of std from me:
Change:
<ins> // In this regression test we check that a path pattern referring to a unit variant // through a type alias is successful in inferring the generic argument. // compile-pass #![feature(type_alias_enum_variants)] enum Opt<T> { N, S(T), } type OptAlias<T> = Opt<T>; fn f1(x: OptAlias<u8>) { match x { OptAlias::N // We previously failed to infer `T` to `u8`. => (), _ => (), } match x { < OptAlias<_> // And we failed to infer this type also. >::N => (), _ => (), } } fn main() {} </ins>

Discussion:
The following, which I expect to work, fails to infer the type of : In HIR, should correspond to: However, if we change the snippet to: it all works out fine. I also tested changing to a tuple variant and that works also. cc cc
It might be a good idea to trace the difference between and because they look relatively similar and yet they behave differently in terms of inference.
Value (/) and type () namespaces execute very different logic for type inference (/ vs ). It's quite possible that there are intended and unintended observable differences (not necessarily specific to ). checkpatpath and checkpattuplestruct Rather and . ( is the same "value" case as .)
Change:
<ins> // Check that `-Zmir-enable-passes=+Inline` does not ICE because of stolen MIR. // unit-test: Inline // skip-filecheck #![crate_type = "lib"] // Randomize `def_path_hash` by defining them under a module with different names macro_rules! emit { ($($m:ident)*) => {$( pub mod $m { pub fn main() { let func = || 123u8; func(); } } )*}; } // Increase the chance of triggering the bug emit!(m00 m01 m02 m03 m04 m05 m06 m07 m08 m09 m10 m11 m12 m13 m14 m15 m16 m17 m18 m19); </ins>

Discussion:
While trying to build a test for , I renamed my test file and it stopped ICEing. I have no idea what's happening here. Create a file with this contents called Then This compiles fine: But this ICEs:
We skip calling by comparing def-path hashes. The def-path hash provides a total order on MIR bodies that respects incremental compilation, and avoids a potentially costly query. OTOH, it depends on the crate name, which is the file name in your example. If you add a somewhere, that should be reproducible.
Setting the crate name would stabilize this for now, but any change to the hash algorithm could cause this test to suddenly pass, even if the compiler regresses in its behavior. Is there a way around that problem?
As someone who has changed the hash algorithm before, a comment in the file that says you might have to fiddle with the crate name to find something where that check works (including a link to this issue) might be enough if there's no other option.
I'm not concerned about the test suddenly failing, I'm concerned about it suddenly passing when it shouldn't.
I can't reproduce the MCVE in your opening comment. However, if I rename the file to then it emits an ICE (which I suspect is the same you reported here, is it? <details</detailsTo summarize: :heavycheckmark: :heavycheckmark: :skull: I'm really puzzled. Any idea? :thinking: EDIT: worth mentioning I'm on the latest nightly:
For testing purposes? Repeat the test a number of times to ensure that it is unlikely that it will pass by an accident.
Yes, that is the ICE in question, and your difficulty in reproducing this underscores the problem here. Any ICE that relies on MIR inlining within a crate (as opposed to inlining a function from another crate) may stop reproducing basically at any time. I believe this is the same reason that bisects to unrelated commits.
Change:
fn binding_description(&self, b: &NameBinding<'_>, ident: Ident, from_prelude: bool) -> String { let res = b.res(); <del> if b.span.is_dummy() { </del> <ins> if b.span.is_dummy() || self.session.source_map().span_to_snippet(b.span).is_err() { </ins> // These already contain the "built-in" prefix or look bad with it. let add_built_in = !matches!(b.res(), Res::NonMacroAttr(..) | Res::PrimTy(..) | Res::ToolMod);

Discussion:
This code on the playground produces the following error Note how the 2nd note is dangling: no span is shown after it says 'could also refer to the enum defined here'. I was not able to reproduce this locally, so this might also have to do with something special the playground is doing -- Cc
I’d guess it has something to do with the number of crates and their types available by default. For example, just typing by itself says:
I think the standard library is not always distributed with sources, which sometimes causes weird diagnostics. That could be what's happening here.
Yes, the playground , which doesn't include the component. As an example:
Change:
<ins> // issue #101376 use std::ops::AddAssign; struct Foo; impl AddAssign<()> for Foo { fn add_assign(&mut self, _: ()) {} } impl AddAssign<()> for &mut Foo { fn add_assign(&mut self, _: ()) {} } fn main() { (&mut Foo) += (); //~^ ERROR invalid left-hand side of assignment //~| NOTE cannot assign to this expression //~| HELP consider dereferencing the left-hand side of this operation } </ins>

Discussion:
: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(update, I've reproduced it on smaller example)
Error -ICE regression in 1.63 label regression-from-stable-to-stable
searched nightlies: from nightly-2022-05-01 to nightly-2022-07-01 regressed nightly: nightly-2022-05-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegresses in rollup , most likely , cc
claim
Change:
<ins> // test that "error: arguments for inline assembly must be copyable" doesn't show up in this code // needs-asm-support // only-x86_64 fn main() { let peb: *const PEB; //~ ERROR cannot find type `PEB` in this scope [E0412] unsafe { std::arch::asm!("mov {0}, fs:[0x30]", out(reg) peb); } } </ins>

Discussion:
No response No response Happens on , as well as several earlier versions. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Just needs someone to this error if the type , I think.
assign
Error: Parsing assign command in failed: ...' assign' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
claim
Hi! I have given a brief introduction of myself in the . With that said, I have potentially setup the necessary pre-requisites and compiler infrastructure in my local machine, also re confirmed by using the and other build commands which seem to work. As per the , I have the all the toolchains command executed (for [0-2]). Like any other contribution, I figured that in repo, are tagged as for new-comers, and to start, I have chosen this issue. Until now, I have found the following which I presume is targeting the output: Would be great if one could point out any points I may have missed out! A head start would be great!
claim
Change:
<ins> //@ check-pass //@ compile-flags: -Zvalidate-mir fn hello() -> &'static [impl Sized; 0] { if false { let x = hello(); let _: &[i32] = x; } &[] } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'', 'thread 'rustc' panicked at 'broken MIR in Item(DefId(0:7 ~ a[e8bd]::hello)) (after pass CheckPackedRef) at bb3[6]:'' 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: [mirbuilt] building MIR for [hasffiunwindcalls] checking if contains FFI-unwind calls --
another one from rust #![feature(typealiasimpltrait)] fn rpit() -impl Sized {} pub type Tait = impl Sized; pub fn foo() -Box<dyn std::future::Future<Output = Tait{ Box::new(async { let out: Tait = rpit(); _out }) } ``
another one that is a bit smaller than the original example:
Change:
write!( w, <del> " {} for {}", </del> <ins> " {}{} for {}", tcx.impl_polarity(impl_def_id).as_str(), </ins> trait_ref.print_only_trait_path(), tcx.type_of(impl_def_id).instantiate_identity() )

Discussion:
The following code: produces: which reads as: any , which isn't realy true. It realy implements . Perhaps the error message should add a in front of the impl to make it more obvious, like this:
Hi , I'd like to take up this issue if it has not been assigned yet. However this would be my first contribution so I just want to confirm it's a good first task. Thanks!
Yeah, for sure! It should be as simple as updating () to account for the polarity. You can query/obtain the impl polarity with . Feel free to reach out here or on Zulip if you have any questions.
Change:
let some = Some(110u); let none: Option<int> = None; <ins> let some_fat = Some("abc"); let none_fat: Option<&'static str> = None; </ins> let nested_variant1 = NestedVariant1( NestedStruct {

Discussion:
Debuginfo for (and probably also ) enums is not correct if the pointer that doubles as discriminant is a fat pointer. Steps to reproduce: (1) Compile the following program with (2) Print the value of in LLDB with pretty printers enabled: This should print instead of . Maybe it's just the LLDB pretty printer that needs to be adapted.
Change:
self.length = dfs(self.root.as_ref().unwrap().as_ref()); } <ins> /// Creates a consuming iterator visiting all the keys, in sorted order. /// The map cannot be used after calling this. /// The iterator element type is `K`. /// /// # Examples /// /// ``` /// #![feature(map_into_keys_values)] /// use std::collections::BTreeMap; /// /// let mut a = BTreeMap::new(); /// a.insert(2, "b"); /// a.insert(1, "a"); /// /// let keys: Vec<i32> = a.into_keys().collect(); /// assert_eq!(keys, [1, 2]); /// ``` #[inline] #[unstable(feature = "map_into_keys_values", issue = "75294")] pub fn into_keys(self) -> IntoKeys<K, V> { IntoKeys { inner: self.into_iter() } } /// Creates a consuming iterator visiting all the values, in order by key. /// The map cannot be used after calling this. /// The iterator element type is `V`. /// /// # Examples /// /// ``` /// #![feature(map_into_keys_values)] /// use std::collections::BTreeMap; /// /// let mut a = BTreeMap::new(); /// a.insert(1, "hello"); /// a.insert(2, "goodbye"); /// /// let values: Vec<&str> = a.into_values().collect(); /// assert_eq!(values, ["hello", "goodbye"]); /// ``` #[inline] #[unstable(feature = "map_into_keys_values", issue = "75294")] pub fn into_values(self) -> IntoValues<K, V> { IntoValues { inner: self.into_iter() } } </ins> } #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
#![crate_name = "dependency"] #![crate_type = "rlib"] <del> pub struct Type; pub trait Trait {} impl Trait for Type {} </del> <ins> pub struct Type(pub i32); pub trait Trait { fn foo(&self); fn bar(); } impl Trait for Type { fn foo(&self) {} fn bar() {} } </ins> pub fn do_something<X: Trait>(_: X) {}

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
use syntax::ast_map; use syntax::ast_util::{def_id_of_def, local_def}; use syntax::codemap::Span; <ins> use syntax::owned_slice::OwnedSlice; </ins> use syntax::parse::token; use syntax::visit;

Discussion:
Not exactly sure what the minimal failing test case is yet.
I think that I was running an out of date rustc. I don't think that this is a problem on master.
Actually, I hit this on rustc that I just built from master.
I talked to and he gave me access to his codebase, which I used to narrow down: Converting to a normal trait method and implementing it for stops the ICE. cc
Change:
} .item-info .stab { <del> /* This min-height is needed to unify the height of the stab elements because some of them have emojis. */ min-height: 36px; display: flex; </del> <ins> display: block; </ins> padding: 3px; margin-bottom: 5px; <del> align-items: center; vertical-align: text-bottom; </del> } .item-name .stab { margin-left: 0.3125em;

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
/// /// [`Unpin`]: ../../std/marker/trait.Unpin.html /// [`Pin::into_inner`]: #method.into_inner <del> #[unstable(feature = "pin_into_inner", issue = "60245")] </del> <ins> #[stable(feature = "pin_into_inner", since = "1.39.0")] </ins> #[inline(always)] pub unsafe fn into_inner_unchecked(pin: Pin<P>) -> P { pin.pointer

Discussion:
This is a tracking issue for and , proposed and implemented in
modify labels to T-libs, C-tracking-issue.
These have been available on nightly for some time with no controversy. They're pretty useful when working with -- do y'all have anything you'd like to see here before merging?
Let's see! Proposed APIs look to be: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [ ] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
r+
I don't think you can r+ issues ;)
Since this seems to have gone quiet again, I took the liberty of creating to do the actual stabilization.
Change:
<ins> warning: the feature `impl_trait_in_bindings` is incomplete and may cause the compiler to crash --> $DIR/bound-normalization-pass.rs:6:12 | LL | #![feature(impl_trait_in_bindings)] |            ^^^^^^^^^^^^^^^^^^^^^^ </ins>

Discussion:
With the following code: comes the following error: However, this function compiles correctly without the keyword.
cc
You can trigger this without async/await using : cc
Some more reduction in genericity and clearing up a few things: The problem is that is not know in impl trait items. It's also not related to the return position, but refers to any impl trait in the function. Outside of impl trait can be resolved without a problem, so it must be something related to the way impl trait reuses the generics of its parent.
It seems to be a missing normalization, most likely.
I have a local fix for reduction above, but is making this rather difficult as it makes output not work properly.
This also happens for definitions: My fix only seems to turn this into a cycle error for some reason. EDIT: Nevermind I just broke existential types in general lol
Marking as blocking, although I think there's minimal future compat risk. If push came to shove I personally would be ok with removing this from the blocking list. But then it looks like already fixed it =)
I think the problem is on this line of code: in particular, we "instantiate" the predicates -- meaning, substitute in the values for their type parameters -- but we never normalize them. We should be able to invoke the methods. Note that in this code we do have an available, as well, in . I think we should be able to invoke: this returns an  value, which contains obligations that must be pushed into .
Hmm, that code is only invoked if is true, which I think wouldn't be the case here since there are no region bounds at all (right?). I also noticed that does not exist in this context ( is an ), and there's no nearby either. However, another place where is called without normalizing the result is here, further down in the same file: there does exist (as does ). Quick testing shows that normalizing there fixes this issue as well, and as a bonus also fixes the issue with without ICEs!
good catch -- actually I think the lines you found are the ones I meant to direct you to in the first place. I see you have some other problems on the PR, looking now.
Change:
pub(crate) fn universe_info(&self, universe: ty::UniverseIndex) -> UniverseInfo<'tcx> { self.universe_causes[&universe].clone() } <ins> /// Tries to find the terminator of the loop in which the region 'r' resides. /// Returns the location of the terminator if found. pub(crate) fn find_loop_terminator_location( &self, r: RegionVid, body: &Body<'_>, ) -> Option<Location> { let scc = self.constraint_sccs.scc(r.to_region_vid()); let locations = self.scc_values.locations_outlived_by(scc); for location in locations { let bb = &body[location.block]; if let Some(terminator) = &bb.terminator { // terminator of a loop should be TerminatorKind::FalseUnwind if let TerminatorKind::FalseUnwind { .. } = terminator.kind { return Some(location); } } } None } </ins> } impl<'tcx> RegionDefinition<'tcx> {

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. --Given the following code: The current output is: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this: