fix: revert float parsing "fix" to avoid macro-related panics
Reverts https://github.com/rust-lang/rust-analyzer/pull/12149 and the follow-up fixes, while keeping their tests.
https://github.com/rust-lang/rust-analyzer/pull/12149 has caused many unexpected panics related to macros, and the fixes for those are not straightforward and further complicate the MBE token conversion logic, which was already fairly hard to follow before these fixes.
feat: Support variable substitution in VSCode settings
Currently support a subset of [variables provided by VSCode](https://code.visualstudio.com/docs/editor/variables-reference) in `server.extraEnv` section of Rust-Analyzer settings:
* `workspaceFolder`
* `workspaceFolderBasename`
* `cwd`
* `execPath`
* `pathSeparator`
Also, this PR adds support for general environment variables resolution. You can declare environment variables and reference them from other variables like this:
```JSON
"rust-analyzer.server.extraEnv": {
"RUSTFLAGS": "-L${env:OPEN_XR_SDK_PATH}",
"OPEN_XR_SDK_PATH": "${workspaceFolder}\\..\\OpenXR-SDK\\build\\src\\loader\\Release"
},
```
The order of variable declaration doesn't matter, you can reference variables before defining them. If the variable is not present in `extraEnv` section, VSCode will search for them in your environment. Missing variables will be replaced with empty string. Circular references won't be resolved and will be passed to rust-analyzer server process as is.
Closes#9626, but doesn't address use cases where people want to use values provided by `rustc` or `cargo`, such as `${targetTriple}` proposal #11649
Fix `character` semantic token type definition
The semantic token type for character literals is called `character`:
94fa8a6534/crates/rust-analyzer/src/semantic_tokens.rs (L51)
and yet the definition in `package.json` uses `char`. In practice this means trying to highlight `char` doesn’t have any effect, while `character` doesn’t have any hover documentation and doesn’t appear in autocomplete. The definition also defines the fallback semantic token type as `type`; luckily since it currently references the non-existent `char` this doesn’t have any effect, since it doesn’t really make sense to highlight character literals as types.
This PR fixes the definition in `package.json` to correctly reference `character`, and also defines the fallback type as `number`. I’d say character literals are closer to a shorthand for writing a number than a string, though this is debatable and I’d be happy to change it to `string`, or anything else.
