merge privacy/privacy-sanity-2 with privacy/privacy-sanity.rs
Add comment to generics/type-args-on-module-in-bound.rs
Add comment to array-slice-vec/closure-in-array-eln.rs
Add comment to array-slice-vec/return-in-array-len.rs
Merge for-loop-while/break-outside-loop-2.rs with
for-loop-while/break-outside-loop.rs
Add comment to macros/column-macro-collision.rs
Add comment to privacy/private-extern-fn-visibility.rs
Add comment to mismatched_types/vec-hashset-type-mismatch.rs
Merge std-sync-right-kind-impls-2.rs with std-sync-right-kind-impls.rs
Add comment to array-slice-vec/slice-of-multi-ref.rs
Add comment to mismatched_types\vec-hashset-type-mismatch.rs
Add comment to derives/derive-hygiene-struct-builder.rs
Add comment to label/undeclared-label-span.rs
Add comment to label\undeclared-label-span.rs
Add comment to mismatched_types/array-repeat-unit-struct.rs
Avoid ICEs after bad patterns, for the other syntactic variants
This PR introduces changes equivalent to the ones in rust-lang/rust#126320, but also for struct and tuple patterns, instead of tuple struct patterns only.
Fixesrust-lang/rust#150507.
include `HirId`s directly in the THIR, not wrapped in `LintLevel`s
Occurrences of `LintLevel` in the THIR were always `LintLevel::Explicit`, containing a `HirId`, so we don't need to make it possible to put `LintLevel::Inherited` there. Removing the unused case where `HirId`s aren't present in the THIR slightly simplifies diagnostics/lints/tools that want to map from the THIR back to the HIR, e.g. rust-lang/rust#145569.
Since `LintLevel` is no longer present in the THIR, I've moved it in the second commit to live in `rustc_mir_build`; that's where it's actually used. I'm not sure exactly where exactly it should live there, but I put it in the `builder::scope` module since it's used by `Builder::in_scope` for determining when to introduce source scopes.
r? lcnr as the reviewer of rust-lang/rust#145569, since this was discussed there
This reverts PR <https://github.com/rust-lang/rust/pull/130998> because
the added test seems to be flaky / non-deterministic, and has been
failing in unrelated PRs during merge CI.
Recover parse gracefully from `<const N>`
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
r? @fmease
Follow up to rust-lang/rust#151077. Fixrust-lang/rust#84327.
Disallow eii in statement position
With how v2 macros resolve, and the name resolution of `super` works, I realized with @WaffleLapkin that there's actually no way to consistently expand EIIs in statement position.
r? @WaffleLapkin
Remove `FeedConstTy` and provide ty when lowering const arg
r? @BoxyUwU
edit: BoxyUwU
`FeedConstTy` currently only provides the expected type of a const argument *sometimes* (e.g. previously array lengths did not do this). This causes problems with mGCA's directly represented const arguments which always need to know their expected type.
Don't try to recover keyword as non-keyword identifier
Fixesrust-lang/rust#149692.
On beta after rust-lang/rust#146978, we ICE on
```rs
macro_rules! m {
($id:item()) => {}
}
m!(Self());
```
where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.
I suspect rust-lang/rust#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like
```rs
error: expected identifier, found keyword `Self`
--> src/lib.rs:5:4
|
5 | m!(Self());
| ^^^^ expected identifier, found keyword
error: missing `fn` or `struct` for function or struct definition
--> src/lib.rs:5:4
|
2 | ($id:item()) => {}
| -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
| ^^^^
|
help: if you meant to call a macro, try
|
5 | m!(Self!());
| +
```
I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
rustdoc: Fix intra-doc link bugs involving type aliases and associated items
This PR:
- Add support for linking to fields of variants behind a type alias.
- Correctly resolve links to fields and variants behind a type alias to the alias's version of the docs.
- Refactor some intra-doc links code to make it simpler.
- Add tests for the status quo of linking to associated items behind aliases.
Future steps:
- Nail down the rules of when inherent and trait impls are inlined into an alias's docs, and when impls on the alias appear for the aliased type.
- Adjust the resolutions of intra-doc links, through aliases, to associated items based on these rules.
r? @GuillaumeGomez
Add a context-consistency check before emitting redundant generic-argument suggestions
Fixesrust-lang/rust#149559
Add a context-consistency check before emitting redundant generic-argument suggestions. If the redundant argument spans come from mixed hygiene contexts (e.g., macro definition + macro callsite), we skip the suggestion to avoid malformed `shrink_to_hi().to(...)` spans and potential ICEs.
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
The opposite ordering was a consistent source of confusion during debuggingю
`report_conflict` actually used an incorrect order due to similar confusion.
Remove `Deref`/`DerefMut` impl for `Providers`.
It's described as a "backwards compatibility hack to keep the diff small". Removing it requires only a modest amount of churn, and the resulting code is clearer without the invisible derefs.
r? @oli-obk
Recognize potential `impl<const N: usize>` to `impl<N>` mistake
When encountering code like `impl<N> Bar<N> for [u8; N]`, suggest `impl<const N: Type> Bar<N> for [u8; N]` as a possibility.
```
error[E0423]: expected value, found type parameter `T`
--> $DIR/issue-69654.rs:5:25
|
LL | impl<T> Bar<T> for [u8; T] {}
| - ^ not a value
| |
| found this type parameter
|
help: you might have meant to write a const parameter here
|
LL | impl<const T: Type> Bar<T> for [u8; T] {}
| +++++ ++++++
```
Addresses "case 3" from rust-lang/rust#84327.
Avoid should-fail in two ui tests and a codegen-llvm test
`should-fail` is only meant for testing the compiletest framework itself. It checks that the test runner itself panicked.
With this there are still a bunch of rustdoc-html tests that use it due to this test suite not supporting anything like `//@ doc-fail`.
Better handle when trying to iterate on a `Range` of a type that isn't `Step`
Mention when a trait bound corresponds to an unstable trait.
Mention `Range` when `Step` bound is unment, and explain that only some std types impl `Iterator` for `Range`.
CC rust-lang/rust#151026
std: move `errno` and related functions into `sys::io`
Part of rust-lang/rust#117276.
Currently, `errno` and related functions like `decode_error_kind` are split across `sys::pal` and `sys::pal::os`. This PR moves all of them into a new module inside `sys::io`.
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
When encountering code like `impl<N> Bar<N> for [u8; N]`, suggest `impl<const N: Type> Bar<N> for [u8; N]` as a possibility.
```
error[E0423]: expected value, found type parameter `T`
--> $DIR/issue-69654.rs:5:25
|
LL | impl<T> Bar<T> for [u8; T] {}
| - ^ not a value
| |
| found this type parameter
|
help: you might have meant to write a const parameter here
|
LL | impl<const T: /* Type */> Bar<T> for [u8; T] {}
| +++++ ++++++++++++
```
Reduce flakyness for `tests/rustdoc-gui/notable-trait.goml`
Fixes https://github.com/rust-lang/rust/issues/151006 (hopefully).
Instead of asserting right away, it waits for the element count to be the one expected.
r? @jieyouxu
ui: add regression test for macro resolution ICE (issue #150711)
Added a new test in `test/ui/resolve` for a macro
resolution scenario that previously caused an ICE.
Files added:
- `tests/ui/resolve/decl-macro-use-no-ice.rs`
- `tests/ui/resolve/decl-macro-use-no-ice.stderr`
Fixesrust-lang/rust#150711
r? @matthiaskrgr
r? @petrochenkov
Support arrays in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting arrays `[T; N]` through type reflection. It does so by adding `TypeKind::Array` and the `Array` struct:
```rust
pub struct Array {
pub element_ty: TypeId,
pub len: usize,
}
```
This can be used to inspect arrays like so:
```rust
match const { Type::of::<[u16; 4]>() }.kind {
TypeKind::Array(array) => {
assert_eq!(array.element_ty, TypeId::of::<u16>());
assert_eq!(array.len, 4);
}
_ => unreachable!(),
}
```
r? @oli-obk
Make `Type::of` support unsized types
Tracking issue: rust-lang/rust#146922Fixesrust-lang/rust#151018
`Type::of` is a utility function for getting type reflection information, and internally just calls `TypeId::of::<T>().info()`. `Type::of` does not support unsized types like `str` and `[u8]` because it is missing a `?Sized` bound. I believe this is an oversight rather than an intentional decision, as `TypeId::of` _does_ support unsized types and `Type::size` is an `Option` to support types without sizes.
This PR adds a `?Sized` bound to `Type::of` and extends the `dump.rs` test to ensure unsized types work in the future.
r? @oli-obk
Regression test for type params on eii
Somewhere along the line I fixed this one with my other PRs. This just adds the regression tests
Closesrust-lang/rust#149983
