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.
bors[bot] [Mon, 20 Dec 2021 14:43:39 +0000 (14:43 +0000)]
Merge #11067
11067: internal: Store function param names in ItemTree r=Veykril a=Veykril
This prevents us reparsing source files for completions, sometimes slowing them down massively if the source file is not cached at the expense of a slightly bigger memory usage.
related info https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Completion.20performance
bors[bot] [Mon, 20 Dec 2021 09:14:38 +0000 (09:14 +0000)]
Merge #11062
11062: fix: Don't say "a reference to" for `Copy` types in the generate getter assist r=Veykril a=patrick-gu
This changes the generate getter assist to not say "a reference to" in the documentation stub if the type is `Copy`, as the getter does not return a reference.
To determine whether the type is `Copy`, I have added an `is_copy` method to `ReferenceConversion`.
patrick-gu [Mon, 20 Dec 2021 01:27:24 +0000 (17:27 -0800)]
Don't say "a reference to" for Copy types
This changes the generate getter assist to not say "a reference to" in the documentation stub if the type is Copy, as the getter does not return a reference.
bors[bot] [Sun, 19 Dec 2021 00:17:01 +0000 (00:17 +0000)]
Merge #11054
11054: fix #11049 by removing double trimming r=Veykril a=Heinenen
The `unwrap_trivial_block()` removes the braces around trivial blocks (as the name suggests). This violates the precondition of `update_expr_string()` which removes the first and the last non-whitespace character and thus expects braces to still exist around all blocks.
- we still build a plain VSIX, just in case
- we build the extension on every platform to make the release workflow arguably cleaner
- the Windows VSIX includes the PDB (but let's leave #10371 open until we change the Windows stand-alone release to a ZIP file)
- `npm` doesn't run if started from `xtask`, possibly something related to path mapping; I moved the `npm` calls outside, but..
- the `Patch` thingy doesn't work any more, so you'll end up with a dirty `package.json` of you run `cargo xtask --client-patch-version`; I don't think we should block on this
- there's an untested Alpine build; for better or worse, we special-case `musl` distros as `alpine`
- I tested this as much as I could, but not the publishing and nightly updates
- you can find some sample artifacts under https://github.com/lnicola/rust-analyzer/releases
- we can now run the server from the install location (is Code planning to switch to compressed extensions?), except on NixOS
- Code lets you install a VSIX for the wrong platform (with the results one would expect)
- I don't know what happens if we try to publish a VSIX without a target
This is a relatively risky, but we'll probably have to take our chances with it.
projects / rust.git / log