Disallow `A { .. }` if `A` has no fields
```
error: `A` has no fields, `..` needs at least one default field in the struct definition
--> $DIR/empty-struct.rs:16:17
|
LL | let _ = A { .. };
| - ^^
| |
| this type has no fields
```
[rustdoc] Replace module list items `ul`/`li` with `dl`/`dd`/`dt` elements
`@hywan` suggested that rustdoc should use `dl`,`dt` and `dd` HTML tags for listing items on module pages as it matches better what this is (an item and optionally its description). This is a very good idea so here is the implementation.
Also nice side-effect of this change: it reduces a bit the generated HTML since we go from:
This PR shouldn't impact page appearance.
```html
<ul class="item-table">
<li>
<div class="item-name">NAME</div>
<div class="desc docblock-short">THE DOC</div>
</li>
</ul>
```
to:
```html
<dl class="item-table">
<dt>NAME</dt>
<dd>THE DOC</dd>
</dl>
```
You can test it [here](https://rustdoc.crud.net/imperio/items-list/std/index.html).
r? `@notriddle`
Fix ICE in resolving associated items as non-bindings
Fixes#135614 so that imported associated functions of traits can be shadowed by local bindings and associated constants of traits can be used in patterns.
```
error[E0797]: base expression required after `..`
--> $DIR/feature-gate-default-field-values.rs:62:21
|
LL | let x = Foo { .. };
| ^
|
help: add `#![feature(default_field_values)]` to the crate attributes to enable default values on `struct` fields
|
LL + #![feature(default_field_values)]
|
help: add a base expression here
|
LL | let x = Foo { ../* expr */ };
| ++++++++++
```
```
error: `size_of_val` is not yet stable as a const intrinsic
--> $DIR/const-unstable-intrinsic.rs:17:9
|
LL | unstable_intrinsic::size_of_val(&x);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: add `#![feature(unstable)]` to the crate attributes to enable
help: add `#![feature(unstable)]` to the crate attributes to enable
|
LL + #![feature("unstable")]
|
```
When encountering a call corresponding to an item marked as unstable behind a feature flag, provide a structured suggestion pointing at where in the crate the `#![feature(..)]` needs to be written.
```
error: `foobar` is not yet stable as a const fn
--> $DIR/const-stability-attribute-implies-no-feature.rs:12:5
|
LL | foobar();
| ^^^^^^^^
|
help: add `#![feature(const_foobar)]` to the crate attributes to enable
|
LL + #![feature(const_foobar)]
|
```
Fix#81370.
```
error: `A` has no fields, `..` needs at least one default field in the struct definition
--> $DIR/empty-struct.rs:16:17
|
LL | let _ = A { .. };
| - ^^
| |
| this type has no fields
```
Collect all unreachable fields in a single struct literal struct and emit a single error, instead of one error per private field.
```
error[E0451]: fields `beta` and `gamma` of struct `Alpha` are private
--> $DIR/visibility.rs:18:13
|
LL | let _x = Alpha {
| ----- in this type
LL | beta: 0,
| ^^^^^^^ private field
LL | ..
| ^^ field `gamma` is private
```
Rollup of 7 pull requests
Successful merges:
- #133700 (const-eval: detect more pointers as definitely not-null)
- #135290 (Encode constraints that hold at all points as logical edges in location-sensitive polonius)
- #135478 (Run clippy for rustc_codegen_gcc on CI)
- #135583 (Move `std::pipe::*` into `std::io`)
- #135612 (Include x scripts in tarballs)
- #135624 (ci: mirror buildkit image to ghcr)
- #135661 (Stabilize `float_next_up_down`)
r? `@ghost`
`@rustbot` modify labels: rollup
const-eval: detect more pointers as definitely not-null
This fixes https://github.com/rust-lang/rust/issues/133523 by making the `scalar_may_be_null` check smarter: for instance, an odd offset in any 2-aligned allocation can never be null, even if it is out-of-bounds.
More generally, if an allocation with unknown base address B is aligned to alignment N, and a pointer is at offset X inside that allocation, then we know that `(B + X) mod N = B mod N + X mod N = X mod N`. Since `0 mod N` is definitely 0, if we learn that `X mod N` is *not* 0 we can deduce that `B + X` is not 0.
This is immediately visible on stable, via `ptr.is_null()` (and, more subtly, by not raising a UB error when such a pointer is used somewhere that a non-null pointer is required). Therefore nominating for `@rust-lang/lang.`
new solver: prefer trivial builtin impls
As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/needs_help.3A.20trivial.20builtin.20impls), this PR:
- adds a new `BuiltinImplSource::Trivial` source, and marks the `Sized` builtin impls as trivial
- prefers these trivial builtin impls in `merge_trait_candidates`
The comments can likely be wordsmithed a bit better, and I ~stole~ was inspired by the old solver ones. Let me know how you want them improved.
When enabling the new solver for tests, 3 UI tests now pass:
- `regions/issue-26448-1.rs` and its sibling `regions/issue-26448-2.rs` were rejected by the new solver but accepted by the old one
- and `issues/issue-42796.rs` where the old solver emitted some overflow errors in addition to the expected error
(For some reason one of these tests is run-pass, but I can take care of that another day)
r? lcnr
```
error[E0451]: field `x` of struct `S` is private
--> $DIR/visibility.rs:24:9
|
LL | let a = baz::S {
| ------ in this type
LL | ..
| ^^ field `x` is private
```
```
error[E0451]: field `beta` of struct `Alpha` is private
--> $DIR/visibility.rs:11:37
|
LL | let x = crate::foo::Alpha { .. };
| ^^ field `beta` is private
```
Detect if-else chains with a missing final else in type errors
```
error[E0308]: `if` and `else` have incompatible types
--> $DIR/if-else-chain-missing-else.rs:12:12
|
LL | let x = if let Ok(x) = res {
| ______________-
LL | | x
| | - expected because of this
LL | | } else if let Err(e) = res {
| | ____________^
LL | || return Err(e);
LL | || };
| || ^
| ||_____|
| |_____`if` and `else` have incompatible types
| expected `i32`, found `()`
|
= note: `if` expressions without `else` evaluate to `()`
= note: consider adding an `else` block that evaluates to the expected type
```
We probably want a longer explanation and fewer spans on this case.
Partially address #133316.
Location-sensitive polonius prototype: endgame
This PR sets up the naive location-sensitive analysis end-to-end, and replaces the location-insensitive analysis. It's roughly all the in-progress work I wanted to land for the prototype, modulo cleanups I still want to do after the holidays, or the polonius debugger, and so on.
Here, we traverse the localized constraint graph, have to deal with kills and time-traveling (👌), and record that as loan liveness for the existing scope and active loans computations.
Then the near future looks like this, especially if the 2025h1 project goal is accepted:
- gradually bringing it up to completion
- analyzing and fixing the few remaining test failures
- going over the *numerous* fixmes in this prototype (one of which is similar to a hang on one test's millions and millions of constraints)
- trying to see how to lower the impact of the lack of NLL liveness optimization on diagnostics, and their categorization of local variables and temporaries (the vast majority of blessed expectations differences), as well as the couple ICEs trying to find an NLL constraint to blame for errors.
- dealing with the theoretical weakness around kills, conflating reachability for the two TCS, etc that is described ad nauseam in the code.
- switching the compare mode to the in-tree implementation, and blessing the diagnostics
- apart from the hang, it's not catastrophically slower on our test suite, so then we can try to enable it on CI
- checking crater, maybe trying to make it faster :3, etc.
I've tried to gradually introduce this PR's work over 4 commits, because it's kind of subtle/annoying, and Niko/I are not completely convinced yet. That one comment explaining the situation is maybe 30% of the PR 😓. Who knew that spacetime reachability and time-traveling could be mind bending.
I kinda found this late and the impact on this part of the computation was a bit unexpected to us. A bit more care/thought will be needed here. I've described my plan in the comments though. In any case, I believe we have the current implementation is a conservative approximation that shouldn't result in unsoundness but false positives at worst. So it feels fine for now.
r? ``@jackh726``
---
Fixes#127628 -- which was a assertion triggered for a difference in loan computation between NLLs and the location-insensitive analysis. That doesn't exist anymore so I've removed this crash test.
Treat other items as functions for the purpose of type-based search
specifically, constants and statics are nullary functions, and struct fields are unary functions.
fixes#130204
r? ``@notriddle``
Add gpu-kernel calling convention
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target.
Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
Tracking issue: #135467
amdgpu target tracking issue: #135024
Use trait definition cycle detection for trait alias definitions, too
fixes#133901
In general doing this for `All` is not right, but this code path is specifically for traits and trait aliases, and there we only ever use `All` for trait aliases.
constants and statics are nullary functions, and struct fields are unary functions.
functions (along with methods and trait methods) are prioritized over other
items, like fields and constants.
