jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // This code (probably) _should_ compile, but it currently does not because we // are not smart enough about implied bounds. use std::io; fn real_dispatch<T, F>(f: F) -> Result<(), io::Error> //~^ NOTE required by a bound in this where F: FnOnce(&mut UIView<T>) -> Result<(), io::Error> + Send + 'static, //~^ NOTE required by this bound in `real_dispatch` //~| NOTE required by a bound in `real_dispatch` { todo!() } #[derive(Debug)] struct UIView<'a, T: 'a> { _phantom: std::marker::PhantomData<&'a mut T>, } trait Handle<'a, T: 'a, V, R> { fn dispatch<F>(&self, f: F) -> Result<(), io::Error> where F: FnOnce(&mut V) -> R + Send + 'static; } #[derive(Debug, Clone)] struct TUIHandle<T> { _phantom: std::marker::PhantomData<T>, } impl<'a, T: 'a> Handle<'a, T, UIView<'a, T>, Result<(), io::Error>> for TUIHandle<T> { fn dispatch<F>(&self, f: F) -> Result<(), io::Error> where F: FnOnce(&mut UIView<'a, T>) -> Result<(), io::Error> + Send + 'static, { real_dispatch(f) //~^ ERROR expected a `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` //~| NOTE expected an `FnOnce<(&mut UIView<'_, T>,)>` closure, found `F` //~| NOTE expected a closure with arguments //~| NOTE required by a bound introduced by this call } } fn main() {} </ins>

Related discussion:
text: Sorry, this is not necessarily the smallest possible example. Please let me know if this is unhelpful and I'll come up with something more concise. Given the following code: The output in current stable (1.63.0) is: (Please note the "expected closure with ... found closure with ..." hint.) From 1.64 onwards, the expected/found hint is omitted: To me the 1.63 behaviour is preferable to that from 1.64+ as it can often be non-obvious where the differences lie.
searched nightlies: from nightly-2022-06-01 to nightly-2022-08-11 regressed nightly: nightly-2022-07-23 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: </details
Looks like it was caused by , which is pretty big diagnostics PR in that rollup. cc
Of course I caused it.
label -E-needs-bisection
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
/// Parse a `mod <foo> { ... }` or `mod <foo>;` item fn parse_item_mod(&mut self, outer_attrs: &[Attribute]) -> PResult<'a, ItemInfo> { <del> let outer_attrs = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }.process_cfg_attrs(outer_attrs.to_owned()); </del> <ins> let (in_cfg, outer_attrs) = { let mut strip_unconfigured = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }; let outer_attrs = strip_unconfigured.process_cfg_attrs(outer_attrs.to_owned()); (strip_unconfigured.in_cfg(&outer_attrs), outer_attrs) }; </ins> let id_span = self.span; let id = self.parse_ident()?; if self.check(&token::Semi) { self.bump(); <del> // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) </del> <ins> if in_cfg { // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) } else { let placeholder = ast::Mod { inner: syntax_pos::DUMMY_SP, items: Vec::new() }; Ok((id, ItemKind::Mod(placeholder), None)) } </ins> } else { let directory = self.directory.clone(); self.push_directory(id, &outer_attrs);

Related discussion:
text: This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is
Code change:
/// Parse a `mod <foo> { ... }` or `mod <foo>;` item fn parse_item_mod(&mut self, outer_attrs: &[Attribute]) -> PResult<'a, ItemInfo> { <del> let outer_attrs = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }.process_cfg_attrs(outer_attrs.to_owned()); </del> <ins> let (in_cfg, outer_attrs) = { let mut strip_unconfigured = ::config::StripUnconfigured { config: &self.cfg, sess: self.sess, should_test: false, // irrelevant features: None, // don't perform gated feature checking }; let outer_attrs = strip_unconfigured.process_cfg_attrs(outer_attrs.to_owned()); (strip_unconfigured.in_cfg(&outer_attrs), outer_attrs) }; </ins> let id_span = self.span; let id = self.parse_ident()?; if self.check(&token::Semi) { self.bump(); <del> // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) </del> <ins> if in_cfg { // This mod is in an external file. Let's go get it! let (m, attrs) = self.eval_src_mod(id, &outer_attrs, id_span)?; Ok((id, m, Some(attrs))) } else { let placeholder = ast::Mod { inner: syntax_pos::DUMMY_SP, items: Vec::new() }; Ok((id, ItemKind::Mod(placeholder), None)) } </ins> } else { let directory = self.directory.clone(); self.push_directory(id, &outer_attrs);

Related discussion:
text: The ABI string for is validated while being parsed, meaning one can get errors about in 'd off modules: (Compiled without .) This isn't necessarily wrong, but it is weird and somewhat annoying if one needs it. (It can be worked-around by hiding the block behind a macro: .)
Any ideas where we could move the check into? Any of borrowck, typeck, lints, privacy and resolve don’t exactly fit. I think trans thematically is the best place to have it, but it is a shame to have it error out so late for such an easy to detect and obvious error. I’m personally fine keeping it a parse error, IMO there’s no reason to have cfg blocks with code that does not compile.
NB. we can add a special pass if necessary (i.e. there's no reason for us to compromise by putting the error in trans). Yeah, of course. However, there are cases when the d code does compile, e.g. I encountered this in where I an ABI and had to use it in inside a module. Similarly, if we add ABIs in future, someone might have code designed to compile with Rust 1.0.0, but can take advantage of the newer ABI if it is available.
The block might be to gate nightly-only code. The code within the gated block is compiled only when a cargo feature is enabled; the code outside it works both on stable and nightly. I hit it myself; I'm playing with the SIMD work from pull request, but I want to keep the crate working on stable. .
Code change:
} function showResults(results) { <del> if (results.others.length === 1 && getCurrentValue("rustdoc-go-to-only-result") === "true") { </del> <ins> var search = getSearchElement(); if (results.others.length === 1 && getCurrentValue("rustdoc-go-to-only-result") === "true" // By default, the search DOM element is "empty" (meaning it has no children not // text content). Once a search has been run, it won't be empty, even if you press // ESC or empty the search input (which also "cancels" the search). && (!search.firstChild || search.firstChild.innerText !== getSearchLoadingText())) { </ins> var elem = document.createElement("a"); elem.href = results.others[0].href; elem.style.display = "none"; // For firefox, we need the element to be in the DOM so it can be clicked. document.body.appendChild(elem); elem.click(); <ins> return; </ins> } var query = getQuery(search_input.value);

Related discussion:
text: Enable "Directly go to item in search if there is only one result" option on Settings ! Search an unique item in search box generated by rustdoc, it will lead you to the doc of that item. Click the go back button in browser, the page will change to previous search result and go forward to the doc of the searched item. How to reproduce the issue: Go to std doc: Search for "PhantomData" Click the go back button in browser. : 1.47.0-nightly ( 2020-08-20) cc
Well, you can but since there is only one result, it puts you back haha. (Ok, we can consider it as bug, but it's a funny one)
The single search result page can be elided using the to disappear it, leaving the back button to take you to before the search. I believe this would be the desired behavior?
What about detecting the key release to check if there's a single item and redirect, instead of redirecting after calculating the results?
Code change:
impl Encodable for Span { fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> { <del> try!(s.emit_u32(self.lo.0)); s.emit_u32(self.hi.0) </del> <ins> s.emit_struct("Span", 2, |s| { try!(s.emit_struct_field("lo", 0, |s| { self.lo.encode(s) })); s.emit_struct_field("hi", 1, |s| { self.hi.encode(s) }) }) </ins> } } impl Decodable for Span { fn decode<D: Decoder>(d: &mut D) -> Result<Span, D::Error> { <del> let lo = BytePos(try! { d.read_u32() }); let hi = BytePos(try! { d.read_u32() }); Ok(mk_sp(lo, hi)) </del> <ins> d.read_struct("Span", 2, |d| { let lo = try!(d.read_struct_field("lo", 0, |d| { BytePos::decode(d) })); let hi = try!(d.read_struct_field("hi", 1, |d| { BytePos::decode(d) })); Ok(mk_sp(lo, hi)) }) </ins> } }

Related discussion:
text: In , changed the encoding of from serializing the value as a single into serializing two sequential values. Unfortunately this violates the serialization protocol, and causes a span like to be serialized as . Here's the current implementation: Semantically speaking these spans should be serialized as a tuple, which would properly delimit the two values, but since that'd add a bunch of tagging overhead to the output, it'd probably be more efficient to just restore the old encoding:
Code change:
self.r .session <del> .struct_span_warn(item.span, "`$crate` may not be imported") .note( "`use $crate;` was erroneously allowed and  will become a hard error in a future release", ) </del> <ins> .struct_span_err(item.span, "`$crate` may not be imported") </ins> .emit(); } }

Related discussion:
text: The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.
Code change:
pub(crate) fn unsafety(&self, tcx: TyCtxt<'_>) -> hir::Unsafety { tcx.trait_def(self.def_id).unsafety } <ins> pub(crate) fn is_object_safe(&self, tcx: TyCtxt<'_>) -> bool { tcx.check_is_object_safe(self.def_id) } </ins> } #[derive(Clone, Debug)]

Related discussion:
text: So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".
Code change:
pub(crate) fn unsafety(&self, tcx: TyCtxt<'_>) -> hir::Unsafety { tcx.trait_def(self.def_id).unsafety } <ins> pub(crate) fn is_object_safe(&self, tcx: TyCtxt<'_>) -> bool { tcx.check_is_object_safe(self.def_id) } </ins> } #[derive(Clone, Debug)]

Related discussion:
text: My reasoning here is that conceptually, is somewhat like an implementor of the trait.
I don't think this is necessarily true, you can have a that doesn't implement . But putting the text under "implementors" seems as good a place as any
Just out of curiosity, how can I have a that doesn’t implement ?
I don't think that's actually true, I misremembered.
We have one on: Would anyone else like to weigh in? Good enough to proceed with implementation?
Any update on this? :)
I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?
I like suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas: Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there. Add information to the documentation of any method that causes the trait to be not object-safe.
I think it’s still fine to mention under “Implementors” like “This trait is not object safe: doesn’t implement ”, but I also like the idea of the new section. I see this issue doesn’t have an assignee currently, can I claim this?
You can but since we didn't reach a consensus, any PR would hang around until we reach one.
Code change:
val.into() } <del> Aggregate(ref kind, ref fields) => Value::Aggregate { fields: fields .iter() .map(|field| self.eval_operand(field).map_or(Value::Uninit, Value::Immediate)) .collect(), variant: match **kind { AggregateKind::Adt(_, variant, _, _, _) => variant, AggregateKind::Array(_) | AggregateKind::Tuple | AggregateKind::Closure(_, _) | AggregateKind::Coroutine(_, _) | AggregateKind::CoroutineClosure(_, _) => VariantIdx::new(0), }, }, </del> <ins> Aggregate(ref kind, ref fields) => { // Do not const pop union fields as they can be // made to produce values that don't match their // underlying layout's type (see ICE #121534). // If the last element of the `Adt` tuple // is `Some` it indicates the ADT is a union if let AggregateKind::Adt(_, _, _, _, Some(_)) = **kind { return None; }; Value::Aggregate { fields: fields .iter() .map(|field| { self.eval_operand(field).map_or(Value::Uninit, Value::Immediate) }) .collect(), variant: match **kind { AggregateKind::Adt(_, variant, _, _, _) => variant, AggregateKind::Array(_) | AggregateKind::Tuple | AggregateKind::Closure(_, _) | AggregateKind::Coroutine(_, _) | AggregateKind::CoroutineClosure(_, _) => VariantIdx::new(0), }, } } </ins> Repeat(ref op, n) => { trace!(?op, ?n);

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)', 'error: internal compiler error: invalid asymmetric binary op Sub: (i32), 2 (u32)' 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: [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Const prop We need to make it not do union field accesses
Reduced a bit further:
claim
Code change:
Some(x) => x, }; if local_tmp_s0 != local_tmp_s1 <ins> // The field-and-variant information match up. </ins> || vf_s0 != vf_s1 <ins> // Source and target locals have the same type. // FIXME(Centril | oli-obk): possibly relax to same layout? || local_decls[local_0].ty != local_decls[local_1].ty // We're setting the discriminant of `local_0` to this variant. </ins> || Some((local_0, vf_s0.var_idx)) != match_set_discr(s2) { continue;

Related discussion:
text: PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are
Code change:
Some(x) => x, }; if local_tmp_s0 != local_tmp_s1 <ins> // The field-and-variant information match up. </ins> || vf_s0 != vf_s1 <ins> // Source and target locals have the same type. // FIXME(Centril | oli-obk): possibly relax to same layout? || local_decls[local_0].ty != local_decls[local_1].ty // We're setting the discriminant of `local_0` to this variant. </ins> || Some((local_0, vf_s0.var_idx)) != match_set_discr(s2) { continue;

Related discussion:
text: Since few Rustc nightly versions I see a miscompilation problem with the code below. I am using: If I compile with: The code:
NB: this is because it needs an unstable CLI flag to reproduce.
cc since this might have something to do with recent const-eval work (apologies if I left anyone out)
I've managed to minify it to
Bisected it to , most probably the same issue as
Code change:
req_introduces_loc: subdiag, has_lifetime: sup_r.has_name(), <del> lifetime: sup_r.to_string(), </del> <ins> lifetime: lifetime_name.clone(), has_param_name: simple_ident.is_some(), param_name: simple_ident.map(|x| x.to_string()).unwrap_or_default(), </ins> spans_empty, bound, };

Related discussion:
text: [ ] Previous Stable [ ] Current Stable [ ] Current Beta [X] Current Nightly No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is another case for And except for the missing argument issue, there is an copy-paste bug in :
Code change:
pub use self::scoped_tls::ScopedKey; #[doc(hidden)] pub use self::local::__KeyInner as __LocalKeyInner; <ins> #[doc(hidden)] pub use self::scoped_tls::__KeyInner as __ScopedKeyInner; </ins> //////////////////////////////////////////////////////////////////////////////// // Builder

Related discussion:
text: There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?