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?

detrumi (Nov 18 2019 at 13:20, on Zulip):

So I've been experimenting a bit on this, and there's a few ways to go here:
1) The simplest is to still write directly to string, but add some knobs (just a folding level in the simplest case). This is fairly easy to add to HirDisplayWrapper, this WIP branch shows an example
2A) Changing HirDisplay so that it returns an intermediate tree representation that tracks which parts can be collapsed, so we can use a single HirDisplay implementation for both type hints and normal Display impls. I've got a very WIP branch that shows the idea. The main downside of this approach is that the HirDisplay impl's get more complex because they need to decide what's collapsible and such
2B) Create new infrastructure for showing type hints that's separate from HirDisplay. This is what intellij is doing. The main downside of course is that we duplicate the formatting implementations, and we won't be able to send the tree representation to the client

detrumi (Nov 19 2019 at 09:51, on Zulip):

Ah, seems like kiljacken had more success implementing a solution, nice

Last update: May 26 2020 at 11:10UTC