This resolves all the problems we had around "normalizing" the representation of a Scalar in case it carries a Pointer value: we can just use Pointer if we want to have a value taht we are sure is already normalized.
Use clang 12.0.1 on dist-x86_64/i686-linux
The LLD + ThinLTO __morestack bug has been fixed in 12.0.1, so
we can now update our clang version. This also means that we no
longer need to build Python 2.
Implement Mutation- and BorrowOfLayoutConstrainedField in thir-unsafeck
Since nobody has so far claimed Mutation- and BorrowOfLayoutConstrainedField in rust-lang/project-thir-unsafeck#7, I have taken the liberty of implementing them in thir-unsafeck.
r? `@LeSeulArtichaut`
CTFE engine: small cleanups
I noticed these while preparing a large PR, and figured I'd better send them ahead to not muddy the diff unnecessarily.
- remove remaining use of Pointer in Allocation API (I missed those in https://github.com/rust-lang/rust/pull/85472)
- remove unnecessary deallocate_local hack (this logic does not seem necessary any more)
r? `@oli-obk`
Simplify future incompatible reporting.
This simplifies the implementation of the future incompatible reporting system. Instead of having a separate field in the future_incompatible definition, this reuses the `FutureIncompatibilityReason` enum. It also drops the "date" field. Cargo does not use the date field, and there isn't much of a need for this to be structured, and I am skeptical that the date can be predicted reliably. The date or release version can be listed in the lint text if desired.
Fix ICE with unsized type in const pattern
Fixes#87046. The `deref_const()` query currently contains the following check:
e9a387d6cf/compiler/rustc_mir/src/const_eval/mod.rs (L191-L204)
i.e. this will cause an ICE for every unsized type except slices. An error is reported with my changes if such a type is used as a const pattern (this should not be a breaking change, since so far, this has caused an ICE).
Fix rust-analyzer install when not available.
This changes it so that `x.py install` won't fail if rust-analyzer isn't available. This was changed in #86568 to handle the case where installing on stable/beta, and `extended=true`, to skip rust-analyzer. But I neglected to update the install part to also ignore it.
Fixes#86999
stdio_locked: add tracking issue
Add the tracking issue number #86845 to the stability attributes for the implementation in #86799.
r? `@joshtriplett`
`@rustbot` label +A-io +C-cleanup +T-libs-api
Remove unstable `io::Cursor::remaining`
Adding `io::Cursor::remaining` in #86037 caused a conflict with the implementation of `bytes::Buf` for `io::Cursor`, leading to an error in nightly, see https://github.com/rust-lang/rust/issues/86369#issuecomment-867723485.
This fixes the error by temporarily removing the `remaining` function.
r? `@yaahc`
Split MaybeUninit::write into new feature gate and stabilize it
This splits off the `MaybeUninit::write` function from the `maybe_uninit_extra` feature gate into a new `maybe_uninit_write` feature gate and stabilizes it.
Earlier work to improve the documentation of the write function: #86220
Tracking issue: #63567
Fix rendering of reexported macros 2.0 and fix visibility of reexported items
So, this PR grew a bit out of focus, it does the following things:
* Fixes#86276.
* Fixes visibility display for reexported items: it now takes the visibility of the "use" statement rather than the visibility of the reexported item itself).
* Fixes the display of reexported items if "--document-private-items" option is used. Before, they were simply skipped.
* Fixes inconsistency on typedef items: they didn't display their visibility contrary to other items.
I added tests to check everything listed above.
cc `@camelid` `@ollie27` (in case one of you want to review?)
r? `@jyn514`
Improve error reporting for modifications behind `&` references
I had a look at #84210 and noticed that #85823 has effectively already fixed#84210.
However, the string matching in #85823 is _very_ crude and already breaks down when a variable name starts with `mut`. I have made this a bit more robust; further improvements could definitely be made but are complicated by the lack of information provided by an earlier pass:
ce331ee6ee/compiler/rustc_mir_build/src/build/matches/mod.rs (L2103-L2107)
I have also fixed a missing comma in the error message.
Report an error if resolution of closure call functions failed
This pull request fixes#86238. The current implementation seems to assume that resolution of closure call functions (I'm not sure what the proper term is; I mean `call` of `Fn` etc.) can never fail:
60f1a2fc4b/compiler/rustc_typeck/src/check/callee.rs (L590-L595)
But actually, it can, if the `fn`/`fn_mut`/`fn_once` lang items are not defined, or don't have an associated `call`/`call_mut`/`call_once` function, leading to the ICE described in #86238. I have therefore turned the `span_bug!()` into an error message, which prevents the ICE.
Do not suggest adding a semicolon after `?`
Fixes#87051. I have only modified `report_return_mismatched_types()`, i.e. my changes only affect suggestions to add `;` for return type mismatches, but this never makes sense after `?`, because the function cannot return `()` if `?` is used (it has to return a `Result` or an `Option`), and a semicolon won't help if the expected and actual `Err` types differ, even if the expected one is `()`.
cleanup(rustdoc): remove unused function getObjectNameById
This function was used in an earlier version, when idx's were used to serialize function inputs and outputs. That's not done any more, so removed the JS-side support for it.
[docs] Clarify behaviour of f64 and f32::sqrt when argument is negative zero
From IEEE 754 section 6.3:
> Except that squareRoot(−0) shall be −0, every numeric squareRoot result shall have a positive sign.
Rustdoc: Change all 'optflag' arguments to 'optflagmulti'
Because specifying these flags multiple times will never be discernibly different in functionality from specifying them a single time, there is no reason to fail and report an error to the user.
This might be a slightly controversial change. it's tough to say, but it's hard to imagine a case where somebody was depending on this behavior, and doing this seem actively better for the user.
This originally came up in discussion of a fix for [Cargo #8373](https://github.com/rust-lang/cargo/issues/8373), in [Cargo PR #8422](https://github.com/rust-lang/cargo/pull/8422).
The issue is that Cargo will automatically add things like `--document-private-items` to binaries, because it's the only thing that makes sense there. Then some poor user comes along and adds `--document-private-items` to their `rustdoc` flags for the project and suddenly they're getting errors for specifying a flag twice and need to track down which targets to actually add it to without getting duplicates for reasons they won't understand without deep understanding of Cargo behavior.
We're apparently hesitant to inspect `rustdoc` flags provided by the user directly in Cargo, because they're supposed to be opaque, so looking to see if it's already provided before adding it is evidently a non-starter. In trying to resolve that, one suggestion I came up with was to just change `rustdoc` to support passing the flag multiple times, because the user's intent should be clear and it's not *really* an error, so maybe this is a case of 'be permissive in what you accept'.
This PR is an attempt to do that in a straightforward manner for purposes of discussion.
