Extended name section tests

[bvisness]

And really for the name section generally. These do not pass yet but hopefully this will be sufficient for phase 3.

[rossberg]

This looks great! You could throw in a few more negative tests that put @name in wrong places (esp before the bound identifier, before the keyword, after an export clause, or random places inside declarations).

[alexcrichton]

Question for tests like these: should a new assert_* directive be added for this? By default even with an invalid name section (e.g. all \ff bytes) these tests in theory should still pass because validators (I thought at least) shouldn't be validating the contents of custom sections by default.

In lieu of that, should a new directive like assert_valid_custom be added for tests like these?

[bvisness]

Hm, good question. It feels a bit overkill to me when you can just ensure that your test runner reports known but ill-formed custom sections as errors or warnings somehow. But it would more explicitly signal intent. I guess I will leave that decision to @rossberg.

[bvisness]

Alex mentioned here that an assert_valid_custom directive could be useful for signaling engines to avoid round-trip tests. That seems like a pretty good use case to me.

[rossberg]

When Yuri and I discussed this in the context of the branch hinting proposal, IIRC the conclusion was that it's unclear how assert_valid_custom would differ from just giving the module — engines are free to not implement individual custom sections, so they cannot be forced to actually check this. OTOH, implementations may want to provide a way to control which custom sections to recognise (that's what the reference interpreter does), but then the assertion still doesn't add any expressiveness AFAICS.

Even if the custom section doesn't round-trip, I don't understand why that would be an issue for tests like the above. Won't they still succeed just fine with the custom section removed? Sure, it doesn't check much, but no harm done. The only place where round-tripping may fall over is for negative tests on custom section, but we already have assert_invalid_custom to express those cases.

(Aside: That said, tools that implement a custom section should also handle its round-tripping. That's why we introduced annotations in the text format. Ideally, every custom section should define appropriate annotation syntax. If it doesn't, it usually should be possible to fall back to the generic @custom annotation, though this fails for ill-designed custom formats that use binary byte offsets instead of AST-level counts, since those aren't robust. Such custom formats should definitely define a text format.)