add cargo config jsonschema support for editor auto completion and docs jumping

[loynoir]

What does this PR try to resolve?

There is not yet editor hint and completion support for .cargo/config.toml.

So I impl it.

Related

• Publish .cargo/config.toml jsonschema to schemastore.org for editor  #12883

• [feat] .cargo/config.toml SchemaStore/schemastore#3349

Goals

[x] vscode tab completion on key

[x] vscode tab completion on value candidates

[x] vscode err hint when invalid key/value

[x] vscode hint on document url

How should we test and review this PR?

Review schema/cargo-config.schema.d.mts.

The jsonschema is generate from typescript using npm:typescript-json-schema@0.65.1.

Try genereated jsonschema using any supported editor toml extension.

        "evenBetterToml.schema.associations": {
            "^.*/\\.cargo/config\\.toml$": "https://raw.githubusercontent.com/loynoir/cargo/feat-json-schema-for-editor/schema/cargo-config.schema.json",

Additional information

As result, you can see the output jsonschema is very large.

Not able to let human write it.

So I generate it from typescript dts.

Maybe someone can impl macro rules to generate jsonschema, website docs and cli parser at the same time in the future.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[epage]

Generally we use cargo xtasks for automating things in the repo with a CI check to ensure that the generator and the output haven't drifted (make the generator was run, avoid hand-edits). This also duplicates information in an out-of-the-way place (currently in source and in our own documentation).

Also, I'm unsure what the implications are of us having incomplete or wrong information for targets since a straight combination of arch, sub, vendor, sys, and abi are being used. We might want to just leave that as a string.

I wonder if we could use schemars or something like would be a good way to single-source this information. Maybe then we could also code-generate some of our documentation from it as well.

If you go down this route, I'd recommend playing with this for Cargo.toml first in crates/cargo-util-schemas. We could have an unstable-schemagen feature and the xtask could enable it and get the schema and dump it. If/when we get that settled, we could work to move the config schemas to cargo-util-schemas and under unstable-schemagen have a top-level TomlConfig struct.