Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations
Currently, the `#[derive]` attribute always injects an `#[allow(unused_qualifications)]` attribute in the generated implementation. This results in an error when a derive is used in combination with `#![forbid(unused_qualifications)]`, because the `forbid` rule by definition cannot be overridden by `allow`.
It appears that the original issue that prompted the inclusion of `#[allow(unused_qualifications)]` (#19102) is no longer present in the current stable release, and the associated [test case](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-19102.rs) still passes, so the `allow` is simply removed here.
Fixes#71898.
Fix a numerical underflow in tuple wrap suggestion
Fixes#99482
I'm a clown, I rewrote the arg mismatch algo to use well-typed indices to avoid things like this, but then I added my own indexing bug, lol.
Add flag to configure `noalias` on `Box<T>`
The aliasing rules of `Box<T>` are still not decided, but currently, `Box<T>` is unique and gets `noalias`. To aid making an informed decision about the future of `Box<T>`, this PR adds a flag `-Zbox-noalias` to configure `noalias` for `Box<T>` (for example, for benchmarking). The same flag already exists for `&mut T` `noalias`, where it was added because it was the problem of various miscompilations in LLVM.
For more information, see rust-lang/unsafe-code-guidelines#326
Formalize defining_use_anchor
This tackles issue #57961
Introduces new enum called `DefiningAnchor` that replaces `Option<LocalDefId>` of `defining_use_anchor`. Now every use of it is explicit and exhaustively matched, catching errors like one in the linked issue. This is not a perfect fix but it's a step in the right direction.
r? `@oli-obk`
Do not allow typeck children items to constrain outer RPITs
Fixes#99073 in a simpler and more conservative way than #99079. Simply raise a mismatched types error if we try to constrain an RPIT in an item that isn't the RPIT's parent.
r? `@oli-obk`
stdlib support for Apple WatchOS
This is a follow-up to https://github.com/rust-lang/rust/pull/95243 (Add Apple WatchOS compiler targets) that adds stdlib support for Apple WatchOS.
`@deg4uss3r`
`@nagisa`
When an unexpected meta item is provided to `#[stable]`, the diagnostic
lists "since" and "note" as expected meta-items, however the surrounding
code actually expects "feature" and "since".
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 5 pull requests
Successful merges:
- #98784 (Suggest returning local on "expected `ty`, found `()`" due to expr-less block)
- #98916 (Windows: Use `FindFirstFileW` for getting the metadata of locked system files)
- #99433 (Erase regions before comparing signatures of foreign fns.)
- #99452 (int_macros was only using to_xe_bytes_doc and not from_xe_bytes_doc)
- #99481 (Add regression test for #71547)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Erase regions before comparing signatures of foreign fns.
Fixes https://github.com/rust-lang/rust/issues/99276
The version with explicit lifetimes is probably tracked in another bug, but I could not find it.
Windows: Use `FindFirstFileW` for getting the metadata of locked system files
Fixes#96980
Usually opening a file handle with access set to metadata only will always succeed, even if the file is locked. However some special system files, such as `C:\hiberfil.sys`, are locked by the system in a way that denies even that. So as a fallback we try reading the cached metadata from the directory.
Note that the test is a bit iffy. I don't know if `hiberfil.sys` actually exists in the CI.
r? rust-lang/libs
Suggest returning local on "expected `ty`, found `()`" due to expr-less block
Putting this up for _initial_ review. Notably, this doesn't consider if the value has possibly been moved, or whether the type is `Copy`. It also provides a structured suggestion if there's one "preferred" binding that matches the type (i.e. one binding in the block or its parent), otherwise it just points them out if there's fewer than 4 of them.
Fixes#98177
r? `@estebank`
Enable check-cfg in stage0
Now that the bootstrap cargo supports `rustc-check-cfg` we can now enable it with `-Zcheck-cfg=output` and use it in `rustc_llvm` to unblock `--check-cfg` support in stage0.
r? `@Mark-Simulacrum`
Update cargo
9 commits in 8827baaa781b37872134c1ba692a6f0aeb37890e..d8d30a75376f78bb0fabe3d28ee9d87aa8035309
2022-07-14 02:56:51 +0000 to 2022-07-19 13:59:17 +0000
- docs: fixing minor error in the default timing report filename (rust-lang/cargo#10879)
- Stabilize `--crate-type` flag for `cargo rustc` (rust-lang/cargo#10838)
- Stabilize `-Zmultitarget` (rust-lang/cargo#10766)
- Clean up leftover in unstable documentation (rust-lang/cargo#10874)
- Normalize path for `cargo vendor` output (rust-lang/cargo#10668)
- add a reason to `masquerade_as_nightly_cargo` so it is searchable (rust-lang/cargo#10868)
- Allow '.' in workspace.default-members in non-virtual workspaces. (rust-lang/cargo#10784)
- remove`.masquerade_as_nightly_cargo()` from various tests the no longer need it (rust-lang/cargo#10867)
- remove `.masquerade_as_nightly_cargo()` from build_script_extra_link_arg.rs (rust-lang/cargo#10866)
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
Let's avoid using two different terms for the same thing -- let's just call it "provenance" everywhere.
In Miri, provenance consists of an AllocId and an SbTag (Stacked Borrows tag), which made this even more confusing.
Improve the function pointer docs
This is #97842 but for function pointers instead of tuples. The concept is basically the same.
* Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
interpret: make some large types not Copy
Also remove some unused trait impls (mostly HashStable).
This didn't find any unnecessary copies that I managed to avoid, but it might still be better to require explicit clone for these types? Not sure.
r? `@oli-obk`