Stream: t-compiler/rust-analyzer

Topic: Shortening inline hints

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

For shortening inline type hints, I'd hoped to transform the type a bit to change long parts to _ or ... or similar.
Is it better to replace those parts with some dummy types that print the right thing, or is it possible to display just parts of the type without re-implementing the whole formatting part?

Daniel Mcnab (Oct 10 2019 at 13:32, on Zulip):

I guess the formatting part could be refactored to take an optional depth parameter? Maybe using unlimited depth for when you hover over the declaration, but inline hints and hovering over uses could be limited too

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

Good question! I don't know the right answer :)

I think we need some of general formatting infra with knobs in ra_hir, and use it for both HirDispaly and type hints. Basically, what @Daniel Mcnab suggesting

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):


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: Jul 26 2021 at 12:15UTC