Hi @Alex Crichton et al -- quick note that wasmparser 0.63.1 is potentially an issue for Firefox as it changes error messages slightly, but is semver-compatible with cranelift-codegen's "0.63" dep; so when we develop locally (not against the wasmparser version that is vendored into the mozilla-central repo) we have non-passing tests that pass otherwise
Could we have a policy of semver-bumping when we change error messages?
oh hm, so typically semver-bumps are generally about APIs as in "your code keeps compiling and probably keeps working"
"keeps working" is sorta vague, though, and typically things like error messages don't fall under that category
if it's causing issues though I can yank it and publish as 0.64.0
ideally making error messages better though wouldn't cause too much process to get engaged
I don't think a yank is necessary, probably, it'll just need some updating in the tests next time someone vendors Cranelift
(... which may be me, today or tomorrow)
in any case I don't want SM to be a drag on improving error messages :-) ideally if things are somewhat stable then this will mostly be a non-issue. And longer-term we should find a better strategy for asserting specific errors
in build.rs
-generated tests we only check that the spec test expected error messages are a prefix of the actual error messages, so we have some wiggle room. is SM testing full messages? is there a way we could relax it a bit like we do in build.rs
?
Yep, it's matching on full messages, or at least more of the text than the prefix (e.g., it wants to assert specific types in type-mismatch messages)
I suppose it could be relaxed, but that's more of a question for Lars over in SpiderMonkey-land (we can certainly bring it up!)
yeah it's a trade off
Last updated: Dec 23 2024 at 13:07 UTC