@SimonSapin you have more historical context than me, can you think of any reason not to do this?

This has been reviewed upstream in https://phabricator.services.mozilla.com/D321882 but will wait a bit before merging (at least a day or two) to get performance numbers (though I think we should do this just for simplicity), and also to wait for Simon's or other folk's feedback :)

IIRC there's some historical context around this in the git log (on my phone, so can't look it up right now). Would be nice if it can be removed. I think it makes the API a little less flexible around input?

Aside from this change, some docs on how to construct and use Parser (and ParserInput if it stays) would be really nice. The lib.rs docs show how to implement a Parser, but not really how to use one.

Err, yeah so... ParserInput was introduced in 970e1ca (by @jdm), but I think that could've probably just reused Tokenizer directly like here. If you blame that further you get to 41fa928 which is the last large rewrite, which had a very different API (Parser was returned by value from e.g. parse_nested_block), which explains this design a lot more.

So I think this is fine nowadays.

Why do you think this makes the API less flexible? I don't see how.

I feel there must have been a reason to bother with two lifetime parameters but right now I can’t remember what it is or was. Stylo is probably the biggest consumer of cssparser, so if you’ve ported it to this new API and feel it’s an improvement I trust your judgment Emilio.

I feel there must have been a reason to bother with two lifetime parameters but right now I can’t remember what it is or was. Stylo is probably the biggest consumer of cssparser, so if you’ve ported it to this new API and feel it’s an improvement I trust your judgment Emilio.

Possibly because the code was written before the stabilization of non-lexical lifetimes in the 2018 edition.

Well if you borrow the tokenizer from the parser and create nested parsers you need the two lifetimes, one for the tokenizer, one for the input the tokenizer borrows from.

But if you don't, then one suffices :)

Cool so seems there no reason not to do this... Can I get an stamp if so? Even though this has been reviewed upstream I'd rather not use the big red button to merge :)

Well if you borrow the tokenizer from the parser and create nested parsers you need the two lifetimes, one for the tokenizer, one for the input the tokenizer borrows from.

Ah yes, that rings a bell. Do we not create nested parsers anymore? What changed to lead to that?

Do we not create nested parsers anymore? What changed to lead to that?

Right now we do only internally (e.g. see the two comments in here which are the two main changes in the PR other than removing the lifetime). But we can just reuse the same parser and restore the state.

In 41fa928, the API was .parse_nested_block().parse_entirely(parse). But that changed in 1796776, and I don't think we've needed this since then, we could've just fixed up the parser state instead, which is what this PR does.

(Rebased over #447)