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 <gerzoh1@gmail.com>
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 <gerzoh1@gmail.com>
2964: Improve responsiveness of the cargo check status label r=matklad a=lnicola
This is still not ideal because the label displays the crate that was just checked, not the one that's currently being checked. But it should give the impression of being faster.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
By default, `spawn` inherits stderr/stdout/stderr of the parent
process, and so, if child, for example does fcntl(O_NONBLOCK), weird
stuff happens to us.
Closes https://github.com/rust-analyzer/lsp-server/pull/10
2963: Emacs fixes r=matklad a=flodiebold
- use provided environment for runnables (finally set `RUST_BACKTRACE`)
- implement `selectAndApplySourceChange` so auto-import works 🙂
cc @brotzeit
2967: Disable optimizations for some build-time crates r=matklad a=lnicola
This speeds up a release build on my laptop from 4m 13s to 3m 33s. It's a bit disappointing, but we don't get perfect parallelism during the build. The non-RA dependencies finish building around 72s as opposed to 112s.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
2946: updating nvim_lsp usage for rust_analyzer r=matklad a=matu3ba
The other option is invalid and a working version depends on [PR](https://github.com/neovim/nvim-lsp/pull/107)
Co-authored-by: Jan <jan.hafer@rwth-aachen.de>
