Rollup of 12 pull requests
Successful merges:
- #61535 (Coherence test when a generic type param has a default value from an associated type)
- #62274 (rustc_mir: follow FalseUnwind's real_target edge in qualify_consts.)
- #62431 (Add messages to `Option`'s and `Result`'s `must_use` annotation for `is_*`)
- #62453 (in which we suggest anonymizing single-use lifetimes in paths )
- #62568 (Replace unsafe_destructor_blind_to_params with may_dangle)
- #62578 (Add test for #49919)
- #62595 (Document that the crate keyword refers to the project root)
- #62599 (move mem::uninitialized deprecation back by 1 release, to 1.39)
- #62605 (Emit dropped unemitted errors to aid in ICE debugging)
- #62607 (Correctly break out of recovery loop)
- #62608 (`async unsafe fn` tests)
- #62623 (downgrade indirect_structural_match lint to allow)
Failed merges:
r? @ghost
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.
Document that the crate keyword refers to the project root
👋 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.
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.
Closes#34761
rustc_mir: follow FalseUnwind's real_target edge in qualify_consts.
As far as I can tell, this was accidentally omitted from #47802.
Fixes#62272.
r? @matthewjasper or @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.
This is a way to address the regression aspect of rust-lang/rust#62614 in the
short term without actually fixing the bug. (My thinking is that the bug that
this lint detects has gone undetected for this long, it can wait a bit longer
until I or someone else has a chance to put in a proper fix that accounts for
rust-lang/rust#62614.)
[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. :)
r? @Manishearth
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.
Closes#49269
cc #61142#48771#40108
Remove rustc_mir dependency from rustc_borrowck
Also renames `rustc_borrowck` to `rustc_ast_borrowck` and removes all error reporting from it.
cc #59193
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.
Fixes: rust-lang/rust#62314
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
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.
