enable unstable feature on `x clean [PATH]`
Since https://github.com/rust-lang/rust/pull/111076 enables unstable cargo feature (`public-dependency`), we need to ensure that unstable features are enabled before reading libstd Cargo.toml.
Fixes#117762
cc `@Nilstrieb`
bump few ICU4X leftover deps
implements https://github.com/rust-lang/rust/pull/117632#issuecomment-1795027801 suggestion
There no strict version dependencies between some crates, so yoke was 0.7.2, but yoke-derive left with 0.7.1, same with zerofrom, zerofrom-derive, zerovec, zerovec-derive; drops synstructure 0.12* dependency, less syn 1.* users left.
It's not clear to me (klinvill) that UserTypeProjections are produced
anymore with the removal of type ascriptions as per
https://github.com/rust-lang/rfcs/pull/3307. Furthermore, it's not clear
to me which variants of ProjectionElem could appear in such projections.
For these reasons, I'm reverting projections in UserTypeProjections to
simple strings until I can get more clarity on UserTypeProjections.
This commit includes richer projections for both Places and
UserTypeProjections. However, the tests only touch on Places. There are
also outstanding TODOs regarding how projections should be resolved to
produce Place types, and regarding if UserTypeProjections should just
contain ProjectionElem<(),()> objects as in MIR.
It was added way back in #28585 under the name `-Zkeep-mtwt-tables`. The
justification was:
> This is so that the resolution results can be used after analysis,
> potentially for tool support.
There are no uses of significance in the code base, and various Google
searches for both option names (and variants) found nothing of interest.
@petrochenkov says removing this part (and it's only part) of the
hygiene data is dubious. It doesn't seem that big, so let's just keep it
around.
rustdoc-json: Fix test so it actually checks things
After #111427, no item has a `kind` field, so these assertions could never fail. Instead, assert that those two items arn't present.
r? `@GuillaumeGomez`
Clarify UB in `get_unchecked(_mut)`
Inspired by #116915, it was unclear to me what exactly "out-of-bounds index" means in `get_unchecked`.
One could [potentially](https://rust.godbolt.org/z/hxM764orW) interpret it that `get_unchecked` is just another way to write `offset`, but I think `get_unchecked(len)` is supposed to be UB even though `.offet(len)` is well-defined (as is `.get_unchecked(..len)`), so write that more directly in the docs.
**libs-api folks**: Can you confirm whether this is what you expect this to mean? And is the situation any different for `<*const [T]>::get_unchecked`?
Update exploit mitigations documentation
Updates the rustc book with most up to date information about exploit mitigations supported by the Rust compiler.
It currently has the syntax
`current_rustc_version!(env!("CFG_RELEASE"))` where the
`env!("CFG_RELEASE")` part looks like a normal expression but it is
actually parsed and processed by the `current_rustc_version` macro.
The documented rationale for this is that you'll find it if you grep for
`env!("CFG_RELEASE")`. But I think that's of very little use -- I would
personally grep for just "CFG_RELEASE" -- and it complicates the macro,
requiring the use of `syn`.
This commit simplifies the macro.
Disable `vec_box` when using different allocators
Fixes#7114
This PR disables the `vec_box` lint when the `Box` and `Vec` use different allocators (but not when they use the same - custom - allocator).
For example - `Vec<Box<i32, DummyAllocator>>` will disable the lint, and `Vec<Box<i32, DummyAllocator>, DummyAllocator>` will not disable the lint.
In addition, the applicability of this lint has been changed to `Unspecified` due to the automatic fixes potentially breaking code such as the following:
```rs
fn foo() -> Vec<Box<i32>> { // -> Vec<i32>
vec![Box::new(1)]
}
```
It should be noted that the `if_chain->let-chains` fix has also been applied to this lint, so the diff does contain many changes.
changelog: disable `vec_box` lint when using nonstandard allocators
Emit #[inline] on derive(Debug)
While working on https://github.com/rust-lang/rust/pull/116583 I noticed that the `cross_crate_inlinable` query identifies a lot of derived `Debug` impls as a MIR body that's little more than a call, which suggests they may be a good candidate for `#[inline]`. So here I've implemented that change specifically.
It seems to provide a nice improvement to build times.
Since https://github.com/rust-lang/rust/pull/111076 enables
unstable cargo feature (`public-dependency`), we need to ensure
that unstable features are enabled before reading libstd Cargo.toml.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
check config file before prompts on `x setup`
First 2 commit moves the check of configuration existence to the first step of `x setup`. And then followed by a prompt that allows devs to decide whether to continue with the configuration override or exit bootstrap.
Closes#110471
I can revert the last commit if needed. Maybe it's just me, but I feel it's better to have those tags capitalized. If you think otherwise, please let me know so that I can revert.
Try to update parser/event doc
`TokenSource` and `TreeSink` has been refactored as part of #10765, they no longer exist in code repo. This pr tries to remove them from event module level comment to prevent confusion.
Allow configuring the parent GitHub repository
The git integration in build_helper hardcoded `rust-lang/rust` as the parent GitHub repository, and `master` as the branch name. This works great for `rust-lang/rust`, but causes problems in downstream forks like Ferrocene whenever those functions are invoked (like `./x fmt`).
In `src/stage0.json` there was already a configuration key for the name of the nightly branch, but it wasn't used by build_helper. This PR adds the `github_repository` key to the file, and requires both values to be passed to build_helper whenever a git function is called. This will allow downstream forks to tweak the values.
generator layout: ignore fake borrows
fixes#117059
We emit fake shallow borrows in case the scrutinee place uses a `Deref` and there is a match guard. This is necessary to prevent the match guard from mutating the scrutinee: fab1054e17/compiler/rustc_mir_build/src/build/matches/mod.rs (L1250-L1265)
These fake borrows end up impacting the generator witness computation in `mir_generator_witnesses`, which causes the issue in #117059. This PR now completely ignores fake borrows during this computation. This is sound as thse are always removed after analysis and the actual computation of the generator layout happens afterwards.
Only the second commit impacts behavior, and could be backported by itself.
r? types
Remove `-Z strip`.
It was stabilized as `-C strip` in November 2021. The unstable option was kept around as a temporary measure to ease the transition. Two years is more than enough!
r? `@tmandry`
