Back

@predrag is their an issue/zulip for this? i have thaughts, but would rather put them somewhere that the rest of T-rustdoc can see.

@aDot there's the linked issue in the Rust repo in the post above (with some discussion already), but there's no Zulip. I'm happy with either -- whatever works best for T-rustdoc is fine by me.

@predrag @aDot it'd be nice to expand the logic that detects sealed traits on trait bound errors (which customizes whether we tell users to implement a trait or use a type that already implements it)

@ekuber @aDot hoping we can feed two birds with one scone here

@predrag @ekuber not sure this is a good idea, as diagnostics can use heuristics to offer progressive enhancements, and if those heuristics don't fire when they should, it's not the end of the world.
The heuristics can still be improved, but it's better than nothing.

Rustdoc JSON instead need to meet the much higher bar of "never wrong" (although their are a few places we're not their). I'd much rather not ship a field, than ship a field with heuristics that's sometimes wrong

@aDot @ekuber I agree.

I was hoping for the opposite direction: if we get it exactly correct for rustdoc, we hopefully can reuse a lot of the same analysis to offer better diagnostics.

I agree that the opposite direction isn't necessarily synergistic.

@predrag @ekuber With a rustdoc hat on, I'm not sure it's a think i want to try to nail down precisely. Their's no language-level definition of what it means for a trait to be sealed (like their is for object safe). Instead it's a load of emergent behaviors. Is their a reason CSC can't calculate the emergent behaviours from what's in JSON today?

It's also possible that i'm just thinking "This is a hard problem, I think it should be lang/compiler/CSC's job", which isn't super helpful

@aDot @ekuber I tried to do it in c-s-c several times and bounced off each time.

It's possible that rustdoc can ship components of the analysis instead of the end result, but that has its own issues.

For one, it would require always documenting private and hidden fields, which c-s-c already does.

Another issue is that it would require figuring out whether values of a pub-in-priv type can possibly be obtained in any way via public API -- which I expect to be *very hard* without compiler infra.

@aDot @ekuber happy to pair program it over rustdoc json with you sometime if you'd like.

Seeing first hand is always better than reading someone else's explanation :) And maybe I've missed an easier way to do it, who knows.

@predrag @ekuber let's find a time, that would probably be enlightening for both of us.

wrt doing this on the rustdoc side, even with a TyCtxt, i think "is this type construable with the public API" (or more realistically, "is this type meant to be construable", given transmute+friends), is still a hard to unanswerable problem, that involves making judgement calls.

Eg

```rust
mod priv {pub struct PubPriv};

#[doc(hidden)]
pub fn obtain() -> priv::PubPriv;

#[macro_export]
/// Obtain the PubPriv.
macro_rules obtain! {
() => {$crate::obtain()}
}
```

I have no idea how'd you'd try to decide weather you can obtain a `PubPriv` here even with a TyCtxt (or even the broader choise of what's the right answer here).

That said, rdj could definatly do more for you, by exposing the EffectiveVisibilty analysis, instead of (presumably) having to force you to implement it yourself. OTOH, I'm worried this might lead to over-fit to the current compiler internals.

@predrag @aDot just in case it is useful:

- https://github.com/rust-lang/rust/pull/112686/files
- https://github.com/rust-lang/rust/pull/116945/files