Remove `DropArena`.
Most arena-allocate types that impl `Drop` get their own `TypedArena`, but a
few infrequently used ones share a `DropArena`. This sharing adds complexity
but doesn't help performance or memory usage. Perhaps it was more effective in
the past prior to some other improvements to arenas.
This commit removes `DropArena` and the sharing of arenas via the `few`
attribute of the `arena_types` macro. This change removes over 100 lines of
code and nine uses of `unsafe` (one of which affects the parallel compiler) and
makes the remaining code easier to read.
Rollup of 8 pull requests
Successful merges:
- #86455 (check where-clause for explicit `Sized` before suggesting `?Sized`)
- #90801 (Normalize both arguments of `equate_normalized_input_or_output`)
- #90803 (Suggest `&str.chars()` on attempt to `&str.iter()`)
- #90819 (Fixes incorrect handling of TraitRefs when emitting suggestions.)
- #90910 (fix getting the discriminant of a zero-variant enum)
- #90925 (rustc_mir_build: reorder bindings)
- #90928 (Use a different server for checking clock drift)
- #90936 (Add a regression test for #80772)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use a different server for checking clock drift
The detectportal.firefox.com server seems to return a random-ish date; for
example I see the following across 5 curl's done consecutively locally, where
the real date is approximately 15 Nov 2021 06:36 UTC.
Date: Mon, 15 Nov 2021 13:34:53 GMT
Date: Mon, 15 Nov 2021 12:20:21 GMT
Date: Mon, 15 Nov 2021 00:06:47 GMT
Date: Mon, 15 Nov 2021 17:14:33 GMT
Date: Mon, 15 Nov 2021 13:33:21 GMT
rustc_mir_build: reorder bindings
No functional changes intended.
I'm playing around with building compiler components using nightly rust
(2021-11-02) in a non-standard way. I encountered the following error while
trying to build rustc_mir_build:
```
error[E0597]: `wildcard` does not live long enough
--> rust/src/nightly/compiler/rustc_mir_build/src/build/matches/mod.rs:1767:82
|
1767 | let mut otherwise_candidate = Candidate::new(expr_place_builder.clone(), &wildcard, false);
| ^^^^^^^^^ borrowed value does not live long enough
...
1799 | }
| -
| |
| `wildcard` dropped here while still borrowed
| borrow might be used here, when `guard_candidate` is dropped and runs the destructor for type `Candidate<'_, '_>`
|
= note: values in a scope are dropped in the opposite order they are defined
```
I believe this flags an issue that may become an error in the future.
Swapping the order of `wildcard` and `guard_candidate` resolves it.
Fixes incorrect handling of TraitRefs when emitting suggestions.
Closes#90804 , although there were more issues here that were hidden by the thing that caused this ICE.
Underlying problem was that substitutions were being thrown out, which not only leads to an ICE but also incorrect diagnostics. On top of that, in some cases the self types from the root obligations were being mixed in with those from derived obligations.
This makes a couple diagnostics arguable worse ("`B<C>` does not implement `Copy`" instead of "`C` does not implement `Copy`") but the worse diagnostics are at least still correct and that downside is in my opinion clearly outweighed by the benefits of fixing the ICE and unambiguously wrong diagnostics.
check where-clause for explicit `Sized` before suggesting `?Sized`
Fixes#85945.
Based on #86454.
``@rustbot`` label +A-diagnostics +A-traits +A-typesystem +D-papercut +T-compiler
Address performance regression introduced by #90218
As part of the changes in #90218 , the `adt_drop_tys` and friends code stopped recursing through the query system, meaning that intermediate computations did not get cached. This change adds the recursions back in without re-introducing any of the old issues.
On local benchmarks this fixes the 5% regressions in #90504 ; the wg-grammar regressions didn't seem to move too much. I may take some time later to look into those.
Not sure who to request for review here, so will leave it up to whoever gets it.
Remove bigint_helper_methods for *signed* types
This PR inspired by `@cuviper's` comment @ https://github.com/rust-lang/rust/issues/90541#issuecomment-967309808
These are working well for *unsigned* types, so keep those, but for the the *signed* ones there are a bunch of questions about what the semantics and API should be. For the main "helpers for big integer implementations" use, there's no need for the signed versions anyway. There are plenty of other methods which exist for unsigned types but not signed ones, like `next_power_of_two`, so this isn't unusual.
Fixes#90541
Tracking issue #85532
Rename WASI's `is_character_device` to `is_char_device`.
Rename WASI's `FileTypeExt::is_character_device` to
`FileTypeExt::is_char_device`, for consistency with the Unix
`FileTypeExt::is_char_device`.
Also, add a `FileTypeExt::is_socket` function, for consistency with the
Unix `FileTypeExt::is_socket` function.
r? `@alexcrichton`
Android is not GNU
For a long time, the Android targets had `target_env=""`, but this changed to `"gnu"` in Rust 1.49.0. I tracked this down to #77729 which started setting `"gnu"` in the `linux_base` target options, and this was inherited by `android_base`. Then #78929 split the env into `linux_gnu_base`, but `android_base` was also changed to follow that. Android was not specifically mentioned in either pull request, so I believe this was an accident. Moving it back to `linux_base` will use an empty `env` again.
r? ````@Mark-Simulacrum````
cc ````@petrochenkov````
