Add all submodules to the list of directories tidy skips
Tidy contains a blacklist of directories that it is not visiting. This list is also used by the `replace-version-placeholder` tool added by #100591 , to determine the directories to do its replacement from. Generally, tidy does not check submodules, but this is not done consistently for all submodules. This PR adds the submodules that were previously missing, so that the `replace-version-placeholder` tool does not attempt to change content of the books. This was needed because `rustc-dev-guide` contains the placeholder, leading to #102014.
Fixes#102014
interpret: expose generate_stacktrace without full InterpCx
In Miri we sometimes want to emit diagnostics without having a full `&InterpCx` available. To avoid duplicating code, this adds a way to get a stacktrace from an arbitrary slice of interpreter frames, that Miri can use with access to just a thread manager.
Update release notes for 1.64
This PR makes a few updates to the release notes to bring them on-par with the release notes of other releases:
* The wording on some items has been changed to be more consistent and better describe what each change means, rather than using the PR title.
* Items that were also in the compatibility notes have been removed from the other sections, only keeping them in the compat notes.
* Diagnostics and ICE fixes have been removed from the notes.
* The cargo section has been made more consistent.
r? ``@Mark-Simulacrum``
cc ``@rust-lang/release`` ``@joshtriplett``
Add unit test for identifier Unicode emoji diagnostics
Seems current diagnostics has some support for emoji usages, however it seems outdated and incomplete. This adds a simple unit test to showcase the status quo.
Add help for invalid inline argument
Fixes#101712
Removed 1 part of the test as its identical with another one. Do let me know if this is undesirable, so I can revert those changes.
Make `from_waker`, `waker` and `from_raw` unstably `const`
Make
- `Context::from_waker`
- `Context::waker`
- `Waker::from_raw`
`const`.
Also added a small test.
Tone down explanation on RefCell::get_mut
The language around `RefCell::get_mut` is remarkably sketchy and especially to the novice seems to quite strongly discourage using the method ("be cautious", "Also, please be aware", "special circumstances", "usually not what you want"). It was added six years ago in #40634 due to confusion about when to use `get_mut` and `borrow_mut`.
While its signature limits the use-cases for `get_mut`, there is no chance for a safety footgun, and readers can be made aware of `borrow_mut` more softly. I've also just sent a [PR](https://github.com/rust-lang/rust-clippy/issues/9044) to lint situations where `get_mut` could be used to improve ergonomics and performance.
So this PR tones down the language around `get_mut` and also brings it more in line with [`std::sync::Mutex::get_mut()`](https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html#method.get_mut).
`EarlyBinder` prevent misuse
folding a type before substituting is pretty much always wrong and could happen by accident, e.g. see https://github.com/rust-lang/rust/pull/99798#discussion_r968666538
this PR removes the `TypeFoldable` and `TypeVisitable` impl from `EarlyBinder`.
r? types cc `@jackh726`
Distribute json doc
# Overview
We add a new component, `rust-json-docs`, to distribute the JSON version of rustdoc's output for public compiler crates (i.e. `std`, `alloc`, `proc_macro`, `core` and `test`).
As discussed in #101383, we do not bundle this up as part of the existing `rust-docs` component since `rustdoc`'s JSON format is still unstable.
# Open questions / Doubts
I tried my best, but I never touched this codebase and I couldn't find much documentation on how `dist` works - I pattern-matched existing code, which might have led to some non-sensical choices in the eyes of people more familiar with the codebase. In particular, I am not sure if my choice of adding a new config flag is appropriate or if the decision to build/not build the JSON docs is more appropriately gated by one of the existing flags.
Any suggestion is more than welcome.
Closes#101383
Add a new configuration settings to set env vars when running cargo, rustc, etc. commands: cargo.extraEnv and checkOnSave.extraEnv
It can be extremely useful to be able to set environment variables when rust-analyzer is running various cargo or rustc commands (such as `cargo check`, `cargo --print cfg` or `cargo metadata`): users may want to set custom `RUSTFLAGS`, change `PATH` to use a custom toolchain or set a different `CARGO_HOME`.
There is the existing `server.extraEnv` setting that allows env vars to be set when the rust-analyzer server is launched, but using this as the recommended mechanism to also configure cargo/rust has some drawbacks:
- It convolutes configuring the rust-analyzer server with configuring cargo/rustc (one may want to change the `PATH` for cargo/rustc without affecting the rust-analyzer server).
- The name `server.extraEnv` doesn't indicate that cargo/rustc will be affected but renaming it to `cargo.extraEnv` doesn't indicate that the rust-analyzer server would be affected.
- To make the setting useful, it needs to be dynamically reloaded without requiring that the entire extension is reloaded. It might be possible to do this, but it would require the client communicating to the server what the overwritten env vars were at first launch, which isn't easy to do.
This change adds two new configuration settings: `cargo.extraEnv` and `checkOnSave.extraEnv` that can be used to change the environment for the rust-analyzer server after launch (thus affecting any process that rust-analyzer invokes) and the `cargo check` command respectively. `cargo.extraEnv` supports dynamic changes by keeping track of the pre-change values of environment variables, thus it can undo changes made previously before applying the new configuration (and then requesting a workspace reload).
Add a codegen test for `slice::from_ptr_range`
I noticed back in #95579 that this didn't optimize as well as it should.
It's better now, after #95837 changed the code in `from_ptr_range` and https://github.com/llvm/llvm-project/issues/54824 was fixed in LLVM 15.
So here's a test to keep it generating the good version.
8 commits in 082503982ea0fb7a8fd72210427d43a2e2128a63..73ba3f35e0205844418260722c11602113179c4a
2022-09-13 17:49:38 +0000 to 2022-09-18 06:38:16 +0000
- Revert "Clarify when cargo detects changes" (rust-lang/cargo#11107)
- Fix links to workspace inheritance headings in workspace docs (rust-lang/cargo#11103)
- docs(ref): Clarify workspace settings (rust-lang/cargo#11082)
- Update comment about ResolveVersion default version (rust-lang/cargo#11095)
- [master] Run `reach_max_unpack_size` test only on debug build (rust-lang/cargo#11091)
- Clarify when cargo detects changes (rust-lang/cargo#11092)
- [master] Fix for CVE-2022-36113 and CVE-2022-36114 (rust-lang/cargo#11089)
- Expose cargo add internals as edit API (rust-lang/cargo#11059)
