Stream: t-compiler/wg-rls-2.0

Topic: Shortening inline hints


detrumi (Oct 10 2019 at 13:35, on Zulip):

Type hints use the HirDisplay trait, so it makes sense to extend that then, yeah

matklad (Oct 10 2019 at 13:36, on Zulip):

@detrumi I had something different in mind. I think extending HirDisplay would put complexity in the wrong place.

Rather, we should extend only Ty display, but implmenet <Ty as HirDisplay> in terms of that new infra

matklad (Oct 10 2019 at 13:37, on Zulip):

basically

fn display_ty(ty: &Ty, knobs: Kbobs) -> Stirng { ... }

impl HirDispaly for Ty {
    fn fmt(&self) {  display_ty(self, Knobs::default()) }
}
detrumi (Oct 10 2019 at 13:37, on Zulip):

Oooh, that's nice

Florian Diebold (Oct 10 2019 at 13:54, on Zulip):

Well... extending only Ty display would mean the knobs would get lost e.g. in impl Trait<SomeType>

matklad (Oct 10 2019 at 13:55, on Zulip):

=/

Florian Diebold (Oct 10 2019 at 13:55, on Zulip):

unless you mean completely building a parallel displaying infrastructure that allows the knobs

Florian Diebold (Oct 10 2019 at 13:55, on Zulip):

then we could just implement HirDisplay for that

Florian Diebold (Oct 10 2019 at 13:56, on Zulip):

I think we need something like that

matklad (Oct 10 2019 at 14:05, on Zulip):

Might be a good idea to check what itellij is doing

detrumi (Oct 10 2019 at 14:19, on Zulip):

Looks they're building a collapsible structure based on the depth

detrumi (Oct 10 2019 at 14:20, on Zulip):

Or levels, with some logic for checking sizes

matklad (Oct 10 2019 at 14:20, on Zulip):

Oooh, right, the don't render directly to string....

I wonder if we should actually do the same? Produce a tree, with a hints like "you can collapse this node", and let the client handle getting the actual string

detrumi (Oct 10 2019 at 14:24, on Zulip):

We could, though it would complicate the client somewhat

detrumi (Oct 10 2019 at 14:25, on Zulip):

Unless we let clients choose between string or tree representation

matklad (Oct 10 2019 at 14:25, on Zulip):

That's true.... Yeah, I think, as a first cut, we really should just be sending strings to the editor. But it makes sense to keep a more powerful impl in mind while implementhig this

Florian Diebold (Oct 10 2019 at 16:02, on Zulip):

Yeah, I think building some tree structure and handling the presentation/collapsing stuff etc. as a second step is actually a good approach

Florian Diebold (Oct 10 2019 at 16:02, on Zulip):

:thinking: maybe that tree structure is just a syntax tree again?

detrumi (Oct 11 2019 at 13:48, on Zulip):

Ideally we'd create some indirection in the hir_fmt functions, so that they don't call hir_fmt on children directly. Maybe change ty.hir_fmt(f) to something like f.fmt(ty), where a different formatter can handle the level logic?

Last update: Nov 12 2019 at 16:50UTC