Enable "jump to def" feature on rustc docs
This PR enables the rustdoc "jump to def" feature which is visible on the source code pages.
r? ``@oli-obk``
Revert "CI: build FreeBSD artifacts on FreeBSD 13.4"
This reverts commit cf34545720.
That commit led to a regression of
https://github.com/rust-lang/rust/issues/132185 . So my analysis that the problem lay in FreeBSD 13.2's specific LLVM version was clearly wrong. Revert that commit until we can figure out the real root cause.
Fixes#132185
try-job: dist-x86_64-freebsd
try-job: dist-various-2
Rollup of 7 pull requests
Successful merges:
- #136073 (Always compute coroutine layout for eagerly emitting recursive layout errors)
- #136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
- #136311 (Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types)
- #136315 (Use short ty string for binop and unop errors)
- #136393 (Fix accidentally not emitting overflowing literals lints anymore in patterns)
- #136435 (Simplify some code for lowering THIR patterns)
- #136630 (Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-gnu-debug
Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering
I don't really know how to test if this unbreaks CI (since #136607 reported that this breaks the CI test rendering *sometimes*).
Fixes#136607.
r? `@ChrisDenton` (two Windows process tests, but feel free to reroll)
Fix accidentally not emitting overflowing literals lints anymore in patterns
This was regressed in https://github.com/rust-lang/rust/pull/134228 (not in beta yet).
The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code.
So now I've set it up for visitors to be able to directly visit literals and get all literals
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
This is continuation of https://github.com/rust-lang/rust/pull/132282 .
I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement.
There are other possibilities, through.
We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase.
So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge.
cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 )
r? SparrowLii
`@rustbot` label WG-compiler-parallel
Document minimum supported host tooling on macOS
In particular we support macOS 10.12 (same as for binaries produced by `rustc`) and Xcode 9.2 (the highest Xcode version that runs on macOS 10.12.6). I have this installed on a MacBook Pro from 2013 that sits below my desk, and am occasionally testing it.
I am documenting this now because it was unclear in https://github.com/rust-lang/rust/issues/136523.
(I'm not inherently against bumping these one day, but that's a separate discussion, let's at least document what we support right now).
`@rustbot` label O-macos
This reverts commit cf34545720.
That commit led to a regression of
https://github.com/rust-lang/rust/issues/132185 . So my analysis that
the problem lay in FreeBSD 13.2's specific LLVM version was clearly
wrong. Revert that commit until we can figure out the real root cause.
Fixes#132185
tests: Port `split-debuginfo` to rmake.rs
Part of #121876.
This PR supersedes #128754 and is co-authored with `@Oneirical.`
## Known limitations
- In general, like the `Makefile` version, this test in its present form is also somewhat funny because for the most part it merely checks for existence/absence of output artifacts but makes no attempt to actually check if the debuginfo is at all usable.
## Changes
This PR ports `tests/run-make/split-debuginfo` to rmake.rs. This is an **initial** port, and certainly could be cleaned up and/or enhanced.
The original Makefile version had several functional problems. I fixed some of them, but also left some existing issues as-is.
1. The linux/non-linux final branch had a conditional interpolation of `UNSTABLE_OPTIONS := -Zunstable-options`. However, one of the use sites was `-C $(UNSTABLE_OPTIONS) split-debuginfo`. This indicates to me that this run-make test is not run in CI under a non-linux + non-windows + non-darwin environment, because that would've failed as this would expand to `-C -Zunstable-options split-debuginfo`. I fixed this in the rmake.rs version, but I'm not sure if this distinction is worth keeping at all if it's not tested in CI.
2. There are several comments that were discovered to be wrong. I tried to fix them in the rmake.rs version as well.
3. The check for path remapping / lack of path remapping through
```make
objdump -Wi $(TMPDIR)/foo | grep DW_AT_GNU_dwo_name | (! grep $(TMPDIR)) || exit 1
```
is incorrect, because that looks at the single line of that contains `DW_AT_GNU_dwo_name`. This is unfortunately wrong because empirical evidence shows that with `objdump`[^objdump], the check actually needs to look at the attribute value of `DW_AT_comp_dir` on the previous line not `DW_AT_GNU_dwo_name`[^gnu-ext]. Example output of `objdump`:
```text
<10> DW_AT_comp_dir : (indirect string, offset: 0xafb48): /home/joe/repos/rust
<14> DW_AT_GNU_dwo_name: (indirect string, offset: 0x5d1b0): foo.foo.fc848df41df7a00d-cgu.0.rcgu.dwo
```
In the rmake.rs version I used a 2-line sliding window to check for `DW_AT_comp_dir` and `DW_AT_GNU_dwo_name`, but to look at `DW_AT_comp_dir` specifically.
4. I included a bunch of FIXMEs and ENHANCEMENTs I noticed regarding the test because I didn't want to fix them in this initial port[^enhancement].
5. The Makefile version didn't test *anything* on Windows (both windows-msvc and windows-gnu). I added some *very* basic and *very* sparse checks for windows-msvc, but I am not willing to spend the effort to expand test coverage to windows-gnu in this initial port.
6. This run-make test is way too big. But I didn't want to expend the effort of breaking this up in this initial port.
[^objdump]: the output format differs between `objdump` and `llvm-objdump`, but the same is true for `llvm-objdump` that this is looking at the wrong line.
[^gnu-ext]: AFAICT that is a GNU DWARF attribute extension, since it isn't mentioned in DWARFv5 spec
[^enhancement]: For instance, the previous path remapping check could in theory be precisely inspected by inspecting `.debug_info` section to look for attribute value of `DW_AT_comp_dir`. But that involves resolving the value of the indirect string, which means you have to: (1) look for offset into string offset table and (2) use *that* offset to find the string itself in the string table. The split part of "split-debuginfo" makes this murky for me, so I wasn't able to replace `llvm-objdump` textual output substring matches with more precise `object` + `gimli` inspections.
## Review advice
- I'm sorry for how long the rmake.rs test ended up, but a lot of it is comments and just vertical space due to formatting. If there's any ways to make this test less long / convoluted, advice would be appreciated.
- This PR *intentionally* introduces several intermediate commits for the `Makefile`, mostly to illustrate the problems I discovered when looking at the original `Makefile` version. This is intended to highlight the existing problems in the `Makefile` version for the reviewer[^squash].
- There are several intentional non-functional commits:
1. Reindent the `Makefile` to make the platform conditional gating more obvious.
2. Collapse nested if-else branches into an else if construct, which is not supported by GNU Make 3.80.
3. Remove all redundant `-C debuginfo=2` when `-g` is already specified.
- This PR is best reviewed commit-by-commit.
[^squash]: I intend to squash these intermediate commits away after the reviewer concludes that the current form of the rmake.rs test is acceptable for merge. Before then, I'll keep them to help with review.
---
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
bootstrap: add wrapper macros for `feature = "tracing"`-gated `tracing` macros
Follow-up to https://github.com/rust-lang/rust/pull/136091#discussion_r1930219425.
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and `trace!`, which `cfg(feature = "tracing")`-gates the underlying `tracing` macros. They expand to nothing if `"tracing"` feature is not enabled.
- This is not done for `span!` or `event!` because they can return span guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute proc-macro unless you use another attribute proc-macro to wrap that.
It's not *great*, because `tracing::instrument` and `tracing::{span,event}` can't be wrapped this way.
Can test locally with:
```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap/
```
r? ``@onur-ozkan`` (or reroll)
rustdoc: clean up a bunch of ts-expected-error declarations in main
This mostly consists of handling potentially-null input and adding more global functions to the list of globals.
Follow-up for #136161
#[contracts::requires(...)] + #[contracts::ensures(...)]
cc https://github.com/rust-lang/rust/issues/128044
Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition, building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).
Known issues:
* My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was to have a rustc-prefixed attribute namespace (like rustc_contracts::requires). But I could not get things working when I tried to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it is called `contracts::requires`.
* Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
* (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)
* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
librustdoc: create a helper for separating elements of an iterator instead of implementing it multiple times
This implements something similar to [`Itertools::format`](https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.format), but on `Fn`s returning iterators instead of directly on iterators, to allow implementing `Display` without the use of a `Cell` (to handle the possibility of `fmt` being called multiple times while receiving `&self`).
~This is WIP, I just want to get a perf run first to see if the regression I saw in #135494 is fixed~
This was originally part of #135494 , but originally caused a perf regression that was since fixed:
7d5ae1863a/src/librustdoc/html/format.rs (L507)
Allow using named consts in pattern types
This required a refactoring first: I had to stop using `hir::Pat`in `hir::TyKind::Pat` and instead create a separate `TyPat` that has `ConstArg` for range ends instead of `PatExpr`. Within the type system we should be using `ConstArg` for all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.
Extract `core::ffi` primitives to a separate (internal) module
### Introduce library/core/src/ffi/primitives.rs
The regex preprocessing for PR #133944 would be more robust if the relevant types from core/src/ffi/mod.rs were first moved to library/core/src/ffi/primitives.rs, then there isn't a need to deal with traits / c_str / va_list / whatever might wind up in that module in the future
r? `@tgross35`
Implement unstable `new_range` feature
Switches `a..b`, `a..`, and `a..=b` to resolve to the new range types.
For rust-lang/rfcs#3550
Tracking issue #123741
also adds the re-export that was missed in the original implementation of `new_range_api`
- Add wrapper macros for `error!`, `warn!`, `info!`, `debug!` and
`trace!`, which `cfg(feature = "tracing")`-gates the underlying
`tracing` macros.
- This is not done for `span!` or `event!` because they can return span
guards, and you can't really wrap that.
- This is also not possible for `tracing::instrument` attribute
proc-macro unless you use another attribute proc-macro to wrap that.
Rollup of 6 pull requests
Successful merges:
- #134807 (fix(rustdoc): always use a channel when linking to doc.rust-lang.org)
- #134814 (Add `kl` and `widekl` target features, and the feature gate)
- #135836 (bootstrap: only build `crt{begin,end}.o` when compiling to MUSL)
- #136022 (Port ui/simd tests to use the intrinsic macro)
- #136309 (set rustc dylib on manually constructed rustc command)
- #136462 (mir_build: Simplify `lower_pattern_range_endpoint`)
r? `@ghost`
`@rustbot` modify labels: rollup
bootstrap: only build `crt{begin,end}.o` when compiling to MUSL
only MUSL needs those objects and trying to compile them to other targets, e.g. Windows or macOS, will produce C compilation errors
check the target before shelling out to the C compiler and tweak `make_run` to skip the actual C compilation when the target is not MUSL
fixes#135782
see the linked issue for additional context
fix(rustdoc): always use a channel when linking to doc.rust-lang.org
Closes#131971
I manually checked the resulting links
One issue is that this will create `nightly/...` links in places that formerly linked to stable, is that ok ? (the `slice` and `array` links in the search help notably)
Rollup of 8 pull requests
Successful merges:
- #136289 (OnceCell & OnceLock docs: Using (un)initialized consistently)
- #136299 (Ignore NLL boring locals in polonius diagnostics)
- #136411 (Omit argument names from function pointers that do not have argument names)
- #136430 (Use the type-level constant value `ty::Value` where needed)
- #136476 (Remove generic `//@ ignore-{wasm,wasm32,emscripten}` in tests)
- #136484 (Notes on types/traits used for in-memory query caching)
- #136493 (platform-support: document CPU baseline for x86-32 targets)
- #136498 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures.
includes post-developed commit: removed tabs that creeped in into rustfmt tool source code.
includes post-developed commit, placating rustfmt self dogfooding.
includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/
includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures).
Rebase Conflicts:
- compiler/rustc_parse/src/parser/diagnostics.rs
- compiler/rustc_parse/src/parser/item.rs
- compiler/rustc_span/src/hygiene.rs
Remove contracts keywords from diagnostic messages
