-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #98752
Rollup of 9 pull requests #98752
Conversation
Clarify that flow sensitive checks now understand that *visibly* uninhabited call expressions never return. The change influences checks of reachable and unreachable code alike, not just dead code like previous wording would imply.
Adding myself (celinval) to be notified of PRs that changes the MIR.
…, r=estebank fix `emit_inference_failure_err` ICE fixes rust-lang#98598 this fix doesn't make me too happy, but 🤷
…k-Simulacrum Let rust-analyzer ship on stable, non-preview The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method, e.g. the VS Code extension will probably still independently update to its weekly releases, but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component, and removes the "-preview" suffix as well by the usual renaming mechanism. cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``
…-errors add ice test for 46511 Fixes rust-lang#46511 r? ``@compiler-errors``
…GuillaumeGomez rustdoc: filter '_ lifetimes from ty::PolyTraitRef Fixes rust-lang#98697
clarify that ExactSizeIterator::len returns the remaining length fixes rust-lang#98721
Request to be notified of MIR changes Adding myself (celinval) to be notified of PRs that changes the MIR.
…otes, r=Mark-Simulacrum Update RELEASES.md Clarify that flow sensitive checks now understand that *visibly* uninhabited call expressions never return. The change influences checks of reachable and unreachable code alike, not just dead code like previous wording would imply. cc ``@Kixunil``
Add a `--build-dir` flag to rustbuild This adds an optional `--build-dir <path>` flag to rustbuild (to both the python and rust code in src/bootstrap). If provided, it overrides build directory from the config file (if any was provided). My reason for wanting this is that I often will make a change, save, and then go run `x.py check` or `x.py test` (or something). Because I've saved, vscode will start doing its thing in the background, but this will take the file lock, preventing `x.py` from running until vscode finishes whatever it's doing (since the manually invoked x.py won't be able to acquire said file lock). This is annoying, because I'd rather the command I explicitly invoke *not* wait for r-a to complete, as r-a's check is conceptually a background task (and one which can take quite some time to complete). Anyway, while there are likely other ways this could be handled, if you have the disk space an easy way is to just have vscode be configured to use a different build directory, and then they never have to block each-other. This can currently be arranged without this patch, by maintaining two `config.toml`s, one of which has a different build dir, and just exists to be passed into the overridden check command in vscode. Unfortunately, this has the downside of requiring I maintain two `config.toml`s and keep them (at least somewhat) in sync, aside from the build dir. I dislike for several reasons, not the least of which because I know myself well enough to know that these will inevitably get out of sync and confuse me in the future (perhaps this case would be different since I've thought about it enough to write this patch? Who knows, I'd rather not find out). Either way, it would be much easier for me to have a way for *only* the build directory to differ, which this patch provides by way of a new flag. I suggested this to `@jyn514` who indicated it sounded reasonable so long as it didn't add too much complexity, which I think I've achieved, but he can be the judge. Anyway, with this patch I can just use something like `["python3", "x.py", "check", "--build-dir", "build-vscode", "--json-output"]` as the overridden check command to rust-analyzer, and do not need to futz with any additional `config.toml`s. Which is very nice! I've tested this manually, and can confirm that it works. I'm not sure if it needs automated tests, or where I should add them if so. r? `@jyn514` (who has had to put up with my complaints about this... many times. <3)
Add macro_rules! rustdoc change to 1.62 relnotes rust-lang#96630 was tagged <kbd>relnotes</kbd> but didn't make it into the notes. Given this is a compatibility issue (rust-lang#97030, rust-lang#98735, rust-lang#98743), it probably *should* be retroactively added.
@bors r+ rollup=never p=9 |
📌 Commit 18d4228 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7e2733b): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Successful merges:
emit_inference_failure_err
ICE #98610 (fixemit_inference_failure_err
ICE)--build-dir
flag to rustbuild #98745 (Add a--build-dir
flag to rustbuild)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup