wasmparser: validate versionsuffix compatibility-track prefix

[RuchitRathi]

The InterfaceName::version() method previously accepted any versionsuffix string as long as prefix + suffix produced a valid semver string. It did not check that the prefix embedded in the interface name matched the canonical compatibility-track string for the assembled version.

For example, a name like a:b/c@1.0 with (versionsuffix ".1") assembles to 1.0.1, whose track prefix is "1" -- but the embedded prefix is "1.0". That mismatch was silently accepted, contrary to the component model spec.

This commit resolves the FIXME comment by:

• Adding a semver_track_prefix() helper that mirrors the logic in wit_parser::PackageName::version_compat_track_string:

  • pre-release: full major.minor.patch-pre string
  • major != 0: just major
  • major == 0, minor != 0: 0.minor
  • major == minor == 0: full 0.0.patch

• Updating InterfaceName::version() to verify the prefix in the name equals the expected track prefix after the version is assembled.

• Changing the return type from Result<_, semver::Error> to crate::Result<_> so a descriptive error can be returned.

• Adding unit tests in names.rs covering valid tracks, each invalid track-prefix mismatch shape, and the helper directly.

• Adding three new assert_invalid cases to tests/cli/component-model/canon-names.wast exercising @1.0, @0.0, and @2.0 prefix mismatches.

Fixes the deferred FIXME noted in the source.

[alexcrichton]

Thanks! One thing I'd ideally like to explore here is a more efficient implementation which doesn't involve lots of string formatting and string allocations. I believe that can be done because the prefix/suffix are already validated to be a valid semver, so I think more-or-less the number of periods just needs to be checked in the prefix? (or something like that)

[RuchitRathi]

Thanks! One thing I'd ideally like to explore here is a more efficient implementation which doesn't involve lots of string formatting and string allocations. I believe that can be done because the prefix/suffix are already validated to be a valid semver, so I think more-or-less the number of periods just needs to be checked in the prefix? (or something like that)

Thanks for the feedback! I agree that the current approach can be made more efficient. Since the prefix and suffix have already been validated as valid semver components, I’ll look into avoiding the intermediate string formatting and allocations and instead rely on the structure of the validated version, such as checking the relevant period count directly. I’ll update the implementation and add/adjust tests to ensure the behavior remains unchanged.