Define decoding algorithms for source maps #119
Conversation
This PR introduces "decoded source map" data structures, which are internal spec representations of the information encoded in source maps. It also defines algorithms to decode source maps from either a JSON string or [infra](https://infra.spec.whatwg.org/) representation. The goal is: - use them to explicitly write down all the possible error cases - use them as a starting point to define new data structures, for example for the scopes proposal - eventually add algorithms such as "get the original location given a decoded source map and a generated location". This PR also explicitly defines sources/sourceRoot resolution in terms of the [WHATWG URL](https://url.spec.whatwg.org/) spec.
nicolo-ribaudo
force-pushed
the
wip-decoding-algorithms
branch
from
232723b to
41fa6a6
Compare
|
PR updated to return i32::min for B, as discussed in the meeting last week. |
| 1. Else, set |decodedSource|'s [=decoded source/URL=] to |sourceURL|. | ||
| 1. If |index| is in |ignoredSources|, set |decodedSource|'s [=decoded source/ignored=] to true. | ||
| 1. If |sourcesContent|'s [=list/size=] is greater than or equal to |index|, set | ||
| |decodedSource|'s [=decoded source/content=] to |sourcesContent|[|index|]. |
There was a problem hiding this comment.
The handling of sourcesContent here seems like a natural way to spec it, but when you have duplicate entries it currently conflicts with what implementations actually do. (see this issue for more details) In particular, it seems all the major browsers treat sources entries as being set-like so that duplicate source URLs point to the same sourcesContent (either the first or last one for that particular URL).
|
@takikawa Given that two of the main debuggers behave one way and two another, I added a note saying that although we support source maps with multiple contents for the same URL, if a debuger does not support showing it they will probably just pick one of the contents in an implementation-defined way. I am not sure that describing the expected behavior in this case is a problem that we necessarily have to figure out, because the same problem can happen also when not using source maps (https://issues.chromium.org/issues/361652150). At most we could say that source maps cannot have duplicate file URLs, but we cannot ban two different source maps from introducing the same original file with two different contents anyway. |
source-map.bs
Outdated
| 1. If |relativeSourceIndex| is not null, [=optionally report an error=]. | ||
| 1. Continue with the next iteration. | ||
| <!-- TODO: If there is a relativeSourceIndex but not a relativeOriginalLine, | ||
| should |sourceIndex| still be increased? --> |
There was a problem hiding this comment.
I think this TODO can be deleted as the answer to this should be "no" right? (because if relativeOriginalLine is null, then relativeOriginalColumn must also be null due to where VLQ decoding returns null, and thus it optionally returns an error)
SHA: 66a163d Reason: push, by nicolo-ribaudo Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Preview: https://nicolo-ribaudo.github.io/source-map/#decoded-source-map
This PR introduces "decoded source map" data structures, which are
internal spec representations of the information encoded in source maps.
It also defines algorithms to decode source maps from either a JSON
string or infra representation.
The goal is:
example for the scopes proposal
decoded source map and a generated location".
This PR also explicitly defines sources/sourceRoot resolution in terms
of the WHATWG URL spec.
There are a few points where I'm not sure about what the current/expected behavior is; I marked them with HTML comments (search for
<!--). @takikawa Did you happen to figure out an answer to them while writing tests?Also, I almost everywhere used "optionally report an error", but in a few cases I wrote "throw an error" because I don't think there is a way to recover from it (for example, invalid data in the
mappingsstring). I didn't test what implementations do though.This PR partially fixes the first and last points of #105. Closes #123.