Remove `tests/run-make-fulldeps/pretty-expanded`
This was an ancient regression test for #12685, caused by `-Zunpretty=expanded` crashing on certain code produced by `#[derive(RustcEncodable)]`.
Given that this test predates `//@ pretty-expanded` tests, and was tied to ancient implementation details of the pretty-printer and `#[derive(RustcEncodable)]` (which the test no longer even uses), I think we can safely delete it.
---
Spotted via #125948.
Update books
## rust-lang/book
6 commits in 85442a608426d3667f1c9458ad457b241a36b569..5228bfac8267ad24659a81b92ec5417976b5edbc
2024-05-29 20:55:49 UTC to 2024-05-27 17:22:03 UTC
- Fix typo in ch10-03 (rust-lang/book#3539)
- Backport changes to ch 9 and 10 (rust-lang/book#3946)
- infra: correctly support preprocessors for nostarch (rust-lang/book#3944)
- Use `<kbd>` instead of `<span class="keystroke">` (rust-lang/book#3945)
- infra: Fix clippy warning in remove_markup (rust-lang/book#3943)
- fix: ch10-03 - misleading use of expect on .split (rust-lang/book#3939)
## rust-lang/edition-guide
2 commits in 0c68e90acaae5a611f8f5098a3c2980de9845ab2..bbaabbe088e21a81a0d9ae6757705020d5d7b416
2024-05-24 19:07:18 UTC to 2024-05-21 22:40:52 UTC
- 2024: Document reserving `gen` keyword (rust-lang/edition-guide#300)
- 2024: Document cargo changes (rust-lang/edition-guide#301)
## rust-embedded/book
1 commits in dd962bb82865a5284f2404e5234f1e3222b9c022..b10c6acaf0f43481f6600e95d4b5013446e29f7a
2024-05-31 08:51:50 UTC to 2024-05-31 08:51:50 UTC
- Add some explanations as to why exception re-entrancy may still be an issue in a multicore-environment. (rust-embedded/book#367)
## rust-lang/reference
6 commits in e356977fceaa8591c762312d8d446769166d4b3e..6019b76f5b28938565b251bbba0bf5cc5c43d863
2024-06-03 15:58:57 UTC to 2024-05-25 18:35:54 UTC
- Add Apple `target_abi` values to the example values (rust-lang/reference#1507)
- this needs a space (rust-lang/reference#1506)
- Mention Variadics With No Fixed Parameter (rust-lang/reference#1494)
- Add "scopes" chapter. (rust-lang/reference#1040)
- update patterns.md for const pattern RFC (rust-lang/reference#1456)
- document guarantee about evaluation of associated consts and const blocks (rust-lang/reference#1497)
## rust-lang/rust-by-example
3 commits in 20482893d1a502df72f76762c97aed88854cdf81..4840dca06cadf48b305d3ce0aeafde7f80933f80
2024-05-28 13:56:12 UTC to 2024-05-27 11:51:10 UTC
- Update mdbook-i18n-helpers to 0.3.3 (rust-lang/rust-by-example#1857)
- Fix CI failure (rust-lang/rust-by-example#1856)
- Add precision on From/Into asymmetry to from_into.md (rust-lang/rust-by-example#1855)
## rust-lang/rustc-dev-guide
4 commits in b6d4a4940bab85cc91eec70cc2e3096dd48da62d..6a7374bd87cbac0f8be4fd4877d8186d9c313985
2024-05-31 00:27:28 UTC to 2024-05-21 09:56:12 UTC
- Flesh out the "representing types" chapter (rust-lang/rustc-dev-guide#1985)
- sync the stage0 filename (rust-lang/rustc-dev-guide#1979)
- Add Rust for Linux notification group entry (rust-lang/rustc-dev-guide#1984)
- fix some typos (rust-lang/rustc-dev-guide#1983)
Fix typo in the docs of `HashMap::raw_entry_mut`
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Ignore `vec_deque_alloc_error::test_shrink_to_unwind` test on non-unwind targets
https://github.com/rust-lang/rust/pull/123803 added this test which requires unwinding to succeed. This conditionally ignores the test on non-unwind targets (as is the case with other tests using `catch_unwind`).
Create `run-make` `env_var` and `env_var_os` helpers
As mentioned in https://github.com/rust-lang/rust/pull/125886. It's quite useful to know which environment variable failed, so better provide a helper helping with that.
r? `@jieyouxu`
Explain differences between `{Once,Lazy}{Cell,Lock}` types
The question of "which once-ish cell-ish type should I use?" has been raised multiple times, and is especially important now that we have stabilized the `LazyCell` and `LazyLock` types. The answer for the `Lazy*` types is that you would be better off using them if you want to use what is by far the most common pattern: initialize it with a single nullary function that you would call at every `get_or_init` site. For everything else there's the `Once*` types.
"For everything else" is a somewhat weak motivation, as it only describes by negation. While contrasting them is inevitable, I feel positive motivations are more understandable. For this, I now offer a distinct example that helps explain why `OnceLock` can be useful, despite `LazyLock` existing: you can do some cool stuff with it that `LazyLock` simply can't support due to its mere definition.
The pair of `std::sync::*Lock`s are usable inside a `static`, and can serve roles in async or multithreaded (or asynchronously multithreaded) programs that `*Cell`s cannot. Because of this, they received most of my attention.
Fixes#124696Fixes#125615
Convert `proc_macro_back_compat` lint to an unconditional error.
We still check for the `rental`/`allsorts-rental` crates. But now if they are detected we just emit a fatal error, instead of emitting a warning and providing alternative behaviour.
The original "hack" implementing alternative behaviour was added in #73345.
The lint was added in #83127.
The tracking issue is #83125.
The direct motivation for the change is that providing the alternative behaviour is interfering with #125174 and follow-on work.
r? ``@estebank``
Add function `core::iter::chain`
The addition of `core::iter::zip` (#82917) set a precedent for adding plain functions for iterator adaptors. Adding `chain` makes it a little easier to `chain` two iterators.
```rust
for (x, y) in chain(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().chain(ys) {}
```
There is prior art for the utility of this in [`itertools::chain`](https://docs.rs/itertools/latest/itertools/fn.chain.html).
Approved ACP https://github.com/rust-lang/libs-team/issues/154
Update `compiler-builtins` test to not clear essential env vars
Noticed in https://github.com/rust-lang/rust/pull/122580#issuecomment-2125755689, the `compiler-builtins` test failed on Windows for a `cargo` invocation because necessary env vars `TMP` and `TEMP` were cleared by `Command::env_clear`, causing temp dir eventually used by codegen to fallback to the Windows directory, which will trigger permission errors.
This PR removes the `env_clear` on the cargo invocation.
r? `@saethlin` (feel free to reroll, since you authored the test)
try-job: x86_64-msvc
try-job: test-various
Rollup of 8 pull requests
Successful merges:
- #125667 (Silence follow-up errors directly based on error types and regions)
- #125717 (Refactor `#[diagnostic::do_not_recommend]` support)
- #125795 (Improve renaming suggestion for names with leading underscores)
- #125865 (Fix ICE caused by ignoring EffectVars in type inference)
- #125953 (Streamline `nested` calls.)
- #125959 (Reduce `pub` exposure in `rustc_mir_build`)
- #125967 (Split smir `Const` into `TyConst` and `MirConst`)
- #125968 (Store the types of `ty::Expr` arguments in the `ty::Expr`)
r? `@ghost`
`@rustbot` modify labels: rollup
Store the types of `ty::Expr` arguments in the `ty::Expr`
Part of #125958
In attempting to remove the `ty` field on `Const` it will become necessary to store the `Ty<'tcx>` inside of `Expr<'tcx>`. In order to do this without blowing up the size of `ConstKind`, we start storing the type/const args as `GenericArgs`
r? `@oli-obk`
Split smir `Const` into `TyConst` and `MirConst`
Part of #125958
Building a `smir::Const` currently requires accessing the `Ty<'tcx>` of a `ty::Const`. This will stop being possible in the future. Replicate the split in rustc of having a representation of type level constants and mir constants with the latter being able to store the former. Ideally we wouldnt have `MirConst::Ty` but 🤷♀️
r? `@oli-obk`
Streamline `nested` calls.
`TyCtxt` impls `PpAnn` in `compiler/rustc_middle/src/hir/map/mod.rs`. We can call that impl, which then calls the one on `intravisit::Map`, instead of calling the one on `intravisit::Map` directly, avoiding a cast and extra references.
r? `@lqd`
Improve renaming suggestion for names with leading underscores
Fixes#125650
Before:
```
error[E0425]: cannot find value `p` in this scope
--> test.rs:2:13
|
2 | let _ = p;
| ^
|
help: a local variable with a similar name exists, consider renaming `_p` into `p`
|
1 | fn a(p: i32) {
| ~
```
After:
```
error[E0425]: cannot find value `p` in this scope
--> test.rs:2:13
|
1 | fn a(_p: i32) {
| -- `_p` defined here
2 | let _ = p;
| ^
|
help: the leading underscore in `_p` marks it as unused, consider renaming it to `p`
|
1 | fn a(p: i32) {
| ~
```
This change doesn't exactly conform to what was proposed in the issue:
1. I've kept the suggested code instead of solely replacing it with the label
2. I've removed the "...similar name exists..." message instead of relocating to the usage span
3. You could argue that it still isn't completely clear that the change is referring to the definition (not the usage), but I'm not sure how to do this without playing down the fact that the error was caused by the usage of an undefined name.
Refactor `#[diagnostic::do_not_recommend]` support
This commit refactors the `#[do_not_recommend]` support in the old parser to also apply to projection errors and not only to selection errors. This allows the attribute to be used more widely.
Part of #51992
r? `@compiler-errors`
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Silence follow-up errors directly based on error types and regions
During type_of, we used to just return an error type if there were any errors encountered. This is problematic, because it means a struct declared as `struct Foo<'static>` will end up not finding any inherent or trait impls because those impl blocks' `Self` type will be `{type error}` instead of `Foo<'re_error>`. Now it's the latter, silencing nonsensical follow-up errors about `Foo` not having any methods.
Unfortunately that now allows for new follow-up errors, because borrowck treats `'re_error` as `'static`, causing nonsensical errors about non-error lifetimes not outliving `'static`. So what I also did was to just strip all outlives bounds that borrowck found, thus never letting it check them. There are probably more nuanced ways to do this, but I worried there would be other nonsensical errors if some outlives bounds were missing. Also from the test changes, it looked like an improvement everywhere.
The addition of `core::iter::zip` (#82917) set a precedent for adding
plain functions for iterator adaptors. Adding `chain` makes it a little
easier to `chain` two iterators.
```
for (x, y) in chain(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().chain(ys) {}
```
Handle no values cfgs with `--print=check-cfg`
This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values.
The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value.
So for `cfg(feature, values())` we would print `feature=`.
I also added the missing tracking issue number in the doc.
r? ```@petrochenkov```
Align `Term` methods with `GenericArg` methods, add `Term::expect_*`
* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.
I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.
r? types
ARM Target Docs Update
Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents.
Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Change pedantically incorrect OnceCell/OnceLock wording
While the semantic intent of a OnceCell/OnceLock is that it can only be written to once (upon init), the fact of the matter is that both these types offer a `take(&mut self) -> Option<T>` mechanism that, when successful, resets the cell to its initial state, thereby [technically allowing it to be written to again](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=415c023a6ae1ef35f371a2d3bb1aa735)
Despite the fact that this can only happen with a mutable reference (generally only used during the construction of the OnceCell/OnceLock), it would be incorrect to say that the type itself as a whole *categorically* prevents being initialized or written to more than once (since it is possible to imagine an identical type only without the `take()` method that actually fulfills that contract).
To clarify, change "that cannot be.." to "that nominally cannot.." and add a note to OnceCell about what can be done with an `&mut Self` reference.
```@rustbot``` label +A-rustdocs
Add tracking issue and unstable book page for `"vectorcall"` ABI
Originally added in 2015 by #30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now.
Tracking issue: #124485
`TyCtxt` impls `PpAnn` in `compiler/rustc_middle/src/hir/map/mod.rs`. We
can call that impl, which then calls the one on `intravisit::Map`,
instead of calling the one on `intravisit::Map` directly, avoiding a
cast and extra references.
Make TLS accessors closures that return pointers
The current TLS macros generate a function that returns an `Option<&'static T>`. This is both risky as we lie about lifetimes, and necessitates that those functions are `unsafe`. By returning a `*const T` instead, the accessor function do not have safety requirements any longer and can be made closures without hassle. This PR does exactly that!
For native TLS, the closure approach makes it trivial to select the right accessor function at compile-time, which could result in a slight speed-up (I have the hope that the accessors are now simple enough for the MIR-inliner to kick in).
bors