rustdoc-json: replace jsondocck with jsondocckng

[aDotInTheVoid]

We want to use https://github.com/aDotInTheVoid/jsondocckng which allows writing the tests in a seperate rust files, instread of the current jsondocck and check_missing_items.py

Reasons to do this

• Easier for new contributors: They don't need to learn how to use JsonPath and @set... commands
• Easier for exising contributors: Common idioms ("$.index[*][?(@.name=='...')]) can be converted to rust code to avoid duplication. Paths referenced repeatedly can be replaced with a let
• We can avoid the problems with quoting of the shlex/serde_json frankensteined value system that leads to things like '"\"vectorcall\""'

Drawbacks

• We dont test the raw json, but instead the Rust Repr
• Unclear how to integrate into rustbuild in current from
• Existing tests need to be rewritten

Todo

• Improve features of jsondocckng
  • Allow multifile crates
  • Allow passing args to rustdoc
  • Allow multiple json outputs
  • When failure occours, diff with nightly and prity print
• Integrate with rustbuild
• Port existing tests
• Document

@rustbot modify labels: +A-contributor-roadblock +A-testsuite +T-rustdoc +A-rustdoc-json +A-rustbuild

[aDotInTheVoid]

2 Possible approaches for this:

1 Crate per test

Each test is its own crate (in addition to the crate being documented). Rustbuild documents the <name>.rs file, compiles <name>_test.rs to a binary, and then calls generated binary with a path the the json. Their is a library crate that each test depends on that provides common test utilitys, and a main method that reads the json file, and then calls the test crates test function.

More concretely

foo.rs

pub fn foo() {}

foo_test.rs

use jsondocck::{TCrate, main_test}

fn main() {main_test(test);}

fn test(t: TCrate) {
   let foo = t.get_root::<Function>("foo");
   assert_eq!(foo.decl.output, None);
}

One crate for all tests

All tests live in the same (binary) crate. rustbuild the test document and builds the one test crate, and then calls the test crate binary with the name of the test to run and the path to json. The test crate has the all the test functions within it, and calls the appropried one based on the name of the test passed on the command line

This feels simpler to impement, but may lead to a slower feedback loop, as the whole test crate needs to be recompilled whenever the contents of a single test is changed.

I'm not sure which direction to go here, and would realy apprciate input

[CraftSpider]

Personally, 1 sounds better. I like the idea of one crate per test, with a helper they all rely on. On the other hand I agree it may be a little more complex.

[aDotInTheVoid]

After some zulip discussion with @_Mark-Simulacrum, it looks like one-crate-per-test is infeasable, because compiletest can't build crates that have crates.io dependencys (needed for serde_json).

Additionaly this looks alot like #40713

[aDotInTheVoid]

Started work at https://github.com/aDotInTheVoid/rust/tree/jsondocck-ng

[aDotInTheVoid]

It might be worth just rewriting src/etc/check_missing_items.py to start with, as that should fit nicely into rustbuild, and it's out of sync whenever the format changes (and even when it doesn't due to undertesting). Eg

pub type RefFn<'a> = &'a dyn for<'b> Fn(&'a i32) -> i32;

fails it.

Theirs a very barebones implementation here.