Michael Howell [Sun, 23 Oct 2022 21:48:17 +0000 (14:48 -0700)]
Rollup merge of #103402 - joshtriplett:niche-wrap-fix, r=oli-obk
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
`ty_find_init_error` assumed that `lo > 0` means the type cannot contain a
zero.
Michael Howell [Sun, 23 Oct 2022 21:48:16 +0000 (14:48 -0700)]
Rollup merge of #103254 - fmease:fix-24183, r=GuillaumeGomez
rustdoc: do not filter out cross-crate `Self: Sized` bounds
All type parameters **except `Self`** are implicitly `Sized` ([via](https://doc.rust-lang.org/nightly/std/marker/trait.Sized.html)). Previously, we disregarded the exception of `Self` and omitted cross-crate `Sized` bounds of *any* type parameter *including* `Self` when rendering.
From now on, we *do* render cross-crate `Self: Sized` bounds.
Most notably, in `std` we now finally properly render the `Sized` bound of the `Clone` trait as well as the `Self: Sized` bound on `Iterator::map`.
Michael Howell [Sun, 23 Oct 2022 21:48:15 +0000 (14:48 -0700)]
Rollup merge of #103005 - solid-rs:patch/kmc-solid/readdir-terminator, r=m-ou-se
kmc-solid: Handle errors returned by `SOLID_FS_ReadDir`
Fixes the issue where the `std::fs::ReadDir` implementaton of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets silently suppressed errors returned by the underlying `SOLID_FS_ReadDir` system function. The new implementation correctly handles all cases:
- `SOLID_ERR_NOTFOUND` indicates the end of directory stream.
- `SOLID_ERR_OK` + non-empty `d_name` indicates success.
- Some old filesystem drivers may return `SOLID_ERR_OK` + empty `d_name` to indicate the end of directory stream.
- Any other negative values (per ITRON convention) represent an error.
Michael Howell [Sun, 23 Oct 2022 21:48:14 +0000 (14:48 -0700)]
Rollup merge of #101644 - Timmmm:file_permissions_docs, r=thomcc
Document surprising and dangerous fs::Permissions behaviour on Unix
This documents the very surprising behaviour that `set_readonly(false)` will make a file *world writable* on Unix. I would go so far as to say that this function should be deprecated on Unix, or maybe even entirely. But documenting the bad behaviour is a good first step.
It turns out `libc::dirent64` is quite big—https://docs.rs/libc/0.2.135/libc/struct.dirent64.html. In #103135 this memset accounted for 0.9% of the runtime of iterating a big directory.
Almost none of the big zeroed value is ever used. We memcpy a tiny prefix (19 bytes) into it, and then read just 9 bytes (`d_ino` and `d_type`) back out. We can read exactly those 9 bytes we need directly from the original entry_ptr instead.
## History
This code got added in #93459 and tweaked in #94272 and #94750.
Prior to #93459, there was no memset but a full 280 bytes were being copied from the entry_ptr.
<table><tr><td>copy 280 bytes</td></tr></table>
This was not legal because not all of those bytes might be initialized, or even allocated, depending on the length of the directory entry's name, leading to a segfault. That PR fixed the segfault by creating a new zeroed dirent64 and copying just the guaranteed initialized prefix into it.
However this was still buggy because it used `addr_of!((*entry_ptr).d_name)`, which is considered UB by Miri in the case that the full extent of entry_ptr is not in bounds of the same allocation. (Arguably this shouldn't be a requirement, but here we are.)
The UB got fixed by #94272 by replacing `addr_of` with some pointer manipulation based on `offset_from`, but still fundamentally the same operation.
After my PR we just grab the 9 needed bytes directly from entry_ptr.
<table><tr><td>copy 9 bytes</td></tr></table>
The resulting code is more complex but I believe still worthwhile to land for the following reason. This is an extremely straightforward thing to accomplish in C and clearly libc assumes that; literally just `entry_ptr->d_name`. The extra work in comparison to accomplish it in Rust is not an example of any actual safety being provided by Rust. I believe it's useful to have uncovered that and think about what could be done in the standard library or language to support this obvious operation better.
bors [Sun, 23 Oct 2022 11:33:18 +0000 (11:33 +0000)]
Auto merge of #103431 - Dylan-DPC:rollup-oozfo89, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #101293 (Recover when unclosed char literal is parsed as a lifetime in some positions)
- #101908 (Suggest let for assignment, and some code refactor)
- #103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`)
- #103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis)
- #103249 (resolve: Revert "Set effective visibilities for imports more precisely")
- #103305 (Move some tests to more reasonable places)
Dylan DPC [Sun, 23 Oct 2022 09:50:18 +0000 (15:20 +0530)]
Rollup merge of #103249 - petrochenkov:revaddids, r=oli-obk
resolve: Revert "Set effective visibilities for imports more precisely"
In theory the change was correct, but in practice the use of import items in HIR is limited and hacky, and it expects that (effective) visibilities for all (up to) 3 IDs of the import are set to the value reflecting (effective) visibility of the whole syntactic `use` item rather than its individual components.
Dylan DPC [Sun, 23 Oct 2022 09:50:17 +0000 (15:20 +0530)]
Rollup merge of #103226 - compiler-errors:delay-if-need-infer, r=lcnr
Check `needs_infer` before `needs_drop` during HIR generator analysis
This is kinda a revival of #103036, but with the understanding that after fallback, a generator-interior type will only have `needs_infer` true if there's an error that prevented int or float variable fallback to occur (modulo region variables, which are erased).
Therefore the best choice here is to delay a bug and skip the `needs_drop` call altogether.
bors [Sun, 23 Oct 2022 09:06:39 +0000 (09:06 +0000)]
Auto merge of #103345 - Nilstrieb:diag-flat, r=compiler-errors
Flatten diagnostic slug modules
This makes it easier to grep for the slugs in the code.
See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Localization.20infra.20interferes.20with.20grepping.20for.20error for more discussion about it.
This was mostly done with a few regexes and a bunch of manual work. This also exposes a pretty annoying inconsistency for the extra labels. Some of the extra labels are defined as additional properties in the fluent message (which makes them not prefixed with the crate name) and some of them are new fluent messages themselves (which makes them prefixed with the crate name). I don't know whether we want to clean this up at some point but it's useful to know.
Matthias Krüger [Sun, 23 Oct 2022 06:14:33 +0000 (08:14 +0200)]
Rollup merge of #103399 - smoelius:unknown-lint-maybe-incorrect, r=fee1-dead
Change `unknown_lint` applicability to `MaybeIncorrect`
This small PR changes the applicability of `unknown_lint` to `MaybeIncorrect`, because the suggested lint might not be the correct one.
Here is one example where the current applicability causes a problem. Clippy has a set of internal lints guarded by a feature called `internal`. If the feature is not enabled, then the internal lints are "unknown." In that case, running `cargo clippy --fix ...` on `clippy_utils` causes lines such as the followig
https://github.com/rust-lang/rust/blob/26c96e341639102afacbbcad0dc18ad0ac71ab18/src/tools/clippy/clippy_utils/src/paths.rs#L51-L52
to be changed to
```rust
#[expect(clippy::invalid_regex)] // internal lints do not know about all external crates
pub const FUTURES_IO_ASYNCREADEXT: [&str; 3] = ["futures_util", "io", "AsyncReadExt"];
```
which is not correct.
Matthias Krüger [Sun, 23 Oct 2022 06:14:32 +0000 (08:14 +0200)]
Rollup merge of #103368 - compiler-errors:normalization-ambiguity-bug, r=oli-obk
Delay ambiguity span bug in normalize query iff not rustdoc
Oli and I decided that the compiler debt of adding another usage of `tcx.sess.opts.actually_rustdoc` is fine, because we don't really want to add more complexity to the normalize query, and moving rustdoc to use fulfill normalization (`fully_normalize`, i.e. not use the normalize query) is unnecessary overhead given that it's skipping binders and stuff.
Matthias Krüger [Sun, 23 Oct 2022 06:14:31 +0000 (08:14 +0200)]
Rollup merge of #103355 - compiler-errors:rpitit-default-check, r=oli-obk
Handle return-position `impl Trait` in traits properly in `register_hidden_type`
The bounds that we get by calling `bound_explicit_item_bounds` from an RPITIT have projections, not opaques, but when we're *registering* an opaque, we want to treat it like an opaque.
Coincidentally fixes #102688 as well, which makes sense, since that was failing because we were inferring an opaque type to be equal to itself (opaque cycle error => "cannot resolve opaque type").
Matthias Krüger [Sun, 23 Oct 2022 06:14:30 +0000 (08:14 +0200)]
Rollup merge of #103123 - compiler-errors:early-binder-iter, r=cjgillot
Introduce `subst_iter` and `subst_iter_copied` on `EarlyBinder`
Makes working with bounds lists a bit easier, which I seem to do a lot.
Specifically, means that we don't need to do `.transpose_iter().map(|(pred, _)| *pred)` every time we want to iterate through an `EarlyBinder<&'tcx [(Predicate, Span)]>` (and even then, still have to call `subst` later), which was a very awkward idiom imo.
Josh Triplett [Sat, 22 Oct 2022 14:37:46 +0000 (15:37 +0100)]
Fix wrapped valid-range handling in ty_find_init_error
Rust's niche handling allows for wrapping valid ranges with end < start;
for instance, a valid range with start=43 and end=41 means a niche of
42. Most places in the compiler handle this correctly, but
ty_find_init_error assumed that `lo > 0` means the type cannot contain a
zero.
- fix: Remove leading newline in vendor output (rust-lang/cargo#11273)
- Fix publishing with a dependency on a sparse registry (rust-lang/cargo#11268)
- Add missing edition (rust-lang/cargo#11265)
- fix(publish): Check remote git registry more than once post-publish (rust-lang/cargo#11255)
- Fix typo (rust-lang/cargo#11258)
- fix: Remove leading newline in vendor output (rust-lang/cargo#11273)
- Fix publishing with a dependency on a sparse registry (rust-lang/cargo#11268)
- Add missing edition (rust-lang/cargo#11265)
- fix(publish): Check remote git registry more than once post-publish (rust-lang/cargo#11255)
- Fix typo (rust-lang/cargo#11258)
Dylan DPC [Sat, 22 Oct 2022 10:58:09 +0000 (16:28 +0530)]
Rollup merge of #103360 - ChrisDenton:isterm-filetype, r=thomcc
Reduce false positives in msys2 detection
Currently msys2 will be detected by getting the file path and looking to see if it contains the substrings "msys-" and "-ptr" (or "cygwin-" and "-pty"). This risks false positives, especially with filesystem files and if `GetFileInformationByHandleEx` returns a [full path](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntqueryinformationfile#remarks).
This PR adds a check to see if the handle is a pipe before doing the substring search. Additionally, for "msys2-" or "cygwin-" it only checks if the file name starts with the substring rather than looking at the whole path.
Dylan DPC [Sat, 22 Oct 2022 10:58:09 +0000 (16:28 +0530)]
Rollup merge of #103346 - HeroicKatora:metadata_of_const_pointer_argument, r=dtolnay
Adjust argument type for mutable with_metadata_of (#75091)
The method takes two pointer arguments: one `self` supplying the pointer value, and a second pointer supplying the metadata.
The new parameter type more clearly reflects the actual requirements. The provenance of the metadata parameter is disregarded completely. Using a mutable pointer in the call site can be coerced to a const pointer while the reverse is not true.
In some cases, the current parameter type can thus lead to a very slightly confusing additional cast. [Example](https://github.com/HeroicKatora/static-alloc/commit/cad93775eb9adc62f744651e3abf19513e69e7d0).
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```
This could then instead be simplified to:
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = uninit.as_ptr().with_metadata_of(&**val);
```
Dylan DPC [Sat, 22 Oct 2022 10:58:08 +0000 (16:28 +0530)]
Rollup merge of #103224 - compiler-errors:semi-after-closure-in-macro, r=fee1-dead
Allow semicolon after closure within parentheses in macros
#88546 added some parsing logic that if we're parsing a closure, and we're within parentheses, and a semicolon follows, then we must be parsing something erroneous like: `f(|| a; b)`, so it replaces the closure body with an error expression. However, it's valid to parse those tokens if we're within a macro, as in #103222.
This is a bit unsatisfying fix. Is there a more robust way of checking that we're within a macro?
I would also be open to removing this "_It is likely that the closure body is a block but where the braces have been removed_" check altogether at the expense of more verbose errors, since it seems very suspicious in the first place...
From the review: https://github.com/rust-lang/rust/pull/101986#discussion_r975610611
It _seemed_ that the lint was not emitted when the `if` check failed, but _actually_ this happens already in a special case and the lint is emitted outside of this function, if this function doesn't. I've cleared up the code/comments a bit, so it's more obvious :)
bors [Sat, 22 Oct 2022 10:53:17 +0000 (10:53 +0000)]
Auto merge of #103231 - ecnelises:le_fix, r=lcnr
Remove byte swap of valtree hash on big endian
This addresses problem reported in #103183. The code was originally introduced in https://github.com/rust-lang/rust/commit/e14b34c386ad2809e937e0e6e0379c5cc5474954. (see https://github.com/rust-lang/rust/pull/96591)
On big-endian environment, this operation sequence actually put the other half from 128-bit result, thus we got different hash result on LE and BE.
bors [Sat, 22 Oct 2022 07:49:33 +0000 (07:49 +0000)]
Auto merge of #103227 - lcnr:bye-bye-unevaluated-const, r=oli-obk
stop using `ty::UnevaluatedConst` directly
best reviewed commit by commit.
simplifies #99798 because we now don't have to expand `ty::UnevaluatedConst` to `ty::Const`.
I also remember some other places where using `ty::UnevaluatedConst` directly was annoying and caused issues, though I don't quite remember what they were rn '^^
bors [Sat, 22 Oct 2022 02:28:05 +0000 (02:28 +0000)]
Auto merge of #103172 - pcwalton:deduced-param-attrs, r=oli-obk
Introduce deduced parameter attributes, and use them for deducing `readonly` on indirect immutable freeze by-value function parameters.
Introduce deduced parameter attributes, and use them for deducing `readonly` on
indirect immutable freeze by-value function parameters.
Right now, `rustc` only examines function signatures and the platform ABI when
determining the LLVM attributes to apply to parameters. This results in missed
optimizations, because there are some attributes that can be determined via
analysis of the MIR making up the function body. In particular, `readonly`
could be applied to most indirectly-passed by-value function arguments
(specifically, those that are freeze and are observed not to be mutated), but
it currently is not.
This patch introduces the machinery that allows `rustc` to determine those
attributes. It consists of a query, `deduced_param_attrs`, that, when
evaluated, analyzes the MIR of the function to determine supplementary
attributes. The results of this query for each function are written into the
crate metadata so that the deduced parameter attributes can be applied to
cross-crate functions. In this patch, we simply check the parameter for
mutations to determine whether the `readonly` attribute should be applied to
parameters that are indirect immutable freeze by-value. More attributes could
conceivably be deduced in the future: `nocapture` and `noalias` come to mind.
Adding `readonly` to indirect function parameters where applicable enables some
potential optimizations in LLVM that are discussed in [issue 103103] and [PR
103070] around avoiding stack-to-stack memory copies that appear in functions
like `core::fmt::Write::write_fmt` and `core::panicking::assert_failed`. These
functions pass a large structure unchanged by value to a subfunction that also
doesn't mutate it. Since the structure in this case is passed as an indirect
parameter, it's a pointer from LLVM's perspective. As a result, the
intermediate copy of the structure that our codegen emits could be optimized
away by LLVM's MemCpyOptimizer if it knew that the pointer is `readonly
nocapture noalias` in both the caller and callee. We already pass `nocapture
noalias`, but we're missing `readonly`, as we can't determine whether a
by-value parameter is mutated by examining the signature in Rust. I didn't have
much success with having LLVM infer the `readonly` attribute, even with fat
LTO; it seems that deducing it at the MIR level is necessary.
No large benefits should be expected from this optimization *now*; LLVM needs
some changes (discussed in [PR 103070]) to more aggressively use the `noalias
nocapture readonly` combination in its alias analysis. I have some LLVM patches
for these optimizations and have had them looked over. With all the patches
applied locally, I enabled LLVM to remove all the `memcpy`s from the following
code:
which is a significant codegen improvement over the status quo. I expect that if this optimization kicks in in multiple places even for such a simple program, then it will apply to Rust code all over the place.
bors [Fri, 21 Oct 2022 23:42:01 +0000 (23:42 +0000)]
Auto merge of #103375 - matthiaskrgr:rollup-4xrs7f2, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #102635 (make `order_dependent_trait_objects` show up in future-breakage reports)
- #103335 (Replaced wrong test with the correct mcve)
- #103339 (Fix some typos)
- #103340 (WinConsole::new is not actually fallible)
- #103341 (Add test for issue 97607)
- #103351 (Require Drop impls to have the same constness on its bounds as the bounds on the struct have)
- #103359 (Remove incorrect comment in `Vec::drain`)
- #103364 (rustdoc: clean up rustdoc-toggle CSS)
- #103370 (rustdoc: remove unused CSS `.out-of-band { font-weight: normal }`)
Matthias Krüger [Fri, 21 Oct 2022 22:14:00 +0000 (00:14 +0200)]
Rollup merge of #103335 - SarthakSingh31:issue-89008, r=jackh726
Replaced wrong test with the correct mcve
Closes #89008.
The old test was wrong and the compiler was [correctly raising an error](https://github.com/rust-lang/rust/issues/89008#issuecomment-1285128060). The bug in the issue was resolved at some point but due to the wrong test the issue was never closed.
This pr replaces that test with the correct MCVE (made by ``@jackh726).``
The error raised by the bug changed between when the bug was posted (2021-09-08) and when the MCVE [was posted](https://github.com/rust-lang/rust/issues/89008#issuecomment-950110735) (2021-10-23).
I ran them both through `nightly-2021-09-08` and they produce identical error messages. They also produce identical but different from before error messages when ran through `nightly-2021-10-23`.
<details>
<summary>Error message with <code>nightly-2021-09-08</code></summary>
The code with the original bug report:
```
error[E0277]: the size for values of type `Repr` cannot be known at compilation time
--> src/main.rs:23:43
|
23 | fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> {
| ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
| |
| this type parameter needs to be `std::marker::Sized`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `test-234234` due to previous error
```
MVCE:
```
error[E0277]: the size for values of type `Repr` cannot be known at compilation time
--> src/main.rs:30:43
|
30 | fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> {
| ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
| |
| this type parameter needs to be `std::marker::Sized`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `test-234234` due to previous error
```
</details>
<details>
<summary>Error message with <code>nightly-2021-10-23</code></summary>
The code with the original bug report:
```
error[E0271]: type mismatch resolving `<impl futures::Future as futures::Future>::Output == impl futures::Stream`
--> src/main.rs:23:43
|
19 | type LineStream<'a, Repr> = impl Stream<Item = Repr>;
| ------------------------ the expected opaque type
...
23 | fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found struct `futures::stream::Empty`
|
= note: expected opaque type `impl futures::Stream`
found struct `futures::stream::Empty<_>`
error: could not find defining uses
--> src/main.rs:19:33
|
19 | type LineStream<'a, Repr> = impl Stream<Item = Repr>;
| ^^^^^^^^^^^^^^^^^^^^^^^^
For more information about this error, try `rustc --explain E0271`.
error: could not compile `test-234234` due to 2 previous errors
```
MCVE:
```
error[E0271]: type mismatch resolving `<impl Future as Future>::Output == impl Stream`
--> src/main.rs:30:43
|
28 | type LineStream<'a, Repr> = impl Stream<Item = Repr>;
| ------------------------ the expected opaque type
29 | type LineStreamFut<'a, Repr> = impl Future<Output = Self::LineStream<'a, Repr>>;
30 | fn line_stream<'a, Repr>(&'a self) -> Self::LineStreamFut<'a, Repr> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found struct `Empty`
|
= note: expected opaque type `impl Stream`
found struct `Empty<_>`
error: could not find defining uses
--> src/main.rs:28:33
|
28 | type LineStream<'a, Repr> = impl Stream<Item = Repr>;
| ^^^^^^^^^^^^^^^^^^^^^^^^
For more information about this error, try `rustc --explain E0271`.
error: could not compile `test-234234` due to 2 previous errors
```
</details>
Matthias Krüger [Fri, 21 Oct 2022 22:13:59 +0000 (00:13 +0200)]
Rollup merge of #102635 - lcnr:incoherent_auto_trait_objects, r=jackh726
make `order_dependent_trait_objects` show up in future-breakage reports
tried to change it to a hard error in #102474 but breaking the more than 1000 dependents of `traitobject` doesn't feel great :sweat_smile:
This lint has existed since more than 3 years now and the way this is currently implemented is buggy and will break with #102472. imo we should upgrade it to also report for dependencies and maybe also backport this to beta. Then after maybe 2-3 stable versions I would like to finally convert this lint to a hard error.
bors [Fri, 21 Oct 2022 20:59:03 +0000 (20:59 +0000)]
Auto merge of #101263 - lopopolo:lopopolo/c-unwind-fn-ptr-impls, r=thomcc
Add default trait implementations for "c-unwind" ABI function pointers
Following up on #92964, only add default trait implementations for the `c-unwind` family of function pointers. The previous attempt in #92964 added trait implementations for many more ABIs and ran into concerns regarding the increase in size of the libcore rlib.
An attempt to abstract away function pointer types behind a unified trait to reduce the duplication of trait impls is being discussed in #99531 but this change looks to be blocked on a lang MCP.
Following `@RalfJung's` suggestion in https://github.com/rust-lang/rust/pull/99531#issuecomment-1233440142, this commit is another cut at #92964 but it _only_ adds the impls for `extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.
I am interested in landing this patch to unblock the stabilization of the `c_unwind` feature.
bors [Fri, 21 Oct 2022 18:09:03 +0000 (18:09 +0000)]
Auto merge of #101077 - sunshowers:signal-mask-inherit, r=sunshowers
Change process spawning to inherit the parent's signal mask by default
Previously, the signal mask was always reset when a child process is
started. This breaks tools like `nohup` which expect `SIGHUP` to be
blocked for all transitive processes.
With this change, the default behavior changes to inherit the signal mask.
This also changes the signal disposition for `SIGPIPE` to only be changed if the `#[unix_sigpipe]` attribute isn't set.
bors [Fri, 21 Oct 2022 15:27:56 +0000 (15:27 +0000)]
Auto merge of #98450 - lqd:doc-metadata, r=lqd,GuillaumeGomez
Remove more attributes from metadata
A lot of the attributes that are currently stored in the metadata aren't used at all. The biggest metadata usage comes from the doc attributes currently but they are needed by rustdoc so we only removed the ones that cannot be used in downstream crates (doc comments on private items).
Andreas Molzer [Fri, 21 Oct 2022 12:05:45 +0000 (14:05 +0200)]
Argument type for mutable with_metadata_of (#75091)
The method takes two pointer arguments: one `self` supplying the pointer
value, and a second pointer supplying the metadata.
The new parameter type more clearly reflects the actual requirements.
The provenance of the metadata parameter is disregarded completely.
Using a mutable pointer in the call site can be coerced to a const
pointer while the reverse is not true.
An example of the current use:
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = val as *const _ as *mut T;
let ptr = uninit.as_ptr().with_metadata_of(ptr);
```
This could then instead be simplified to:
```rust
// Manually taking an unsized object from a `ManuallyDrop` into another allocation.
let val: &core::mem::ManuallyDrop<T> = …;
let ptr = uninit.as_ptr().with_metadata_of(&**val);
```
bors [Fri, 21 Oct 2022 12:41:09 +0000 (12:41 +0000)]
Auto merge of #103344 - Dylan-DPC:rollup-d1rpfvx, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #102287 (Elaborate supertrait bounds when triggering `unused_must_use` on `impl Trait`)
- #102922 (Filtering spans when emitting json)
- #103051 (translation: doc comments with derives, subdiagnostic-less enum variants, more derive use)
- #103111 (Account for hygiene in typo suggestions, and use them to point to shadowed names)
- #103260 (Fixup a few tests needing asm support)
- #103321 (rustdoc: improve appearance of source page navigation bar)
Failed merges:
- #103209 (Diagnostic derives: allow specifying multiple alternative suggestions)
projects / rust.git / log