bors[bot] [Sat, 1 Jan 2022 16:42:22 +0000 (16:42 +0000)]
Merge #11136
11136: Turbo fish assist supports multiple type arguments r=matklad a=Vannevelj
This fixes #11135 (changelog: bug).
I've only started using Rust a few days ago but saw this issue on the top of the list when I looked at this repo. I based myself on [this blog post](https://techblog.tonsser.com/posts/what-is-rusts-turbofish) to understand what a "turbo fish" is so let me know if I missed anything.
Aleksey Kladov [Sat, 1 Jan 2022 16:10:34 +0000 (19:10 +0300)]
test: force client-side watching
The direct reason for this is to fix CI on windows, which seems to fail
for some reason after we fixed the watcher-selection logic which (I
think) changed the tests behavior to use notify rather than client.
But this patch seems to make sense in general -- file watching is
notoriously finicky, so controlling it explicitly leads to less fragile
tests.
bors[bot] [Tue, 28 Dec 2021 16:22:20 +0000 (16:22 +0000)]
Merge #11134
11134: internal: tighten up parser API r=matklad a=matklad
It's tempting to expose things like `Expr::parse`,
but they'll necessary have somewhat ad-hoc semantics.
Instead, we narrow down the parser's interface strictly
to what's needed for MBE. For everything else (eg, parsing
imports), the proper way is enclose the input string into
some context, parse the whole as a file, and then verify
that the input was parsed as intended.
bors[bot] [Sun, 26 Dec 2021 13:49:59 +0000 (13:49 +0000)]
Merge #11118
11118: internal: move ws attachment logic to the parser crate r=matklad a=matklad
This has to re-introduce the `sink` pattern, because doing this purely
with iterators is awkward :( Maaaybe the event vector was a false start?
But, anyway, I like the current factoring more -- it sort-of obvious
that we do want to keep ws-attachment business in the parser, and that
we also don't want that to depend on the particular tree structure. I
think `shortcuts` module achieves that.
Aleksey Kladov [Sun, 26 Dec 2021 13:47:10 +0000 (16:47 +0300)]
internal: move ws attachment logic to the parser crate
This has to re-introduce the `sink` pattern, because doing this purely
with iterators is awkward :( Maaaybe the event vector was a false start?
But, anyway, I like the current factoring more -- it sort-of obvious
that we do want to keep ws-attachment business in the parser, and that
we also don't want that to depend on the particular tree structure. I
think `shortcuts` module achieves that.
bors[bot] [Sat, 25 Dec 2021 19:13:56 +0000 (19:13 +0000)]
Merge #11117
11117: internal: replace TreeSink with a data structure r=matklad a=matklad
The general theme of this is to make parser a better independent
library.
The specific thing we do here is replacing callback based TreeSink with
a data structure. That is, rather than calling user-provided tree
construction methods, the parser now spits out a very bare-bones tree,
effectively a log of a DFS traversal.
This makes the parser usable without any *specifc* tree sink, and allows
us to, eg, move tests into this crate.
Now, it's also true that this is a distinction without a difference, as
the old and the new interface are equivalent in expressiveness. Still,
this new thing seems somewhat simpler. But yeah, I admit I don't have a
suuper strong motivation here, just a hunch that this is better.
Aleksey Kladov [Sun, 19 Dec 2021 14:36:23 +0000 (17:36 +0300)]
internal: replace TreeSink with a data structure
The general theme of this is to make parser a better independent
library.
The specific thing we do here is replacing callback based TreeSink with
a data structure. That is, rather than calling user-provided tree
construction methods, the parser now spits out a very bare-bones tree,
effectively a log of a DFS traversal.
This makes the parser usable without any *specifc* tree sink, and allows
us to, eg, move tests into this crate.
Now, it's also true that this is a distinction without a difference, as
the old and the new interface are equivalent in expressiveness. Still,
this new thing seems somewhat simpler. But yeah, I admit I don't have a
suuper strong motivation here, just a hunch that this is better.
projects / rust.git / log