Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis
See the writeup in `tests/ui/closures/opaque-upvar.rs`.
TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/197
r? lcnr
Clean rustdoc tests folder
We were starting to have way too many tests in the `tests/rustdoc/` folder so I moved some of them in sub-folders. We now have less than 300 tests at the "top level" so I guess it's good enough for now.
So this PR just moves tests in sub-folders and that's pretty much it. 😃
r? ``@notriddle``
Fix RustAnalyzer discovery of rustc's `stable_mir` crate
This fixes issues with RustAnalyzer not finding `stable_mir` crate since RA discovery traverses the dependency graph of `rustc_driver` crate.
This change also aligns with the long term architecture plan for these crates, since we are moving towards having stable_mir depend on rustc_smir and not the other way around. See [this doc](https://hackmd.io/jBRkZLqAQL2EVgwIIeNMHg) for more details.
I believe a similar function will come handy eventually for `stable_mir` users, but I'm keeping it as part of `rustc_internal` since its current format initializes the StableMir context and requires `TyCtxt`.
Finally, I added the `rustc_internal` module re-export under a feature since the APIs from this module shall not be stabilized.
std: get rid of `sys_common::process`
Move the public `CommandEnvs` into the `process` module (and make it a wrapper type for an internal iterator type) and everything else into `sys::process` as per #117276.
Something went wrong with a force push, so I can't reopen#139020. This is unchanged from that PR, apart from a rebase.
r? ```@thomcc```
coverage-dump: Resolve global file IDs to filenames
The coverage-dump tool, used by coverage tests, currently includes “global file ID” numbers in its dump output.
This PR adds support for parsing coverage filename information from LLVM assembly `.ll` files, and resolving those file IDs to the corresponding filename, for inclusion in dump output.
This makes dump output more informative, especially for test cases involving multiple files, and will be important for testing expansion region support in the future.
---
The bootstrap changes don't necessarily have to land at the same time (e.g. they could be deferred to after the stage0 redesign if requested), but I would prefer to land them now if possible.
Consistent trait bounds for ExtractIf Debug impls
Closes#137654. Refer to that issue for a table of the **4** different impl signatures we previously had in the standard library for Debug impls of various ExtractIf iterator types.
The one we are standardizing on is the one so far only used by `alloc::collections::linked_list::ExtractIf`, which is _no_ `F: Debug` bound, _no_ `F: FnMut` bound, only `T: Debug` bound.
This PR applies the following signature changes:
```diff
/* alloc::collections::btree_map */
pub struct ExtractIf<'a, K, V, F, A = Global>
where
- F: 'a + FnMut(&K, &mut V) -> bool,
Allocator + Clone,
impl Debug for ExtractIf<'a, K, V, F,
+ A,
>
where
K: Debug,
V: Debug,
- F: FnMut(&K, &mut V) -> bool,
+ A: Allocator + Clone,
```
```diff
/* alloc::collections::btree_set */
pub struct ExtractIf<'a, T, F, A = Global>
where
- T: 'a,
- F: 'a + FnMut(&T) -> bool,
Allocator + Clone,
impl Debug for ExtractIf<'a, T, F, A>
where
T: Debug,
- F: FnMut(&T) -> bool,
A: Allocator + Clone,
```
```diff
/* alloc::collections::linked_list */
impl Debug for ExtractIf<'a, T, F,
+ A,
>
where
T: Debug,
+ A: Allocator,
```
```diff
/* alloc::vec */
impl Debug for ExtractIf<'a, T, F, A>
where
T: Debug,
- F: Debug,
A: Allocator,
- A: Debug,
```
```diff
/* std::collections::hash_map */
pub struct ExtractIf<'a, K, V, F>
where
- F: FnMut(&K, &mut V) -> bool,
impl Debug for ExtractIf<'a, K, V, F>
where
+ K: Debug,
+ V: Debug,
- F: FnMut(&K, &mut V) -> bool,
```
```diff
/* std::collections::hash_set */
pub struct ExtractIf<'a, T, F>
where
- F: FnMut(&T) -> bool,
impl Debug for ExtractIf<'a, T, F>
where
+ T: Debug,
- F: FnMut(&T) -> bool,
```
I have made the following changes to bring these types into better alignment with one another.
- Delete `F: Debug` bounds. These are especially problematic because Rust closures do not come with a Debug impl, rendering the impl useless.
- Delete `A: Debug` bounds. Allocator parameters are unstable for now, but in the future this would become an API commitment that we do not debug-print a representation of the allocator when printing an iterator.
- Delete `F: FnMut` bounds. Requires `hashbrown` PR: https://github.com/rust-lang/hashbrown/pull/616. **API commitment:** we commit to not doing RefCell voodoo inside ExtractIf to have some way for its Debug impl (which takes &self) to call a FnMut closure, if this is even possible.
- Add `T: Debug` bounds (or `K`/`V`), even on Debug impls that do not currently make use of them, but might in the future. **Breaking change.** Must backport into Rust 1.87 (current beta) or do a de-stabilization PR in beta to delay those types by one release.
- Render using `debug_struct` + `finish_non_exhaustive`, instead of `debug_tuple`.
- Do not render the _entire_ underlying collection.
- Show a "peek" field indicating the current position of the iterator.
Fix `-Zremap-path-scope` rmeta handling
This PR fixes the conditional remapping (`-Zremap-path-scope`) of rmeta file paths ~~by using the `debuginfo` scope~~ by conditionally embedding the local path in addition to the remapped path.
Fixes https://github.com/rust-lang/rust/issues/139217
The MSRV being for crates targeting 1.85-1.87 on edition 2024
This enables the lint for regular nightly users without the feature gate
enabled
r? @samueltardieu
Fixes https://github.com/rust-lang/rust-clippy/issues/14678
changelog: none
Do not attempt to fetch a snippet from expansion. Without this change,
the inside of macros could[*] be shown as the source of the problem.
[*] Due to the way the source code is processed and reparsed in this
macro, the declarative macro has to be located outside the current
source file for the bug to appear. Otherwise, the macro call itself
will be (mis)identified as a potential `struct` field definition and the
lint will not trigger.
Make `-Zfixed-x18` into a target modifier
As part of #136966, the `-Zfixed-x18` flag should be turned into a target modifier. This is a blocker to stabilization of the flag. The flag was originally added in #124655 and the MCP for its addition is [MCP#748](https://github.com/rust-lang/compiler-team/issues/748).
On some aarch64 targets, the x18 register is used as a temporary caller-saved register by default. When the `-Zfixed-x18` flag is passed, this is turned off so that the compiler doesn't use the x18 register. This allows end-users to use the x18 register for other purposes. For example, by accessing it with inline asm you can use the register as a very efficient thread-local variable. Another common use-case is to store the stack pointer needed by the shadow-call-stack sanitizer. There are also some aarch64 targets where not using x18 is the default – in those cases the flag is a no-op.
Note that this flag does not *on its own* cause an ABI mismatch. What actually causes an ABI mismatch is when you have different compilation units that *disagree* on what it should be used for. But having a CU that uses it and another CU that doesn't normally isn't enough to trigger an ABI problem. However, we still consider the flag to be a target modifier in all cases, since it is assumed that you are passing the flag because you intend to assign some other meaning to the register. Rejecting all flag mismatches even if not all are unsound is consistent with [RFC#3716](https://rust-lang.github.io/rfcs/3716-target-modifiers.html). See the headings "not all mismatches are unsound" and "cases that are not caught" for additional discussion of this.
On aarch64 targets where `-Zfixed-x18` is not a no-op, it is an error to pass `-Zsanitizer=shadow-call-stack` without also passing `-Zfixed-x18`.
implement `PanicTracker` to track `t` panics
Trying to understand panics triggered by `t` macro is very exhausting (especially on CI failures) because it doesn't provide any information about where the macro was originally invoked. This change adds that missing information when an inner call inside the `t` macro panics.
Resolves#137557
