Description
in PRs #19827, #21001, and #21214 we use the concept of a .tastycheck file to validate the exact format of tasty. This testing method was introduced because without it there was no testing method to validate precisely what TASTy is produced. - for example to identify which trees get generated or elided, or which source paths exist.
Unfortunately it's likely to be brittle - already test files are fragile to changes in type inference - so that must be avoided - and we already elide machine/config specific information such as source files, compiler version and uuid in the tasty header.
So we should either make it more customisable so that only a specific section of TASTy gets rendered, or perhaps develop a new DSL that can perhaps assert the absence of information, rather than enforcing stability of detail that is otherwise noise in a check file.