Include more types in crystal tool hierarchy

[nobodywasishere]

Feature Request

crystal tool hierarchy is really useful for getting an overview of the classes/structs available. I currently have a refactor branch of the vscode extension that uses it to quickly allow autocomplete of classes/structs.

It would be useful if it included modules/enums/annotations in its output, something as simple as:

{
  "name": "MyModule",
  "kind": "module"
},
{
  "name": "MyModule::MyAnnotation",
  "kind": "annotation"
},
{
  "name": "MyModule::MyEnum",
  "kind": "enum",
  "values": [
    "MyModule::MyEnum::Value1",
    "MyModule::MyEnum::Value2",
    "MyModule::MyEnum::Value3"
  ]
}

[nobodywasishere]

Actually, I'm not sure how these would fit into this as modules/enums/etc don't inherit from a generic Object class. Maybe instead we could have a crystal tool namespace command that outputs information about every NamedType? Thoughts?

[straight-shoota]

Yeah I suppose a separate tool might be better for this.

[nobodywasishere]

Put together what I'm looking for here, let me know if this idea is PR worthy: https://github.com/nobodywasishere/crystal/tree/nobody/namespaces-tool

Resisted the urge to add docs to the output haha. Honestly maybe the move is to just add a crystal tool dump_ast command that has params like --wants-doc/--no-cleanup/--top-level/etc, so other tooling can just accept that and use that, instead of needing bespoke cli tools for everything. Would go in-hand with #14705, as we'd need a way to serialize the AST to/from disk.

[straight-shoota]

For this use case you don't need the full AST (compared to other tools which trace method calls, for example). It's just a very high-level view of the outline. So I don't think this is related to #14705.

Actually, you can pull out the information about (documented) namespaces from index.json from the doc generator.
Improvements to the data format would help improcing this, and of course decoupling the raw data from HTML generation (#6947 and https://forum.crystal-lang.org/t/the-weight-of-compiler-tools/6888).

[nobodywasishere]

This use-case no, but for general use-cases to be able to have tools not built with the compiler that can work with the AST is moreso what I meant.

[nobodywasishere]

Good point with the docs index.json though, I'll look into trying to use that.

[nobodywasishere]

Unfortunately the index.json only includes stuff in the ./src directory by default, whereas I'd want everything available in the entire namespace (./lib, stdlib, and c lib bindings).

[straight-shoota]

That could be easily changed with a flag though.

Why did you close this? I think this it's worth pursuing a solution.

[nobodywasishere]

My thought was this issue, if it just became adding more output to the docs json generator, would be duplicates of #7904 and #6721, and should be handled in those issues (treating the docs json output as a serialization of a top-level analysis)