jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // https://github.com/rust-lang/rust/issues/100252 #![feature(no_core)] #![no_core] mod bar { // @set baz = import_from_private.json "$.index[*][?(@.kind=='struct')].id" pub struct Baz; // @set impl = - "$.index[*][?(@.kind=='impl')].id" impl Baz { // @set doit = - "$.index[*][?(@.kind=='method')].id" pub fn doit() {} } } // @set import = - "$.index[*][?(@.kind=='import')].id" pub use bar::Baz; // FIXME(adotinthevoid): Use hasexact once #99474 lands // @has - "$.index[*][?(@.kind=='module')].inner.items[*]" $import // @is  - "$.index[*][?(@.kind=='import')].inner.id" $baz // @has - "$.index[*][?(@.kind=='struct')].inner.impls[*]" $impl // @has - "$.index[*][?(@.kind=='impl')].inner.items[*]" $doit </ins>

Related discussion:
text: running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls
Code change:
fn bar() -> Self::Output; } <ins> // @has foo/trait.Safe.html // @!has - '//div[@class="sidebar-elems"]//h3/a[@href="#object-safety"]' '' pub trait Safe { fn access(&self); } </ins> // @has foo/struct.Bar.html // @has - '//div[@class="sidebar-elems"]//h3/a[@href="#fields"]' 'Fields' // @has - '//*[@class="sidebar-elems"]//section//a[@href="#structfield.f"]' 'f'

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:
fn bar() -> Self::Output; } <ins> // @has foo/trait.Safe.html // @!has - '//div[@class="sidebar-elems"]//h3/a[@href="#object-safety"]' '' pub trait Safe { fn access(&self); } </ins> // @has foo/struct.Bar.html // @has - '//div[@class="sidebar-elems"]//h3/a[@href="#fields"]' 'Fields' // @has - '//*[@class="sidebar-elems"]//section//a[@href="#structfield.f"]' 'f'

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:
[[package]] name = "jsonrpc-core" <del> version = "13.1.0" </del> <ins> version = "13.2.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "dd42951eb35079520ee29b7efbac654d85821b397ef88c8151600ef7e2d00217" </del> <ins> checksum = "91d767c183a7e58618a609499d359ce3820700b3ebb4823a18c343b4a2a41a0d" </ins> dependencies = [ "futures", "log",

Related discussion:
text: 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! cc the PR reviewer, and nominating for compiler team prioritization.
Code change:
[63421]: https://github.com/rust-lang/rust/pull/63421/ [cargo/7084]: https://github.com/rust-lang/cargo/pull/7084/ [cargo/7143]: https://github.com/rust-lang/cargo/pull/7143/ <ins> [63048]: https://github.com/rust-lang/rust/pull/63048 </ins> [`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast [`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32

Related discussion:
text: At some point between Rust 1.34.0 and 1.39.0, the ability to add documentation to reexported items was , but I can't find it mentioned in either or the rust- blog posts. Maybe this should be mentioned in the RELEASE notes for the version that that feature? I have a crate that I use to test stuff, and used to document this: !
This was changed in 1.38 (coincidentally also the release rust-std spiked from a 61.2 MB to 173.3 MB download). are you interested in making a PR?
Sure, what are the PRs that made this possible?
Oh I have no idea :laughing: I found it by bisecting.
Looks like is it
Code change:
<ins> #[derive(PartialEq, Eq)] pub struct Tag(pub Context, pub u16); #[derive(PartialEq, Eq)] pub enum Context { Tiff, Exif, } impl Tag { const ExifIFDPointer: Tag = Tag(Context::Tiff, 34665); } fn main() { match Tag::ExifIFDPointer { //~^ ERROR: non-exhaustive patterns: `Tag(Exif, _)` not covered Tag::ExifIFDPointer => {} } } </ins>

Related discussion:
text: I hope this is not already known, but my searching has not turned up anything. Compiling a rust binary with the dependency panices in nightly. How to reproduce: a new rust binary. to dependencies in This gives the following output It compiles on stable and beta. Edit: Just running in gives the same result.
Tried a few different nightlies. And it looks like it broke sometime between and
I have managed to get a much smaller example. Compiling this on nightly gives the above panic:
Looks like it's fixed in the newest nightly ()
Bisecting between ... gives as the regression PR.
Code change:
expanded_cache: FxHashMap<(DefId, SubstsRef<'tcx>), Ty<'tcx>>, primary_def_id: Option<DefId>, found_recursion: bool, <ins> found_any_recursion: bool, </ins> /// Whether or not to check for recursive opaque types. /// This is `true` when we're explicitly checking for opaque type /// recursion, and 'false' otherwise to avoid unnecessary work.

Related discussion:
text: I tried this code: I expected running to produce an error like: It does, but takes time exponential in the number of calls, although doesn't appear to use any extra memory. In the time take looks like: I believe it's also exponential in the number of calls in . The reason I had code like this was because I was using nom's parser combinators which results in lots of nested closures. I spotted it because this caused rust-analyzer to hang because cargo clippy hung (it looks like check was the issue), I had to kill clippy to fix it. I bisected this (with cargo-bisect-rustc) to find the regression in , which contained the following bors commits: merge of - Centril:rollup-rzvry15, r=Centril merge of - tmandry:rollup-0k6jiik, r=tmandry merge of - Manishearth:clippyup, r=Manishearth merge of - tanriol:explain_borrow-use-context-dominators, r=nagisa merge of - ehuss:update-cargo-books, r=alexcrichton modify labels: +regression-from-stable-to-stable -regression-untriaged
what version of rust are you using? Is this also present on nightly?
Good question! This repros on the latest nightly () and on stable (1.53.0 2021-06-17).
Regression means that it was linear, or exponential, but smaller?
I didn't looks to still be exponential just much quicker, and with a smaller base (~2 vs ~14):
looks related
Bisected to innocent-looking commit . Removing the caching from in master does indeed fix the issue. I haven't looked at the how or why or where that causes (other) problems though. cc
Hmm, the only thing that looks expensive there is the hashing - I wonder if it's hashing over and over again without ever getting a cache hit? Hashing has a fixed cost, but can be an arbitrary length:
cuts down on time for this testcase and others with invalid recursive opaque types by bailing out early if a recursion is found.
Code change:
expanded_cache: FxHashMap<(DefId, SubstsRef<'tcx>), Ty<'tcx>>, primary_def_id: Option<DefId>, found_recursion: bool, <ins> found_any_recursion: bool, </ins> /// Whether or not to check for recursive opaque types. /// This is `true` when we're explicitly checking for opaque type /// recursion, and 'false' otherwise to avoid unnecessary work.

Related discussion:
text: This fixes the regression but the check time is still exponential in the recursion: #wraps|time (s) ---|--- 23|9.2 24|18.3 25|36.6 Not sure if that matters in practice though.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
That's the same as before the regression, right? I definitely think that's a change worth making :) I expect the doubling will have a completely different cause.
Yes, same ballpark.
Code change:
let _ = make_vec![a 1, a 2, a 3]; } // --- Minified Issue --- // macro_rules! m { <del> ( $()* ) => {} </del> <ins> ( $()* ) => {}; </ins> //~^ ERROR repetition matches empty token tree }

Related discussion:
text: The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened
Code change:
fn main() { let mut s = S { f: 0, sub: Sub { f: 0 } }; field_write(&mut s); <ins> auto_deref(); nested_boxes(); } fn auto_deref() { struct E { x: bool, y: bool, //~ ERROR: field is never read } struct P<'a> { e: &'a mut E } impl P<'_> { fn f(&mut self) { self.e.x = true; self.e.y = true; } } let mut e = E { x: false, y: false }; let mut p = P { e: &mut e }; p.f(); assert!(e.x); } fn nested_boxes() { struct A { b: Box<B>, } struct B { c: Box<C>, } struct C { u: u32, //~ ERROR: field is never read v: u32, //~ ERROR: field is never read } let mut a = A { b: Box::new(B { c: Box::new(C { u: 0, v: 0 }), }), }; a.b.c.v = 10; a.b.c = Box::new(C { u: 1, v: 2 }); </ins> }

Related discussion:
text: <!-- 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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.
Code change:
} #[test] <del> #[cfg_attr(any(target_os = "vxworks", target_os = "android"), ignore)] </del> <ins> #[cfg_attr(any(target_os = "vxworks"), ignore)] </ins> fn test_process_status() { let mut status = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 1"]).status().unwrap() } else { <del> Command::new("false").status().unwrap() </del> <ins> shell_cmd().arg("-c").arg("false").status().unwrap() </ins> }; assert!(status.code() == Some(1)); status = if cfg!(target_os = "windows") { Command::new("cmd").args(&["/C", "exit 0"]).status().unwrap() } else { <del> Command::new("true").status().unwrap() </del> <ins> shell_cmd().arg("-c").arg("true").status().unwrap() </ins> }; assert!(status.success()); }

Related discussion:
text: To enable test on android bot and test/run-pass/rtio- It looks to me RtioProcess does not work properly on android.
logs are
Hm this may be an FFI issue with libuv. I realized during my uv rewrite that libuv is giving us an int64t exit status and we think it's a cint. Once lands this may be fixed.
Hmm, this issue number has propagated to several more tests that are cfg-disabled on android. (Some of which are now failing when I mixed in a Boehm/BDW conservative GC into the runtime, in particular .)
Also, has landed, so it would be good to determine if these tests now work on Android.
Triage: I have no idea how to test this, but a lot has changed in a year (especially the removal of green & libuv), so these may be magically fixed; if someone can check.
Triage: is gone, but all these tests in are still ignored for android.
I tried to run these tests with but they all failed with , which seems suspect (at least for the tests that invoke , , , etc.). Is there a better way to test? I have an android device available.
Code change:
Some(t) if t.hir_owner == parent_id => t, _ => self.tcx.typeck(parent_id), }; <del> let ty = typeck_results.expr_ty_adjusted(expr); let span = expr.peel_blocks().span; </del> <ins> let expr = expr.peel_blocks(); let ty = typeck_results.expr_ty_adjusted_opt(expr).unwrap_or(tcx.ty_error()); let span = expr.span; </ins> if Some(span) != err.span.primary_span() { err.span_label( span, <del> &if ty.references_error() { </del> <ins> if ty.references_error() { </ins> String::new() } else { format!("this tail expression is of type `{:?}`", ty)

Related discussion:
text: I tried this code: searched nightlies: from nightly-2022-08-18 to nightly-2022-09-09 regressed nightly: nightly-2022-08-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- 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-{channel} -regression-untriaged --
Regression introduced in:
This block around is crucial to trigger the ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
"create_substs_for_associated_item(span: {:?}, item_def_id: {:?}, item_segment: {:?}", span, item_def_id, item_segment ); <del> self.create_substs_for_ast_path( </del> <ins> let (args, _) = self.create_substs_for_ast_path( </ins> span, item_def_id, parent_substs,

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
#![feature(macro_reexport)] #![feature(macro_vis_matcher)] #![feature(needs_panic_runtime)] <del> #![feature(needs_drop)] </del> #![feature(never_type)] #![feature(num_bits_bytes)] #![feature(old_wrapping)]

Related discussion:
text: About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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 is now complete.
Code change:
<ins> error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:6:34 | LL |     let _: u32 = 5i32.try_into::<32>().unwrap(); |                                  ^^ unexpected const argument error[E0599]: no method named `f` found for type `S` in the current scope --> $DIR/invalid-const-arg-for-type-param.rs:7:7 | LL | struct S; | --------- method `f` not found for this ... LL |     S.f::<0>(); |       ^ error[E0107]: wrong number of const arguments: expected 0, found 1 --> $DIR/invalid-const-arg-for-type-param.rs:8:9 | LL |     S::<0>; |         ^ unexpected const argument error: aborting due to 3 previous errors Some errors have detailed explanations: E0107, E0599. For more information about an error, try `rustc --explain E0107`. </ins>

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
<ins> pub trait Example { fn query<Q>(self, q: Q); } impl Example for i32 { fn query<Q>(self, _: Q) { unimplemented!() } } mod nested { use super::Example; fn example() { 1.query::<dyn ToString>("") //~^ ERROR the size for values of type `dyn ToString` cannot be known at compilation time //~| ERROR mismatched types } } fn main() {} </ins>

Related discussion:
text: Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.