Sync `rust-analyzer`, add `rust-analyzer-proc-macro-srv` binary to Rustc component
As discussed earlier with `@jyn514` and `@pietroalbini,` I'm also going to use this PR to have `dist::Rustc` build the `rust-analyzer-proc-macro-srv` binary introduced in:
* https://github.com/rust-lang/rust-analyzer/pull/12871
mem::uninitialized: mitigate many incorrect uses of this function
Alternative to https://github.com/rust-lang/rust/pull/98966: fill memory with `0x01` rather than leaving it uninit. This is definitely bitewise valid for all `bool` and nonnull types, and also those `Option<&T>` that we started putting `noundef` on. However it is still invalid for `char` and some enums, and on references the `dereferenceable` attribute is still violated, so the generated LLVM IR still has UB -- but in fewer cases, and `dereferenceable` is hopefully less likely to cause problems than clearly incorrect range annotations.
This can make using `mem::uninitialized` a lot slower, but that function has been deprecated for years and we keep telling everyone to move to `MaybeUninit` because it is basically impossible to use `mem::uninitialized` correctly. For the cases where that hasn't helped (and all the old code out there that nobody will ever update), we can at least mitigate the effect of using this API. Note that this is *not* in any way a stable guarantee -- it is still UB to call `mem::uninitialized::<bool>()`, and Miri will call it out as such.
This is somewhat similar to https://github.com/rust-lang/rust/pull/87032, which proposed to make `uninitialized` return a buffer filled with 0x00. However
- That PR also proposed to reduce the situations in which we panic, which I don't think we should do at this time.
- The 0x01 bit pattern means that nonnull requirements are satisfied, which (due to references) is the most common validity invariant.
`@5225225` I hope I am using `cfg(sanitize)` the right way; I was not sure for which ones to test here.
Cc https://github.com/rust-lang/rust/issues/66151
Fixes https://github.com/rust-lang/rust/issues/87675
Add some comments to the docs issue template to clarify
Newcomers may not know that some docs have their own repositories (e.g. the book, the reference), or that the documentation and rustdoc are different.
Actually, this template was used to report an issue related to the book: https://github.com/rust-lang/rust/issues/99699
This adds some comments to clarify the above things. I'm not sure if the current wording is the best, any suggestion would be helpful!
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
lint: add bad opt access internal lint
Prompted by [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/sess.2Ecrate_types.28.29.20vs.20sess.2Eopts.2Ecrate_types/near/290682847).
Some command-line options accessible through `sess.opts` are best accessed through wrapper functions on `Session`, `TyCtxt` or otherwise, rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed through a wrapper function so that this is prohibited. Options are annotated with a new attribute `rustc_lint_opt_deny_field_access` which can specify the error message (i.e. "use this other function instead") to be emitted.
A simpler alternative would be to simply rename the options in the option type so that it is clear they should not be used, however this doesn't prevent uses, just discourages them. Another alternative would be to make the option fields private, and adding accessor functions on the option types, however the wrapper functions sometimes rely on additional state from `Session` or `TyCtxt` which wouldn't be available in an function on the option type, so the accessor would simply make the field available and its use would be discouraged too.
**Leave a comment if there's an option I should add this to.**
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Fix slice::ChunksMut aliasing
Fixes https://github.com/rust-lang/rust/issues/94231, details in that issue.
cc `@RalfJung`
This isn't done just yet, all the safety comments are placeholders. But otherwise, it seems to work.
I don't really like this approach though. There's a lot of unsafe code where there wasn't before, but as far as I can tell the only other way to uphold the aliasing requirement imposed by `__iterator_get_unchecked` is to use raw slices, which I think require the same amount of unsafe code. All that would do is tie the `len` and `ptr` fields together.
Oh I just looked and I'm pretty sure that `ChunksExactMut`, `RChunksMut`, and `RChunksExactMut` also need to be patched. Even more reason to put up a draft.
Remove let-chain close brace check.
#98633 added some checks to forbid let-expressions that aren't in a let chain. This check looks at the preceding token to determine if it is a valid let-chain position. One of those tokens it checks is the close brace `}`. However, to my understanding, it is not possible for a let chain to be preceded by a close brace. This PR removes the check to avoid any confusion.
This is a followup to the discussion at https://github.com/rust-lang/rust/pull/98633#pullrequestreview-1030962803. It wasn't clear what issues the original PR ran into, but I have run the full set of CI tests and nothing failed. I also can't conceive of a situation where this would be possible. This doesn't reject any valid code, I'm just removing it to avoid confusion to anyone looking at this code in the future.
This attribute now does more than just place noalias on the return,
and has specific requirements for the signature.
Drop the test entirely, as we already check __rust_alloc attributes
in other codegen tests.
Replace the separate AbortCodegenOnDrop guard by integrating this
functionality into OngoingCodegen (or rather, the Coordinator part
of it). This ensures that we send a CodegenAborted message and
wait for workers to finish even if the panic occurs outside
codegen_crate() (e.g. inside join_codegen()).
This requires some minor changes to the handling of CodegenAborted,
as it can now occur when the main thread is LLVMing rather than
Codegenning.
This builds `src/tools/rust-analyzer/crates/proc-macro-srv-cli` and
ships it as part of Rustc's dist component. This allows rust-analyzer's
proc macro support to work on all rustc versions (stable, beta and
nightly) starting now.
Rollup of 5 pull requests
Successful merges:
- #99079 (Check that RPITs constrained by a recursive call in a closure are compatible)
- #99704 (Add `Self: ~const Trait` to traits with `#[const_trait]`)
- #99769 (Sync rustc_codegen_cranelift)
- #99783 (rustdoc: remove Clean trait impls for more items)
- #99789 (Refactor: use `pluralize!`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a `platform-support` entry to the rustc-docs for the different
`*-unknown-uefi` targets. This describes in detail how this platform
works, a few basic examples, and how to compile for the platform.
Red Hat is sponsoring my work on this platform, so I am putting myself
down as target maintainer. Co-maintainers are more than welcome to join
me in the effort. Communication is going on off-list to coordinate the
different efforts.
Note that the ultimate goal is to move the UEFI targets to Tier-2 so
bootloaders can be more easily supported in commercial products. This
documentation is the first step towards that goal, but should be a
viable documentation even for the current Tier-3 status of the targets.
I also want to point out that there is an ongoing GSoC-effort to port
the rust standard library to UEFI (by Ayush Singh). While this work is
not necessarily required to get to Tier-2, we definitely should
coordinate the efforts and update the documentation as soon as any such
ports are merged.
Note that the targets are already used by multiple commercial and non
commercial production systems, including, but not limited to:
* Tianocore-EDK2 (Official UEFI SDK by Intel) comes with rust support
in its staging repository (not part of any release, yet).
(https://github.com/tianocore/edk2-staging/tree)
* Intel's research program "Project Mu" uses the rust UEFI targets to
show possible future replacements for Tianocore-EDK2.
* The Rust OS "Redox" uses the UEFI targets for its bootloader.
(https://www.redox-os.org/)
* The hugely popular in-depth documentation of OS development in Rust
by Philipp Oppermann uses the UEFI targets.
(https://os.phil-opp.com/)
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
