Last minute relnotes fix
This PR applies most of the suggestions in https://github.com/rust-lang/rust/pull/140802#discussion_r2080675967 (except for `as_flattened_mut`, which is indeed a const stabilization this cycle), and replaces all links from nightly to stable.
r? `@BoxyUwU`
Improved error message for top-level or-patterns
I was confused by "top-level or-patterns are not allowed in `let` bindings" error, because it sounded like or-patterns were completely unsupported.
This error has an auto-fix suggestion that shows otherwise, but the auto-fix isn't always visible in IDEs.
I've changed the wording to be consistent with "`Fn` bounds require arguments in parentheses", and it doesn't sound like a dead-end any more.
Fix `broken-pipe-no-ice` run-make test for rpath-less builds
The `broken-pipe-no-ice` run-make test currently fails on rpath-less builds, because host compiler runtime libs are not configured for raw std command usages.
This PR is an alternative approach to #140744. However, instead of duplicating `run_make_support::util::set_host_compiler_dylib_path` logic, we instead support "ejecting" the "configured" underlying std `Command` from `bare_rustc()` and `rustdoc()`, where host compiler runtime libs are already set.
cc `@jchecahi`
r? `@Kobzol`
also export metrics from librustdoc
Addresses the issue mentioned here: [#t-docs-rs > metrics intitiative @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/356853-t-docs-rs/topic/metrics.20intitiative/near/515714331)
The previous implementation only emitted metrics from rustc, but it turns out running `cargo doc` only calls `rustc` for dependencies, and not for the root crate being documented. We are planning to gather a sample dataset from docs.rs ci via `cargo doc` so as things stood this would not emit any metrics for any of the crates themselves that were published.
This change adds the same logic from `rustc_driver_impl` to `librustdoc` to also dump metrics at the end of its execution if they are enabled.
Note: The hash's generated by librustdoc will likely be completely different from the ones generated by rustc. This is because rustc is actually doing the various passes needed to fully calculate the stable version hash. My understanding of how rustdoc works is that the hashes generated will be working with partial information due to it only doing the work required to generate docs. The hashes will still be unique per crate and will work for the purposes of the metrics proof of concept, it would not be possible to correlate metrics generated by rustdoc with those generated by rustc for the same crate. This is fine for the purposes of the PoC but a future full implementation of metrics may want to address this issue.
rustdoc: Replace unstable flag `--doctest-compilation-args` with a simpler one: `--doctest-build-arg`
Tracking issue: https://github.com/rust-lang/rust/issues/134172.
Context: https://github.com/rust-lang/rust/pull/137096#issuecomment-2776318800
Yeets the ad hoc shell-like lexer for 'nested' program arguments.
No FCP necessary since the flag is unstable.
I've chosen to replace `compilation` with `build` because it's shorter (you now need to pass it multiple times in order to pass many arguments to the doctest compiler, so it matters a bit) and since I prefer it esthetically.
**Issue**: Even though we don't process the argument passed to `--doctest-build-arg`, we end up passing it via an argument file (`rustc `@argfile`)` which delimits arguments by line break (LF or CRLF, [via](https://doc.rust-lang.org/rustc/command-line-arguments.html#path-load-command-line-flags-from-a-path)) meaning ultimately the arguments still get split which is unfortunate. Still, I think this change is an improvement over the status quo.
I'll update the tracking issue if/once this PR merges. I'll also add the (CR)LF issue to 'unresolved question'.
r? GuillaumeGomez
r? notriddle
Where host compiler runtime libs are properly configured, instead of raw
`RUSTC`/`RUSTDOC` commands.
Co-authored-by: Jesus Checa Hidalgo <jchecahi@redhat.com>
In rare cases, the test may need access to the underlying
`std::process::Command` (e.g. for non-trivial process spawning).
Co-authored-by: Jesus Checa Hidalgo <jchecahi@redhat.com>
Revert "Rollup merge of #129343 - estebank:time-version, r=jieyouxu"
This reverts commit 26f75a65d7, reversing
changes made to 2572e0e8c9.
Imports are modified to fix merge conflicts and remove unused ones.
Enable non-leaf Frame Pointers for Arm64 Windows
Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>:
> The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack.
I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
Use span before macro expansion in lint for-loops-over-falibles
Fixes#140747
I think there are going to be a lot of cases where macros are expanded in the compiler resulting in span offsets, and I'd like to know how that's typically handled. Does it have to be handled specially every time?
All uses have been removed. And it's nonsensical: an identifier by
definition has at least one char.
The commits adds an is-non-empty assertion to `Ident::new` to enforce
this, and converts some `Ident` constructions to use `Ident::new`.
Adding the assertion requires making `Ident::new` and
`Ident::with_dummy_span` non-const, which is no great loss.
The commit amends a couple of places that do path splitting to ensure no
empty identifiers are created.
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes#138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
Rollup of 8 pull requests
Successful merges:
- #140095 (Eliminate `word_and_empty` methods.)
- #140341 (Clarify black_box warning a bit)
- #140684 (Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided)
- #140707 (Structurally normalize in range pattern checking in HIR typeck)
- #140716 (Improve `-Zremap-path-scope` tests with dependency)
- #140800 (Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux)
- #140802 (Add release notes for 1.87.0)
- #140811 (Enable triagebot note functionality for rust-lang/rust)
r? `@ghost`
`@rustbot` modify labels: rollup
Improve `-Zremap-path-scope` tests with dependency
This PR greatly improves our coverage of `-Zremap-path-scope` for diagnostic paths and macros with dependencies.
r? `@jieyouxu` (since we talked about it)
try-job: x86_64-msvc-1
Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided
Since #136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given:
```rust
trait Trait {
type Assoc where Self: Sized;
}
```
After #136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing.
After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.
We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.
Fixes#140645
r? lcnr
Do not deny warnings in "fast" try builds
When we do the classic ``@bors` try` build without specifying `try-job` in the PR description, we want to get a compiler toolchain for perf./crater/local experimentation as fast as possible. We don't run any tests in that case, so it seems reasonable to also ignore warnings.
Fixes: https://github.com/rust-lang/rust/issues/140753
r? `@jieyouxu`
try-job: dist-x86_64-linux
