[display] @:deprecated typedefs in completion

[Gama11]

It's rather annoying to have the now deprecated types (#7390) show up in completion, and before the ones you're meant to use:

I think there's no reason to show @:deprecated typedefs in completion at all? At least as long as they're just simple aliases, typedefs to anon structs should probably still be shown. I think there's already some detection for the difference for nicer auto-generated deprecation messages.

[EricBishton]

Filter this in vsHaxe or vsCode, not the compiler. IDEs should be able to make their own decisions.

[Gama11]

I guess that might be preferable. But in either case something needs to change in the compiler, because the protocol currently doesn't seem to include metadata for types (even though the data structure has a meta field).

It looks like metas are only sent during resolve right now, and they're rather heavy since they include a pos for some reason..

[EricBishton]

I agree the metadata should be included in the protocol response. A flag set for common metadata would be Ok, if we want something lightweight. (Still need all of the metadata to be present, though.)

[Gama11]

The thing I'm concerned about is this pos stuff, which seems rather useless in this context:

We probably don't even need that during resolve requests.

[EricBishton]

We could use a file dictionary to remove the duplicate — very long — names.

[Gama11]

I don't think we need the positions of the metadata at all. There's already a position on the type.

[EricBishton]

That may be true for this use case. The question becomes whether the code that puts out the metadata is common and the position is required for (an)other use case(s). For instance, Is this code part of the compiler trying to expose full fidelity parsed data?

Or, is it, perhaps, trying to give ordering of the metadata so that an IDE can re-order based upon the user's/IDE's rules?

[Simn]

Never thought I'd see the day where @Gama11 wants less positions in the display output...

[RealyUniqueName]

What about an opt-in argument for display requests to add meta positions. By default, metadata won't contain pos infos.

[Gama11]

As I said, I don't think there's any point to including these positions at all, so a flag seems like overengineering. A list of metas to include in responses might make sense though, to reduce bandwidth if we only look at e.g. :deprecated anyway.

[ncannasse]

I agree @:deprecated should imply @:noCompletion, on both types and fields. No flag required.

[RealyUniqueName]

I agree @:deprecated should imply @:noCompletion, on both types and fields. No flag required.

That means the decision about hiding it from completion would be made by the compiler. While the original issue (and I agree with it) suggested to let IDE decide whether a type should be listed in completion.

[Gama11]

Well, originally I suggested hiding it compiler-side, but then @EricBishton complained. :) It would be pretty consistent with what's done with @:noCompletion already though (the compiler makes the decision there, as it should so that lib authors can rely on it / some editor doesn't decide to show it anyway).

[RealyUniqueName]

I have no strong opinion on that. It just feels right to make this decision on IDE side.
@:noCompletion is a different story - it denotes a user explicitly wants to hide something from completion, while @:deprecated is not about completion at all. If that was a case one could manually add @:noCompletion.