| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Markdown ;(
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(implemented with iterators)
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3003: Remove rollup-typescript r=matklad a=matklad
It seems like just calling typescript directly is simpler and more reliable?
@Veetaha what do you think about this approach?
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| |
| |
| |
| | |
It seems like just calling typescript directly is simpler and more reliable?
|
|\|
| |
| |
| |
| |
| |
| |
| | |
3002: Update some rollup packages r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
3001: Use simple prng instead of a dependency r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
| |
closes #2999
|
|\
| |
| |
| |
| |
| |
| |
| | |
2997: Use proper import name in the label r=matklad a=SomeoneToIgnore
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2998: Remove recent improvements to the build script r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
|
|
|
|
| |
tslib as a dev dependency and commonjs modules are definitely *wrong*
in the ideal world, **but** in the real world that's the only
combination that works. See
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Problems.20with.20TypeScript.20build
|
|\
| |
| |
| |
| |
| |
| |
| | |
2994: Small cleanup r=matklad a=SomeoneToIgnore
A follow-up to https://github.com/rust-analyzer/rust-analyzer/pull/2990#discussion_r374044482
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2995: Fix build of typscript extension r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2959: Rework how we send diagnostics to client r=matklad a=kiljacken
The previous way of sending from the thread pool suffered from stale diagnostics due to being canceled before we could clear the old ones.
The key change is moving to sending diagnostics from the main loop thread, but doing all the hard work in the thread pool. This should provide the best of both worlds, with little to no of the downsides.
This should hopefully fix a lot of issues, but we'll need testing in each individual issue to be sure.
Co-authored-by: Emil Lauridsen <[email protected]>
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous way of sending from the thread pool suffered from stale
diagnostics due to being canceled before we could clear the old ones.
The key change is moving to sending diagnostics from the main loop
thread, but doing all the hard work in the thread pool. This should
provide the best of both worlds, with little to no of the downsides.
This should hopefully fix a lot of issues, but we'll need testing in
each individual issue to be sure.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
2990: Use name only when searching for an import candidate r=me a=SomeoneToIgnore
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2993: vscode: fix bundling by switching to es2015 target modules system r=matklad a=Veetaha
Quick fix
Co-authored-by: Veetaha <[email protected]>
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2991: vscode: updated rollup typescript so it typechecks the bundle r=Veetaha a=Veetaha
See [this happy update](https://github.com/rollup/plugins/blob/master/packages/typescript/CHANGELOG.md#v300) from `@rollup/typescript-plugin` changelog)
I also added a utility script to view the latest dependencies versions (`dry-run` variant) and update them in batch. Beware, that it bumps versions even if the major version of them has changed (for updating only within one major version there is a cli option, but I didn't want add a whole bunch of scripts)
Some of the dependencies major versions are out of date:
```
~/my/projects/rust-analyzer/editors/code (feature/refactoring-vscode-ext) $ npm run bump-deps:dry-run
> [email protected] bump-deps:dry-run /home/veetaha/my/projects/rust-analyzer/editors/code
> npm-check-updates
Checking /home/veetaha/my/projects/rust-analyzer/editors/code/package.json
[====================] 16/16 100%
jsonc-parser ^2.1.0 → ^2.2.0
@rollup/plugin-commonjs ^11.0.1 → ^11.0.2
@rollup/plugin-node-resolve ^6.1.0 → ^7.1.0
@types/node ^12.12.25 → ^13.7.0
rollup ^1.30.1 → ^1.31.0
tslint ^5.20.1 → ^6.0.0
vsce ^1.71.0 → ^1.72.0
```
Co-authored-by: Veetaha <[email protected]>
|
| | | |
|
|/ / |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
2989: vscode extension: migrate from any to unknown where possible r=Veetaha a=Veetaha
`unknown` type is the stricter version of `any` and it should always be prefered (like `const` over `let`).
It lets you assign any value to it, but doesn't let you carry out arbitrary operations on them without an explicit type check (like `typeof unknownValue === 'string'`).
Co-authored-by: Veetaha <[email protected]>
|
| | |
|
| | |
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
2987: vscode refactoring: use more laconic export snytax, split huge string literal r=matklad a=Veetaha
Co-authored-by: Veetaha <[email protected]>
|
| | |
|
|/
|
|
| |
several lines
|
|\
| |
| |
| |
| |
| |
| |
| | |
2986: vscode extension cleanup: migrate to prefer-const tslint rule r=matklad a=Veetaha
Co-authored-by: Veetaha <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2985: Avoid premature pessimization r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
|
|
| |
The extra allocation for message should not matter here at all, but
using a static string is just as ergonomic, if not more, and there's
no reason to write deliberately slow code
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2979: vscode: now we are actually using tslib r=matklad a=Veetaha
We had an incorrect setup where `tslib` was in `devDependencies`.
FYI:
tslib is a runtime dependency, it contains functions that are used by transpiled JavaScript in order not to inline them in each file.
For example:
```ts
// foo.ts (source code)
import * as foo from "foo";
// ---------------------------
// foo.js (compiled output)
"use strict";
var __importStar = (this && this.__importStar) || function (mod) {
if (mod && mod.__esModule) return mod;
var result = {};
if (mod != null) for (var k in mod) if (Object.hasOwnProperty.call(mod, k)) result[k] = mod[k];
result["default"] = mod;
return result;
};
Object.defineProperty(exports, "__esModule", { value: true });
const foo = __importStar(require("foo"));
```
As you see, `tsc` generated that `__importStar` helper function in compiled output. And it generates it per each file if you don't enable `"importHelpers": true`. Now with `importHelpers` enabled we get the following picture:
```ts
// foo.ts (source code)
import * as foo from "foo";
// ---------------------------
// foo.js (compiled output)
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const tslib_1 = require("tslib");
const foo = tslib_1.__importStar(require("foo"));
```
It saves some bundle size, but I am not entirely sure wheter we want that. Discussions are welcome!
Co-authored-by: Veetaha <[email protected]>
|
| | |
|