vscode extension: migrate from any to unknown where possible #2989
Conversation
Veetaha
changed the title
Veetaha
changed the title
| @@ -55,7 +55,7 @@ export function syntaxTree(ctx: Ctx): Cmd { | |||
|
|
|||
| // We need to order this after LS updates, but there's no API for that. | |||
| // Hence, good old setTimeout. | |||
| function afterLs(f: () => any) { | |||
| function afterLs(f: () => unknown) { | |||
There was a problem hiding this comment.
Hm, this maybe should be => void, or whats the TypeScript alternative for -> ()?
There was a problem hiding this comment.
Also, this is just a horrible hack which needs to die in flames...
There was a problem hiding this comment.
Okay, let me revisit this)
There was a problem hiding this comment.
Yes, you are right, void is semantically -> (), but not the unit type itself (). It is quite a special language item that is meant to be used only for the function return type and denotes that the value should be discarded (also function with void return type is covariant to other functions with different return type, in which way void type is different from undefined type).
I would say that the concept of unit type the way it is present in Rust is not implemented in TypeScripts type system.
editors/code/src/ctx.ts
Outdated
| return this.extCtx.subscriptions; | ||
| } | ||
|
|
||
| pushCleanup(d: { dispose(): any }) { | ||
| pushCleanup(d: { dispose(): unknown }) { |
There was a problem hiding this comment.
Similarly, this wants to be a : void?
There was a problem hiding this comment.
In general, yes you are right, now when I am looking at it, this seems reasonable
|
bors d+ |
|
✌️ Veetaha can now approve this pull request. To approve and merge a pull request, simply reply with |
|
The easiest fix for that would be to do |
|
Hm, yeah, we should make sure that rollup typechecks stuff |
Veetaha
force-pushed
the
feature/refactoring-vscode-ext
branch
from
6926d8e to
2fd7af2
Compare
|
bors r+ |
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]>
Build succeeded
|
miri: implement some `llvm.x86.sse.*` intrinsics and add tests PR moved from rust-lang/rust#113932. Implements LLVM intrisics needed to run most SSE functions from `core::arch::x86{,_64}`. Also adds miri tests for those functions (mostly copied from core_arch tests). r? `@RalfJung` The first commit is the same that the commit in the PR I had opened in the Rust repository. I addressed review comments in additional commits to make it easier to review. I also fixed formatting and clippy warnings.
miri: implement some `llvm.x86.sse.*` intrinsics and add tests PR moved from rust-lang/rust#113932. Implements LLVM intrisics needed to run most SSE functions from `core::arch::x86{,_64}`. Also adds miri tests for those functions (mostly copied from core_arch tests). r? `@RalfJung` The first commit is the same that the commit in the PR I had opened in the Rust repository. I addressed review comments in additional commits to make it easier to review. I also fixed formatting and clippy warnings.
unknowntype is the stricter version ofanyand it should always be prefered (likeconstoverlet).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').