Explicit package declarations should require root package declaration

[macovedj]

Recently, support for explicit package declarations was added to wit, enabling multiple package declarations in a single wit file. This PR proposes that using this new syntax should still require a "root" package declaration.

Today, mixing declarations below isn't yet supported. This PR proposes that it not only be supported, but required, though just as today, the top level declaration could appear in another file in a wit project directory.

package root:package;

package first:explicit {
  ...
}

package second:explicit {
  ...
}

With this requirement, we can retain the concept of the package that is defined by a wit project, while also being able to define multiple packages in a single project.

[alexcrichton]

Personally I'm in favor of this change in talking with @macovedj. It's been difficult to rationalize how tooling should be updated when the "thing you just parsed" returns a list of packages when there should probably just be a "main package" somewhere in there. I think that this change returns us back to that original state of having a "main package" at all times but we still have all the benefits of inline curly-braced package blocks for ease of use, reading, single-file storage, etc.

Rolling this change out will be a little weird on the wasm-tools side of things but I'm hoping that the usage of multi-package forms hasn't spread too too much.

Also cc @azaslavsky since you worked on the package .. { ... } forms as well

[lukewagner]

This makes sense to me too, thanks for working through this.

[azaslavsky]

I'm generally on board with this change. Is there a companion PR with the implementation in the main wasm-tools repository? The reason I ask is that some tooling for producing WIT, like the pretty printer, might struggle to decide what the "main" package is when printing some set of packages for view. So we'd want to either provide a means to specify that, or else loosen the "must have a root" rule in such cases. Also, today we have users specify their "main" package on the command line when using the all-explicit mode, which should probably be deprecated, lest it collide with this new canonical method of "main" specification.

I suspect there are other similar tricky bits, so it would be good to have a working implementation to work out these corner cases alongside this spec change.

[macovedj]

I'm generally on board with this change. Is there a companion PR with the implementation in the main wasm-tools repository?

Been noodling on it. Hoping I can have something up for you to follow this coming week.

[alexcrichton]

My hope is to definitely deprecate/remove the current "set of packages" input where it's just a bunch of package ... { ... } blocks in favor of this feature of "must have a top-level package ...; to explicitly indicate what the main package is. That'll hopefully simplify the various tooling pieces where everything is still working with a single world/package at a time rather than a set

[macovedj]

Is there a companion PR with the implementation in the main wasm-tools repository?

Still working through some of the tests and tidying up a bit, but figured I'd put it up here so you could get a feel for the changes

[alexcrichton]

Ok I believe that the implementation at bytecodealliance/wasm-tools#1700 is good to go now. It's somewhat urgent to get that out because the C# bindings generator was about to start relying on multi-package output in a way that is incompatible with this proposal. I'd like to head that off and avoid any workaround/compat bits by only having in-the-wild C# things use this new format of package-at-the-top and optionally-nested-packages-afterwards