1912: add new editing API, suitable for modifying several nodes at once r=viorina a=matklad
r? @viorina
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1913: Fix retrieval of the Fn traits r=flodiebold a=flodiebold
I used the wrong query, so it only used the lang items from the respective
crate...
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1900: Add rollup bundler for vscode extension r=matklad a=JasperDeSutter
This is an alternative approach to #1451 - bundling should improve extension startup times as explained [here](https://code.visualstudio.com/api/working-with-extensions/bundling-extension).
I'm using [rollup.js](https://rollupjs.org/guide/en/) which is a small and light bundler as opposed to webpack. Bundling is only done for creating the final vsix package, reducing 196 files down to 7 (of which 1 javascript file).
1907: update documentation according to new settings r=matklad a=lesurp
1. `command` has been added to change the default cargo-watch command
2. `check-arguments` has been renamed to `arguments` as a consequence
Thoses changes were merged in #1434
Co-authored-by: JasperDeSutter <jasper.desutter@gmail.com>
Co-authored-by: Paul Lesur <paul.lesur@dfki.de>
1. `command` has been added to change the default cargo-watch command
2. `check-arguments` has been renamed to `arguments` as a consequence
Thoses changes were merged in #1434
1845: Closure types r=flodiebold a=flodiebold
This adds types for closures and makes them implement the `Fn` traits (we don't currently care or try to infer `Fn` vs. `FnMut` vs. `FnOnce`; this would require move analysis, I think).
This requires some changes in Chalk; one is that we need to know the self type when asked for impls, so we can synthesize `Fn` trait impls for closures; but also there's a problem that prevents us from normalizing the closure output type correctly that I _think_ will be fixed on the Chalk side (basically, we ask too early and try to solve `Normalize(<?1 as FnOnce<(u32,)>>::Output => ?0)` -- note the variable in the self type -- and instead of an ambiguous answer, we get back that it can't be solved, so we don't try again. Niko mentioned he's making all goals where the self type is unconstrained flounder, which I think would mean this would be ambiguous).
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1895: Handle associated type shorthand (`T::Item`) (Second attempt) r=flodiebold a=flodiebold
This is only allowed for generic parameters (including `Self` in traits), and
special care needs to be taken to not run into cycles while resolving it,
because we use the where clauses of the generic parameter to find candidates for
the trait containing the associated type, but the where clauses may themselves
contain instances of short-hand associated types.
In some cases this is even fine, e.g. we might have `T: Trait<U::Item>, U:
Iterator`. If there is a cycle, we'll currently panic, which isn't great, but
better than overflowing the stack...
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
