Improve display of parallel jobs in rustdoc-gui tester script
If no `-j` option is not passed to `x.py`, it would display `-1`, which isn't great.
r? `@notriddle`
coverage: Several small cleanups in `spans`
While investigating the details of coverage span processing, I noticed several opportunities to make the code simpler and clearer.
---
`@rustbot` label +A-code-coverage
Also add a few methods to instantiate instances and get an instance
definition.
We're still missing support to actually monomorphize the instance body.
This makes it so that all the matchers that match against paths use the
definition path instead of the export path. This removes all duplication
around `std`/`alloc`/`core`.
This is not necessarily optimal because we now depend on internal
implementation details like `core::ops::control_flow::ControlFlow`,
which is not very nice and probably not acceptable for a stable
`on_unimplemented`.
An alternative would be to just string-replace normalize away
`alloc`/`core` to `std` as a special case, keeping the export paths but
making it so that we're still fully standard library flavor agnostic.
Remove `DefiningAnchor::Bubble` from opaque wf check
Set the defining anchor to `DefiningAnchor::Bind(parent_def_id)` where `parent_def_id` is the first parent def-id that isn't an opaque.
This "fixes" some of the nested-return-type wf tests. If we *do* want these to be hard-errors for TAITs, we should probably make those error separately from this check (i.e. via some check like the code in the `OPAQUE_HIDDEN_INFERRED_BOUND` lint). The fact that some of these tests fail but not all of them seems kinda coincidental.
r? oli-obk
Suggest trait bounds for used associated type on type param
Fix#101351.
When an associated type on a type parameter is used, and the type parameter isn't constrained by the correct trait, suggest the appropriate trait bound:
```
error[E0220]: associated type `Associated` not found for `T`
--> file.rs:6:15
|
6 | field: T::Associated,
| ^^^^^^^^^^ there is a similarly named associated type `Associated` in the trait `Foo`
|
help: consider restricting type parameter `T`
|
5 | struct Generic<T: Foo> {
| +++++
```
When an associated type on a type parameter has a typo, suggest fixing
it:
```
error[E0220]: associated type `Baa` not found for `T`
--> $DIR/issue-55673.rs:9:8
|
LL | T::Baa: std::fmt::Debug,
| ^^^ there is a similarly named associated type `Bar` in the trait `Foo`
|
help: change the associated type name to use `Bar` from `Foo`
|
LL | T::Bar: std::fmt::Debug,
| ~~~
```
Enable triagebot no-merges check
Follow-up on https://github.com/rust-lang/triagebot/pull/1704
### Motivation
Occasionally, a merge commit like cb5c011670 makes it past manual review and gets merged into master.
At one point, we tried adding a check to CI to prevent this from happening (https://github.com/rust-lang/rust/pull/105058), but that ended up [problematic](https://github.com/rust-lang/rust/pull/106319#issuecomment-1368144076) and was [reverted](https://github.com/rust-lang/rust/pull/106320). This kind of check is simply too fragile for CI, and there must be a way for a human to override the bot's decision.
The capability to detect and warn about merge commits has been present in triagebot for quite some time, but was never enabled at rust-lang/rust, possibly due to concerns about false positives on rollup and subtree sync PRs. This PR intends to alleviate those concerns.
### Configuration
This configuration will exclude rollup PRs and subtree sync PRs from merge commit detection, and it will post the default warning message and add the `has-merge-commits` and `S-waiting-on-author` labels when merge commits are detected on other PRs.
The eventual vision is to have bors refuse to merge if the `has-merge-commits` label is present. A reviewer can still force the merge by removing that label if they so wish.
### Note for contributors
The rollup tool should add that label automatically, but anyone performing subtree updates should begin including "subtree update" in the titles of those PRs, to avoid false positives.
r? infra
## Open Questions
1. This configuration uses the default message that's built into triagebot:
> There are merge commits (commits with multiple parents) in your changes. We have a [no merge policy](https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy) so these commits will need to be removed for this pull request to be merged.
>
> You can start a rebase with the following commands:
> ```shell-session
> $ # rebase
> $ git rebase -i master
> $ # delete any merge commits in the editor that appears
> $ git push --force-with-lease
> ```
Any changes to this are easy, I'll just have to add a `message` option. Should we mention the excluded titles in the message?
Add `Config::hash_untracked_state` callback
For context, I'm looking to use [late module passes](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/context/struct.LintStore.html#structfield.late_module_passes) in Clippy which unlike regular late passes run incrementally per module
However we have a config file which can change between runs, we need changes to that to invalidate the `lint_mod` query. This PR adds a side channel for us to hash some extra state into `Options` in order to do that
This does not make any changes to Clippy, I plan to do that in a PR to the Clippy repo along with some other required changes
An alternative implementation would be to add a new query to track this state and override the `lint_mod` query in Clippy to first call that
cc `@rust-lang/clippy`
[`unnecessary_lazy_eval`]: reduce applicability if closure has return type annotation
Fixes#11672
We already check if closure parameters don't have type annotations and reduce the applicability to `MaybeIncorrect` if they do, since those help type inference and removing them breaks code. We didn't do this for return type annotations however. This PR adds it. This doesn't change it to produce a fix that will compile, but it will prevent rustfix from auto-applying it.
(In general I'm not sure if we can suggest a fix that will compile. In this specific example, it might be possible to suggest `&[] as &[u8]`, but as-casts won't always work, e.g. `Default::default() as &[u8]` is a compile error, so just reducing applicability should be a safe fix in any case for now)
changelog: [`unnecessary_lazy_eval`]: reduce applicability to `MaybeIncorrect` if closure has return type annotation
changelog: Now `declare_interior_mutable_const` and `borrow_interior_mutable_const` respect the `ignore-interior-mutability` configuration entry
Signed-off-by: slinkydeveloper <francescoguard@gmail.com>
don't UB on dangling ptr deref, instead check inbounds on projections
This implements https://github.com/rust-lang/reference/pull/1387 in Miri. See that PR for what the change is about.
Detecting dangling references in `let x = &...;` is now done by validity checking only, so some tests need to have validity checking enabled. There is no longer inherently a "nodangle" check in evaluating the expression `&*ptr` (aside from the aliasing model).
r? `@oli-obk`
Based on:
- https://github.com/rust-lang/reference/pull/1387
- https://github.com/rust-lang/rust/pull/115524
interpret: clean up AllocBytes
Fixes https://github.com/rust-lang/miri/issues/2836
Nothing has moved here in half a year, so let's just remove these unused stubs -- they need a proper re-design anyway.
r? `@oli-obk`
Interacting with `basic_coverage_blocks` directly makes it easier to satisfy
the borrow checker when mutating `pending_dups` while reading other fields.
