You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current mappings decoding spec ignores mappings where the resulting "generatedColumn" is negative (see step 4.c. in DecodeMappings.
This matches the firefox WASM implementation which throws and aborts mappings parsing when encountering negative numbers.
sourcemap-codec and Chrome DevTools however keep going and emit a mapping. More importantly they update the "original" state.
Also note that sourcemap-codec and Chrome DevTools actually allow for negative original line/column numbers.
Should we align the spec here? If we want the spec to match all three implementations we'd need to keep the "optionally report an error" checks that we already have, but not force negative numbers to null and also emit a mapping even if generatedColumn is negative.
The text was updated successfully, but these errors were encountered:
The current mappings decoding spec ignores mappings where the resulting "generatedColumn" is negative (see step 4.c. in DecodeMappings.
This matches the firefox WASM implementation which throws and aborts mappings parsing when encountering negative numbers.
sourcemap-codec and Chrome DevTools however keep going and emit a mapping. More importantly they update the "original" state.
Also note that sourcemap-codec and Chrome DevTools actually allow for negative original line/column numbers.
Should we align the spec here? If we want the spec to match all three implementations we'd need to keep the "optionally report an error" checks that we already have, but not force negative numbers to null and also emit a mapping even if generatedColumn is negative.
The text was updated successfully, but these errors were encountered: