Because the old spelling is widely used, some projects may need time to
migrate their uses to the new triple spelling. The old spelling may
eventually be removed altogether.
Colorize `cargo check` diagnostics in VSCode via text decorations
Fixes#13648
![colored-rustc-diagnostics](https://user-images.githubusercontent.com/11131775/209479884-10eef8ca-37b4-4aae-88f7-3591ac01b25e.gif)
Use ANSI control characters to display text decorations matching the VScode terminal theme, and strip them out when providing text content for rustc diagnostics.
This adds the small [`anser`](https://www.npmjs.com/package/anser) library (MIT license, no dependencies) to parse the control codes, and it also supports HTML output so it should be fairly easy to switch to a rendered HTML/webview implementation in the future
I also updated the default `cargo check` command to use the rendered ANSI diagnostics, although I'm not sure if it makes sense to put this kind of thing behind a feature flag, or whether it might have any issues on Windows (as I believe ANSI codes are not used for colorization there)?
Use ANSI control characters to display text decorations matching the
VScode terminal theme, and strip them out when providing text content
for rustc diagnostics.
This adds the small `anser` library to parse the control codes, and it
also supports HTML output so it should be fairly easy to switch to a
rendered HTML/webview implementation if desired.
add dtors_in_dtors_in_dtors
That's a pretty neat test from the standard library. Sadly not enough to check for https://github.com/rust-lang/miri/issues/2754, but still worth having here.
Rename `checkOnSave` settings to `check`
Now that flychecks can be triggered without saving the setting name doesn't make that much sense anymore. This PR renames it to just `check`, but keeps `checkOnSave` as the enabling setting.
error-code docs improvements (No. 2)
- Added empty error-code docs for `E0208`, `E0640` and `E0717` with the "internal" header as discussed on Discord.
- Wrote docs and UI test for `E0711`, again with the header.
- `tidy` changes are common-sense and make everything pass, `style.rs` hack is annoying though.
r? ```@GuillaumeGomez```
Use FxIndexSet when updating obligation causes in `adjust_fulfillment_errors_for_expr_obligation`
I have no idea how to test this reliably, but I've **manually** verified it fixes the instability in #106417 that isn't due to dtolnay/trybuild#212.
Fixes#106417
Simplify some canonical type alias names
* delete the `Canonicalized<'tcx>` type alias in favor for `Canonical<'tcx>`
* `CanonicalizedQueryResponse` -> `CanonicalQueryResponse`
I don't particularly care about the latter, but it should be consistent. We could alternatively delete the first alias and rename the struct to `Canonicalized`, and then keep the name of `CanonicalizedQueryResponse` untouched.
Move `check_region_obligations_and_report_errors` to `TypeErrCtxt`
Makes sense for this function to live with its sibling `resolve_regions_and_report_errors`, around which it's basically just a wrapper.
Enable Shadow Call Stack for Fuchsia on AArch64
Fuchsia already uses SCS by default for C/C++ code on ARM hardware. This patch allows SCS to be used for Rust code as well.
Fix ui constant tests for big-endian platforms
A number of tests under ui/const-ptr and ui/consts are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the stderr test files.
Fix this by a combination of two types of changes:
- Where possible (i.e. where the particular value of a constant does not affect the purpose of the test), choose constant values that have the same encoding on big- and little-endian platforms.
- Where this is not possible, provide a normalize-stderr-test rule that transforms the printed big-endian encoding of such constants into the corresponding little-endian form.
Fixes part of https://github.com/rust-lang/rust/issues/105383.
Remove invalid case for mutable borrow suggestion
If we have a call such as `foo(&mut buf)` and after reference
collapsing the type is inferred as `&T` where-as the required type is
`&mut T`, don't suggest `foo(&mut mut buf)`. This is wrong syntactically
and the issue lies elsewhere, not in the borrow.
Fixes#105645
Change a commit_if_ok call to probe
Removes an over-eager `commit_if_ok` which makes inference worse.
I'm not entirely sure whether it's ok to remove the check that types are the same, because casting seems to cause equality checks with incorrect types?
Fixes#105037
r? ```@BoxyUwU```
Add action to expand a declarative macro once, inline. Fixes#13598
This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See #13598 for the most applicable issue; though I suspect it'll resolve part of #5949 and make #11888 significantly easier).
The macro works like this:
![rust-analyser-feature](https://user-images.githubusercontent.com/10906982/208813167-3123e379-8fd5-4206-a4f4-5af1129565f9.gif)
I have 2 questions before this PR can be merged:
1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release.
2. **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.