Implement (but don't use) valtree and refactor in preparation of use
This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.
cc `@rust-lang/wg-const-eval` on the following commits:
* 2027184 implement valtree
* eeecea9 fallible Scalar -> ScalarInt
* 042f663 ScalarInt convenience methods
cc `@eddyb` on ef04a6d
cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled
This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments
To do so, we
- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code
Closes rust-lang/project-rfc-2229/issues/27
Closes rust-lang/project-rfc-2229/issues/24
r? `@nikomatsakis`
Use delay_span_bug instead of panic in layout_scalar_valid_range
#83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Fixes#83180.
More informative diagnotic from `x.py test` attempt atop beta checkout
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
Deprecate RustcEncodable and RustcDecodable.
We can't remove the `RustcEncodable` and `RustcDecodable` derive macros from the prelude, but we can deprecate them.
No background for code in portability snippets
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.


There should be no observable changes to the ayu theme.
Fall-back to sans-serif if Arial is not available
Otherwise on systems where Arial is not available the UA will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
r? ```@GuillaumeGomez``` cc ```@jsha```
Added `try_exists()` method to `std::path::Path`
This method is similar to the existing `exists()` method, except it
doesn't silently ignore the errors, leading to less error-prone code.
This change intentionally does NOT touch the documentation of `exists()`
nor recommend people to use this method while it's unstable.
Such changes are reserved for stabilization to prevent confusing people.
Apart from that it avoids conflicts with #80979.
`@joshtriplett` requested this PR in [internals discussion](https://internals.rust-lang.org/t/the-api-of-path-exists-encourages-broken-code/13817/25?u=kixunil)
Allow rustdoc to handle asm! of foreign architectures
This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one.
Fixes#82869
Add a `min_type_alias_impl_trait` feature gate
This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).
r? `@nikomatsakis`
This is best reviewed commit-by-commit
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.
(update: placated tidy.)
83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
use RWlock when accessing os::env (take 2)
This reverts commit acdca316c3 (#82877) i.e. redoes #81850 since the invalid unlock attempts in the child process have been fixed in #82949
r? `@joshtriplett`
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
Otherwise on systems where Arial is not available the system will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.