jiebi/CodeConvo huggingface dataset:
Change:
I was playing around with existential types in nightly, forgot to update some code, and hit this ICE. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label: +requires-nightly
I'm not sure, if it's the same cause, but this ICE seems related (found in by so I'll post it here instead of in a new issue:
The original ICE has been fixed by but hasn't, could you open a new issue if it hasn't been reported yet?

Discussion:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; //~^ ERROR: hidden type for `impl Trait` captures lifetime that does not appear in bounds //~| ERROR: the type `&'<empty> str` does not fulfill the required lifetime //~| ERROR: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements trait Output<'a> {} impl<'a> Output<'a> for &'a str {} fn cool_fn<'a>(arg: &'a str) -> OpaqueOutputImpl<'a> { let out: OpaqueOutputImpl<'a> = arg; arg } fn main() { let s = String::from("wassup"); cool_fn(&s); } </ins>

<ins> error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | note: hidden type `&'<empty> str` captures lifetime smaller than the function body --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ error[E0477]: the type `&'<empty> str` does not fulfill the required lifetime --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | note: type must outlive the lifetime `'a` as defined on the item at 5:23 --> $DIR/issue-85113.rs:5:23 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                       ^^ error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | = note: first, the lifetime cannot outlive the empty lifetime... note: ...but the lifetime must also be valid for the lifetime `'a` as defined on the item at 5:23... --> $DIR/issue-85113.rs:5:23 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                       ^^ note: ...so that the types are compatible --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ = note: expected `Output<'a>` found `Output<'_>` error: aborting due to 3 previous errors Some errors have detailed explanations: E0477, E0495, E0700. For more information about an error, try `rustc --explain E0477`. </ins>
Change:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting

Discussion:
.enumerate() .map(|(idx, e)| idx.wrapping_add(e)) .fuse() <del> .peekable() </del> .collect::<Vec<usize>>(), ); });

.zip(std::iter::repeat(1usize)) .map(|(a, b)| a + b) .map_while(Option::Some) <del> .peekable() </del> .skip(1) .map(|e| if e != usize::MAX { Ok(std::num::NonZeroUsize::new(e)) } else { Err(()) }); assert_in_place_trait(&iter);

} } <ins> // regression test for issue #85322. Peekable previously implemented InPlaceIterable, // but due to an interaction with IntoIter's current Clone implementation it failed to uphold // the contract. #[test] fn test_collect_after_iterator_clone() { let v = vec![0; 5]; let mut i = v.into_iter().map(|i| i + 1).peekable(); i.peek(); let v = i.clone().collect::<Vec<_>>(); assert_eq!(v, [1, 1, 1, 1, 1]); assert!(v.len() <= v.capacity()); } </ins> #[test] fn test_cow_from() { let borrowed: &[_] = &["borrowed", "(slice)"];

<del> use crate::iter::{adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen}; </del> <ins> use crate::iter::{adapters::SourceIter, FusedIterator, TrustedLen}; </ins> use crate::ops::{ControlFlow, Try}; /// An iterator with a `peek()` that returns an optional reference to the next

unsafe { SourceIter::as_inner(&mut self.iter) } } } <del> #[unstable(issue = "none", feature = "inplace_iteration")] unsafe impl<I: InPlaceIterable> InPlaceIterable for Peekable<I> {} </del>
Change:
<!-- 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: I expected to see this happen: generate Instead, this happened: <!-- 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
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .

Discussion:
return false; } <ins> if let DefKind::Static(_) = tcx.def_kind(def_id) { // We cannot monomorphize statics from upstream crates. return false; } </ins> if !tcx.is_mir_available(def_id) { bug!("no MIR available for {:?}", def_id); }

<ins> -include ../../run-make-fulldeps/tools.mk # Regression test for issue #85401 # Verify that we do not ICE when trying to access MIR for statics, # but emit an error when linking. OUTPUT_FILE := $(TMPDIR)/build-output all: $(RUSTC) --crate-type rlib --crate-name foo -Crelocation-model=pic --edition=2018 foo.rs -Zalways-encode-mir=yes --emit metadata -o $(TMPDIR)/libfoo.rmeta $(RUSTC) --crate-type rlib --crate-name bar -Crelocation-model=pic --edition=2018 bar.rs -o $(TMPDIR)/libbar.rlib --extern=foo=$(TMPDIR)/libfoo.rmeta $(RUSTC) --crate-type bin --crate-name baz -Crelocation-model=pic --edition=2018 baz.rs -o $(TMPDIR)/baz -L $(TMPDIR) --extern=bar=$(TMPDIR)/libbar.rlib > $(OUTPUT_FILE) 2>&1; [ $$? -eq 1 ] cat  $(OUTPUT_FILE) $(CGREP) 'crate `foo` required to be available in rlib format, but was not found in this form' < $(OUTPUT_FILE) # -v tests are fragile, hopefully this text won't change $(CGREP) -v "internal compiler error" < $(OUTPUT_FILE) </ins>

<ins> pub fn bar() { println!("bar {}", foo::FOO); foo::foo(); } </ins>

<ins> fn main() { bar::bar() } </ins>

<ins> pub static FOO: &str = "foo"; pub fn foo() { println!("foo"); } </ins>
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this: (which matches ) Instead, this happened: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Stable rust 1.52.1 <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --I suspect that this issue was caused by
Let's bisect this: ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
(I ended up doing the bisection myself, sorry for the ping everyone!) finds a regression in (which does contain rust-lang/stdarch), cc
cc
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical +T-compiler

Discussion:
<del> Subproject commit c14e98417feb406df66e821ccd81e1293b4baa6f </del> <ins> Subproject commit 37d6e1886369ea0176356286dc7fbd42ee5aa79c </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. 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!
Sure, I can look at this one.
Thanks for merging ! If I'm reading things right, I think I need a new crater release of it so I can update ? If so, can you please make one of those?

Discussion:
[[package]] name = "racer" <del> version = "2.1.46" </del> <ins> version = "2.1.47" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "e7cbda48a9124ed2e83766d2c15e3725710d344abca35fad8cf52341a55883b1" </del> <ins> checksum = "513c70e67444a0d62fdc581dffa521c6820942a5f08300d0864863f8d0e750e3" </ins> dependencies = [ "bitflags", "clap",

<del> Subproject commit 097d8908339e20435078233a55a1a3335fe7c2eb </del> <ins> Subproject commit 9ed6f96f2ff85753c5a6ac290ee88ecb2831ab2e </ins>
Change:
Hello, It feels like this shouldn't be an issue but I don't really know where to post it otherwise.. says that there is a more efficient solution when the place is access for read called , but the latter does not exist anywhere. I'm guessing it should be referring to , but I am not entirely sure. Also as a side question, I'd be curious to know why it is slower to access a place for write than it is for read. I'm going to spend a bit of time reading that part of the code, if I ever find other tiny things like that, where should I report it ? It feels like this could be a small discussion in a chat followed by a tiny PR rather than an issue. Thank you ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If you have a question while making a PR, on good resource is Zulip: https://rust- Depending how easy a PR it is and whether you're reasonably confident in your deduction, you could also just make a PR changing it and the reviewer will confirm that the update is accurate.
Your analysis looks correct to me. I'm working up a PR to fix these docs. claim
Issues like this are welcome, as are small PRs. :)

Discussion:
Ok(OpTy { op, layout: place.layout }) } <del> // Evaluate a place with the goal of reading from it.  This lets us sometimes // avoid allocations. </del> <ins> /// Evaluate a place with the goal of reading from it.  This lets us sometimes /// avoid allocations. </ins> pub fn eval_place_to_op( &self, place: mir::Place<'tcx>,

} /// Computes a place. You should only use this if you intend to write into this <del> /// place; for reading, a more efficient alternative is `eval_place_for_read`. </del> <ins> /// place; for reading, a more efficient alternative is `eval_place_to_op`. </ins> #[instrument(skip(self), level = "debug")] pub fn eval_place( &mut self,
Change:
I tried : I expected to see this happen: no warnings, and its method are not publicly documented. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looks like the context here could give us the information needed to determine 1) if the item is an associated function definition, and 2) if the type on which it is implemented itself has the attribute.

Discussion:
return; } <ins> // If the method is an impl for an item with docs_hidden, don't doc. if method_context(cx, impl_item.hir_id()) == MethodLateContext::PlainImpl { let parent = cx.tcx.hir().get_parent_did(impl_item.hir_id()); let impl_ty = cx.tcx.type_of(parent); let outerdef = match impl_ty.kind() { ty::Adt(def, _) => Some(def.did), ty::Foreign(def_id) => Some(*def_id), _ => None, }; let is_hidden = match outerdef { Some(id) => cx.tcx.is_doc_hidden(id), None => false, }; if is_hidden { return; } } </ins> let (article, desc) = cx.tcx.article_and_description(impl_item.def_id.to_def_id()); self.check_missing_docs_attrs(cx, impl_item.def_id, impl_item.span, article, desc); }

<ins> // check-pass // See issue #85526. // This test should produce no warnings. #![deny(missing_docs)] //! Crate docs #[doc(hidden)] pub struct Foo; impl Foo { pub fn bar() {} } fn main() {} </ins>
Change:
I'm really sorry if this isn't a compiler bug, but it smells like one. I've managed to bag it into a few lines of code. Change or reorder anything and the test will pass. If you run this repo it will pass: If you add in it will fail. ( You will need to ) It seems to correctly figure out that the condion is false but then take the true branch of the if anyway. There's no unsafe in the code so there should be no UB.... Why for instance does have to be there for the bug to manifest itself? I am clueless... This is with the latest nightly ( rustc 1.54.0-nightly ( 2021-05-21) ), but have confirmed it fails on beta too. I would love to know what is going on - it seems very wierd behaviour.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Smells like an LLVM miscompilation issue? Since it is target-specific, a MIR issue seems unlikely. Cc
I'm afraid the ping didn't work ~ ping cc:
Error: This team () cannot be pinged via this command; it may need to be to on the master branch. Please let know if you're having trouble with this bot.
Error: This team () cannot be pinged via this command; it may need to be to on the master branch. Please let know if you're having trouble with this bot.
With Note that reads a local that has not been initialized.
Upstream issue:

Discussion:
<del> Subproject commit a04279dd5736be294843af15ac07ca499c02acef </del> <ins> Subproject commit ec995b75d71c5f3b9a82fe084259477eb22f74da </ins>
Change:
IIRC we agreed upon the notion of a "slot", which is a simple way to create a mutable interior value. This lets us abstract over the mutable and immutable vectors without the subtyping relation that "mutable?" introduces, which is painful (and which we never got right in the presence of generics). So you could construct a slot using, say, , and that creates a mutable pseudo-box that is interior. Slots have no representation at the IR level; they're purely a way to help us enforce immutability restrictions. would become , would become , etc. This may be appropriate for the first milestone, depending on how serious we consider the type soundness hole with generics to be for 0.1.
So taking the value of a slot in a non-lvalue context would be an error?
Actually thinking through this more, slots have several weird issues relating to autoderef and generic functions. Talked this over with Dave and I think it makes sense to keep , but to fix the issue with covariance/invariance and rename it to something a little less gross ( maybe?)
Dupe of issue .

Discussion:
[[package]] name = "linux-raw-sys" <del> version = "0.4.7" </del> <ins> version = "0.4.10" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "1a9bad9f94746442c783ca431b22403b519cd7fbeed0533fdd6328b2f2212128" </del> <ins> checksum = "da2479e8c062e40bf0066ffa0bc823de0a9368974af99c9f6df941d2c231e03f" </ins> [[package]] name = "litemap"

[[package]] name = "rustix" <del> version = "0.38.14" </del> <ins> version = "0.38.19" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "747c788e9ce8e92b12cd485c49ddf90723550b654b32508f979b71a7b1ecda4f" </del> <ins> checksum = "745ecfa778e66b2b63c88a61cb36e0eea109e803b0b86bf9879fbc77c70e86ed" </ins> dependencies = [ "bitflags 2.4.0", "errno",
Change:
Unfortunately I don't have an easy-to-repro case. This happened while working on Rocket's docs. I renamed a method which made a previously valid link invalid and I got this ICE. Fixing the doc link fixes the error. Backtrace from rustc 1.54.0-nightly ( 2021-05-21) follows: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If someone can compile a build of rustdoc that comments out this line: you should get a much better error message that says exactly what went wrong (it will start with "incompatible link kind"), and that should give an idea of where the bug is.
can you link to the exact commit of Rocket that caused the ICE?
This is the current tip, You may be able to replicate this by referencing in the struct's docs in and then changing the method's name to something else. If this fails, I will try to create a reproducible case.
MCVE: label -E-needs-mcve
claim
Error: Parsing relabel command in failed: ...'needs-MCVE' '): rs'... Please let know if you're having trouble with this bot.
Error: Parsing relabel command in failed: ...'needs-mcve' '): rs'... Please let know if you're having trouble with this bot.

Discussion:
return Suggestion::Macro; } else if kind == DefKind::Fn || kind == DefKind::AssocFn { return Suggestion::Function; <ins> } else if kind == DefKind::Field { return Suggestion::RemoveDisambiguator; </ins> } let prefix = match kind {

Function, /// `m!` Macro, <ins> /// `foo` without any disambiguator RemoveDisambiguator, </ins> } impl Suggestion {

Self::Prefix(x) => format!("prefix with `{}@`", x).into(), Self::Function => "add parentheses".into(), Self::Macro => "add an exclamation mark".into(), <ins> Self::RemoveDisambiguator => "remove the disambiguator".into(), </ins> } }

Self::Prefix(prefix) => format!("{}@{}", prefix, path_str), Self::Function => format!("{}()", path_str), Self::Macro => format!("{}!", path_str), <ins> Self::RemoveDisambiguator => path_str.into(), </ins> } } }

<ins> #![deny(rustdoc::broken_intra_doc_links)] //~^NOTE the lint level is defined here /// [`Foo::bar`] /// [`Foo::bar()`] //~^ERROR incompatible link kind for `Foo::bar` //~|HELP to link to the field, remove the disambiguator //~|NOTE this link resolved to a field, which is not a function pub struct Foo { pub bar: u8 } </ins>

<ins> error: incompatible link kind for `Foo::bar` --> $DIR/field-ice.rs:5:6 | LL | /// [`Foo::bar()`] |      ^^^^^^^^^^^^ help: to link to the field, remove the disambiguator: ``Foo::bar`` | note: the lint level is defined here --> $DIR/field-ice.rs:1:9 | LL | #![deny(rustdoc::broken_intra_doc_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: this link resolved to a field, which is not a function error: aborting due to previous error </ins>
Change:
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.

Discussion:
} 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();

); write_sidebar_links(out, blanket_format); } <del> 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); } </del> } } }