Rollup merge of #62599 - RalfJung:uninit, r=cramertj
move mem::uninitialized deprecation back by 1 release, to 1.39
As per discussion at https://github.com/rust-lang/rust/issues/53491#issuecomment-509271182. Three releases also agrees with the precedent from `trim_left/right`. Three releases means that even nightly users (including rustc itself) get a full cycle from when the announcement is made in the stable release to when nightly starts to warn.
Rollup merge of #62595 - ngoldbaum:path-clarity-doc, r=Centril
Document that the crate keyword refers to the project root
:wave: this is my first rust contribution so I hope I'm doing everything correctly. Help very much appreciated if I'm not.
As far as I can tell this use of `crate` is only documented [in the edition guide for rust 2018](https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#the-crate-keyword-refers-to-the-current-crate). However it should probably be in the documentation for the `crate` keyword itself. This adds that documentation.
Rollup merge of #62568 - lzutao:replace_may_dangle, r=matthewjasper
Replace unsafe_destructor_blind_to_params with may_dangle
This PR will completely remove support for `#[unsafe_destructor_blind_to_params]` attribute,
which is deprecated in #38970 by `[may_dangle]` unsafe attribute.
Rollup merge of #61535 - ohadravid:test-generic-with-default-assiociated-type-re-rebalance-coherence, r=nikomatsakis
Coherence test when a generic type param has a default value from an associated type
A followup on #61400.
Before `re_rebalance_coherence`, this fails to compile (even though it should be accepted).
`re_rebalance_coherence` had no direct test for this, and I wanted to (a) make sure it doesn't regress in the future and (b) get it on record that this is actually the intended behavior.
Auto merge of #61462 - GuillaumeGomez:fix-local-storage, r=Manishearth
[rustdoc] Fix storage usage when disabled
Fixes #61239.
@starblue: Can you give a try to this change please? I tried on chrome and firefox and both worked so if you're using another web browser, that might be useful. :)
Auto merge of #62549 - ehuss:update-cargo-vendor, r=alexcrichton
Update cargo-vendor usage
This contains a variety of updates to clean up the usage of cargo-vendor.
- Remove the install step for the old cargo-vendor now that it is built-in to cargo and available in the stage0 install.
- Update installation instructions, dealing with vendoring. The current instructions of running `sudo ./x.py install` is broken, it will almost always fail (since the vendor directory doesn't exist). Since the steps for properly handling this are numerous, I'm recommending removing the suggestion to use `sudo` altogether.
- If the sudo-forced-vendoring detects that the vendor directory is not available, abort with instructions on how to fix.
- Now that cargo-vendor is built-in, automatically run it if it looks like it is needed.
- Update instructions on how to install cargo.
- Remove the unused markdown link references in README/CONTRIBUTING. This reverts most of #44935. These references don't do anything if they are unused.
Auto merge of #62580 - Centril:rollup-remihe0, r=Centril
Rollup of 7 pull requests
Successful merges:
- #61665 (core: check for pointer equality when comparing Eq slices)
- #61923 (Prerequisites from dep graph refactoring #2)
- #62270 (Move async-await tests from run-pass to ui)
- #62425 (filedesc: don't use ioctl(FIOCLEX) on Linux)
- #62476 (Continue refactoring macro expansion and resolution)
- #62519 (Regression test for HRTB bug (issue 30786).)
- #62557 (Fix typo in libcore/intrinsics.rs)
Rollup merge of #62476 - petrochenkov:expref, r=matthewjasper
Continue refactoring macro expansion and resolution
This PR continues the work started in https://github.com/rust-lang/rust/pull/62042.
It contains a set of more or less related refactorings with the general goal of making things simpler and more orthogonal.
Along the way most of the issues uncovered in https://github.com/rust-lang/rust/pull/62086 are fixed.
The PR is better read in per-commit fashion with whitespace changes ignored.
I tried to leave some more detailed commit messages describing the motivation behind the individual changes.
Rollup merge of #62425 - cyphar:linux-cloexec-use-fcntl, r=alexcrichton
filedesc: don't use ioctl(FIOCLEX) on Linux
All `ioctl(2)`s will fail on `O_PATH` file descriptors on Linux (because
they use `&empty_fops` as a security measure against `O_PATH` descriptors
affecting the backing file).
As a result, `File::try_clone()` and various other methods would always
fail with `-EBADF` on `O_PATH` file descriptors. The solution is to simply
use `F_SETFD` (as is used on other unices) which works on `O_PATH`
descriptors because it operates through the `fnctl(2)` layer and not
through `ioctl(2)`s.
Since this code is usually only used in strange error paths (a broken or
ancient kernel), the extra overhead of one syscall shouldn't cause any
dramas. Most other systems programming languages also use the fnctl(2)
so this brings us in line with them.
Rollup merge of #61665 - aschampion:slice-eq-ptr, r=sfackler
core: check for pointer equality when comparing Eq slices
Because `Eq` types must be reflexively equal, an equal-length slice to the same memory location must be equal.
This is related to #33892 (and #32699) answering this comment from that PR:
> Great! One more easy question: why does this optimization not apply in the non-BytewiseEquality implementation directly above?
Because slices of non-reflexively equal types (like `f64`) are not equal even if it's the same slice. But if the types are `Eq`, we can use this same-address optimization, which this PR implements. Obviously this changes behavior if types violate the reflexivity condition of `Eq`, because their impls of `PartialEq` will no longer be called per-item, but 🤷♂ .
It's not clear how often this optimization comes up in the real world outside of the same-`&str` case covered by #33892, so **I'm requesting a perf run** (on MacOS today, so can't run `rustc_perf` myself). I'm going ahead and making the PR on the basis of being surprised things didn't already work this way.
This is my first time hacking rust itself, so as a perf sanity check I ran `./x.py bench --stage 0 src/lib{std,alloc}`, but the differences were noisy.
To make the existing specialization for `BytewiseEquality` explicit, it's now a supertrait of `Eq + Copy`. `Eq` should be sufficient, but `Copy` was included for clarity.
Auto merge of #62561 - Centril:rollup-5pxj3bo, r=Centril
Rollup of 5 pull requests
Successful merges:
- #62275 (rustc_mir: treat DropAndReplace as Drop + Assign in qualify_consts.)
- #62465 (Sometimes generate storage statements for temporaries with type `!`)
- #62481 (Use `fold` in `Iterator::last` default implementation)
- #62493 (#62357: doc(ptr): add example for {read,write}_unaligned)
- #62532 (Some more cleanups to syntax::print)
expand: Merge `expand_{bang,attr,derive}_invoc` into a single function
It's more convenient to have all this highly related stuff together on one screen (for future refactorings).
The `expand_invoc` function is compact enough now, after all the previous refactorings.
hygiene: Make sure each `Mark` has an associated expansion info
The root expansion was missing one.
Expansions created for "derive containers" (see one of the next commits for the description) also didn't get expansion info.
Use variant names rather than descriptions for identifying desugarings in `#[rustc_on_unimplemented]`.
Both are highly unstable, but variant name is at least a single identifier.
hygiene: Introduce a helper method for creating new expansions
Creating a fresh expansion and immediately generating a span from it is the most common scenario.
Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly.
And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
expand: Do not overwrite existing `ExpnInfo` when injecting derive markers
Create a fresh expansion for them instead - this is the usual way to allow unstable features for generated/desugared code.
Fixes https://github.com/rust-lang/rust/issues/52363
resolve: Fix access to extern and stdlib prelude from opaque macros
Ok, it's hard to explain what happens, but identifier's hygienic contexts need to be "adjusted" to modules/scopes before they are resolved in them.
To be resolved in all kinds on preludes the identifier needs to be adjusted to the root expansion (aka "no expansion").
Previously this was done for the `macro m() { ::my_crate::foo }` case, but forgotten for all other cases.
resolve: Divide macro path resolution into speculative and error reporting parts
Also move macro stability checking closer to other checks performed on obtained resolutions.
Tighten the stability spans as well, it is an error to *refer* to and unstable entity in any way, not only "call" it.
resolve/expand: Catch macro kind mismatches early in resolve
This way we are processing all of them in a single point, rather than separately for each syntax extension kind.
Also, the standard expected/found wording is used.
Create real working and registered (even if dummy) `SyntaxExtension`s for them.
This improves error recovery and allows to avoid all special cases for proc macro stubs (except for the error on use, of course).
The introduced dummy `SyntaxExtension`s can be used for any other inappropriately resolved macros as well.
syntax: Make def-site span mandatory in ExpnInfo/MacroBacktrace/DiagnosticSpanMacroExpansion
We have to deal with dummy spans anyway
Remove def-site span from expander interfaces.
It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
It was used to choose whether to apply derive markers like `#[rustc_copy_clone_marker]` or not,
but it was called before all the data required for resolution is available, so it could work incorrectly in some corner cases (like user-defined derives name `Copy` or `Eq`).
Delay the decision about markers until the proper resolution results are available instead.
Remove unnecessary expansions created by `#[test_case/test/bench]`
The expansions were created to allow unstable things inside `#[test_case/test/bench]`, but that's not a proper way to do that.
Put the required `allow_internal_unstable`s into the macros' properties instead.
Rollup merge of #62275 - eddyb:const-drop-replace, r=pnkfelix
rustc_mir: treat DropAndReplace as Drop + Assign in qualify_consts.
This slipped through the cracks and never got implemented (thankfully that just meant it was overly conservative and didn't allow assignments that don't *actually* drop the previous value).
Fixes #62273.
All ioctl(2)s will fail on O_PATH file descriptors on Linux (because
they use &empty_fops as a security measure against O_PATH descriptors
affecting the backing file).
As a result, File::try_clone() and various other methods would always
fail with -EBADF on O_PATH file descriptors. The solution is to simply
use F_SETFD (as is used on other unices) which works on O_PATH
descriptors because it operates through the fnctl(2) layer and not
through ioctl(2)s.
Since this code is usually only used in strange error paths (a broken or
ancient kernel), the extra overhead of one syscall shouldn't cause any
dramas. Most other systems programming languages also use the fnctl(2)
so this brings us in line with them.
Auto merge of #62339 - pnkfelix:issue-61188-use-visitor-for-structural-match-check, r=nikomatsakis
use visitor for #[structural_match] check
This changes the code so that we recur down the structure of a type of a const (rather than just inspecting at a shallow one or two levels) when we are looking to see if it has an ADT that did not derive `PartialEq` and `Eq`.