Changes needed for gecko-integration

[valenting]

This pull request contains 2 features that are needed in the C-API for use in Gecko:

1. Feature that allows to only percent decode characters that are valid in the hostname.
   This introduces the only_percent_decode_hostname_valid feature.
2. From for Position in order to use slicing in the C API.

---

This change is

[SimonSapin]

I’ll comment more tomorrow, but why the first change? It deviates from the spec. If it’s necessary for web-compat, the spec should be changed.

[valenting]

I forgot to mention the reasoning behind this. Indeed it deviates from the spec (which is why I made it a feature), but that is needed to support old addons in Gecko, which access their content using a URL such as resource://ADDON_ID/path - where ADDON_ID usually contains a percent encoded @ character.
If we feel this isn't a change we want to support at all, I could use a separate fork for the Gecko stuff.

[SimonSapin]

Does Gecko’s URL parser for web content have the same behavior? If that’s the case and Gecko is not willing to align with the spec, maybe the spec should be changed. Could you file an issue on https://github.com/whatwg/url/issues/ with the proposed parser changes and this reasoning?

Instead of a compile-time switch it could be a per-URL run-time one: add a method to ParseOptions and use it like: Url::options().only_percent_decode_hostname_valid().parse(some_str). What do you think?

I’ll comment inline on implementation details.

[SimonSapin]

Encode sets are normally used for percent encoding, not decoding. So I’d rather not expose this in the public API. In after_percent_sign you could "inline" !HOSTNAME_ENCODE_SET.contains(c) to !(matches(c, ' ' | '!' | '"' | /* ...*/ '~') || c < '\u{20}' || c > '\u{7E}'), or invert the logic and use matches!(c, 'a'...'z' | 'A'...'Z' | '0'...'9' | '.' | '-' | '_' | '*'). (I think that’s the complementary set, but I’m not sure * should be there.)

[nox]

Why not use an enum from C too for Position?

[bors-servo]

☔ The latest upstream changes (presumably #216) made this pull request unmergeable. Please resolve the merge conflicts.

[valenting]

The resource://ADDON_ID issue will be fixed in Firefox, so we shouldn't worry about that here.
I'll probably open another PR for the slicing bits.

[nox]

The resource://ADDON_ID issue will be fixed in Firefox,

@valenting And you deliver this information on my birthday? You have a good timing sense, thanks. :D