Make stage2 rustdoc and proc-macro-srv disableable in x.py install
Rustdoc will build if `[build] tools = ["rustdoc"]` is set, and rust-analyzer-proc-macro-srv will build if `[build] tools = ["rust-analyzer"]` is set.
On my machine skipping these tools speeds up `x.py install` from 7m15s to 6m08s (0m43s for rustdoc and 0m24s for rust-analyzer-proc-macro-srv). This is a significant speedup, since I never use rust-analyzer-proc-macro-srv, and I practically never need to use a custom build of rustdoc.
BPF: Disable atomic CAS
Enabling CAS for BPF targets (https://github.com/rust-lang/rust/pull/105708) breaks the build of core library.
The failure occurs both when building rustc for BPF targets and when
building crates for BPF targets with the current nightly.
The LLVM BPF backend does not correctly lower all `atomicrmw` operations
and crashes for unsupported ones.
Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF
backend first.
Fixes#106795
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
rustc_metadata: Encode `doc(hidden)` flag to metadata
To retrieve these flags rustdoc currently has to mass decode full attributes for items in the whole crate tree, so it's better to pre-compute it in advance.
This is especially important for short-term performance of https://github.com/rust-lang/rust/pull/107054 because resolver cannot use memoization of query results yet.
Consider doc(alias) when providing typo suggestions
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a similar name" help text, because the point where we choose and emit a suggestion is different from where we gather the suggestions. Changes have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but generally only if there is no candidate that matches based on the existing Levenshtein methodology.
Fixes#83968.
Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type.
ACP: rust-lang/libs-team#162
Reviving #79665.
I want to get this merged this time; this does not contain changes (apart from very minor changes in comments/docs).
See #79665 for further description of the PR. The only “unresolved” points that led to that PR being closed, AFAICT, were
* The desire to also implement a `Rc::into_inner` function
* however, this can very well also happen as a subsequent PR
* Possible need for further discussion on the naming “`into_inner`” (?)
* `into_inner` seems fine to me; also, this PR introduces unstable API, and names can be changed later, too
* ~~I don't know if a tracking issue for the feature flag is supposed to be opened before or after this PR gets merged (if *before*, then I can add the issue number to the `#[unstable…]` attribute)~~ There is a [tracking issue](https://github.com/rust-lang/rust/issues/106894) now.
I say “unresolved” in quotation marks because from my point of view, if reviewers agree, the PR can be merged immediately and as-is :-)
...and remove it from `PointeeInfo`, which isn't meant for this.
There are still various places (marked with FIXMEs) that assume all pointers
have the same size and alignment. Fixing this requires parsing non-default
address spaces in the data layout string, which will be done in a followup.
there were fixmes for this already
i am about to remove is_ptr (since callers need to properly distinguish
between pointers in different address spaces), so might as well do this
at the same time
This means that
```rust
impl Foo {
#[doc(alias = "quux")]
fn bar(&self) {}
}
fn main() {
(Foo {}).quux();
}
```
will suggest `bar`. This currently uses the "there is a method with a
similar name" help text, because the point where we choose and emit a
suggestion is different from where we gather the suggestions. Changes
have mainly been made to the latter.
The selection code will now fall back to aliased candidates, but
generally only if there is no candidate that matches based on the
existing Levenshtein methodology.
Fixes#83968.
Do not use box syntax in `std`
See #94970 and #49733. About half of the `box` instances in `std` do not even need to allocate, the other half can simply be replaced with `Box::new`.
`@rustbot` label +T-libs
r? rust-lang/libs
Update LLVM to 15.0.7
This commit pulls in rust-lang/llvm-project#143 which updates the LLVM version used by rustc to 15.0.7, namely pulling in https://reviews.llvm.org/D136110 which is needed for some work I'm working on with wasm.
Rollup of 8 pull requests
Successful merges:
- #107102 (Implement some more predicates in the new solver)
- #107111 (Fix missing arguments issues and copy-paste bug for fluent)
- #107114 (Add note about absolute paths to Path::join)
- #107127 (Enable sanitizers for s390x-linux)
- #107152 (Migrate scraped-examples top and bottom "borders" to CSS variables)
- #107170 (Add myself to .mailmap)
- #107174 (rustdoc: Use `DefId(Map,Set)` instead of `FxHash(Map,Set)`)
- #107180 (Remove unnecessary `&format!`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Use `DefId(Map,Set)` instead of `FxHash(Map,Set)`
Not all uses are converted, a few cases iterating through maps/sets and requiring nontrivial changes are kept.
cc https://github.com/rust-lang/rust/pull/106977
Enable sanitizers for s390x-linux
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan) in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
Add note about absolute paths to Path::join
The note already exists on `PathBuf::push`, but I think it is good to have it on `Path::join` as well since it can cause issues if you are not careful with your input.
Implement some more predicates in the new solver
Implement a few more goals. The subtype goal specifically is important, since it's required for this code to compile:
```
fn main() {
let mut x = vec![];
x.push(1i32);
}
```
(I think we emit a subtype goal here because of coercion).
Drive-by: Also implements `--compare-mode=next-solver` -- I've been using this locally a lot to find out what works and what doesn't. I'm also happy to split this out into another PR.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #103418 (Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report)
- #106113 (llvm-wrapper: adapt for LLVM API change)
- #106144 (Improve the documentation of `black_box`)
- #106578 (Label closure captures/generator locals that make opaque types recursive)
- #106749 (Update cc to 1.0.77)
- #106935 (Fix `SingleUseLifetime` ICE)
- #107015 (Re-enable building rust-analyzer on riscv64)
- #107029 (Add new bootstrap members to triagebot.toml)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add new bootstrap members to triagebot.toml
```@ozkanonur``` if you want to be assigned to review PRs too, just post a message to this thread.
Should a `T-bootstrap` label be created, since `src/tools/tidy` is assigned to the `bootstrap` members, but labeled `A-testsuite` (and not `A-bootstrap`) ?
cc ```@jyn514```
Re-enable building rust-analyzer on riscv64
It was disabled in #75103 due to an LLVM bug, but followup comments have
confirmed that it builds fine on Fedora with LLVM 15.
r? ```@Mark-Simulacrum```
cc ```@matklad``` ```@davidlt```
Improve the documentation of `black_box`
There don't seem to be many great resources on how `black_box` should be used, so I added some information here
llvm-wrapper: adapt for LLVM API change
No functional changes intended.
The LLVM commit e6b02214c6 added `TargetExtTyID` to the `TypeID` enum. This adapts `RustWrapper` accordingly.
