Show whether ?Sized parameters are actually Sized

[obi1kenobi]

A mostly-working, "some polish still required" attempt at fixing #143197

• Add a new allow_unsized: bool field to GenericParamDefKind::Type.
• Expose that field as-is to rustdoc JSON, without tampering with ?Sized clauses there.
• Suppress ?Sized from HTML where Sized is implied.

I haven't figured out a good way to suppress ?Sized from impl Trait in function parameters in HTML yet. The synthetic generics data doesn't seem to be "nearby" so more refactoring might be needed. I included a failing test case to remind me of this.

r? fmease

[rustbot]

fmease is currently at their maximum review capacity.
They may take a while to respond.

[obi1kenobi]

cc @aDotInTheVoid

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

Checking tidy rustdoc_json...
Running eslint on rustdoc JS files
No error code explanation was removed!
tidy: Skipping binary file check, read-only filesystem
##[error]tidy error: /checkout/src/librustdoc/html/format.rs:1065: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.1.1)
linting python files
All checks passed!
checking python file formatting
28 files already formatted
checking C++ file formatting
some tidy checks failed
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:01:25
  local time: Mon Jul  7 04:28:49 UTC 2025
  network time: Mon, 07 Jul 2025 04:28:49 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[fmease]

I know this is WIP but if I may let me collect initial perf data (I've only skimmed the changes and haven't reviewed anything yet).

[@]bors2 try [@]rust-timer queue

[rust-bors]

⌛ Trying commit bba78b8 with merge 55a9833…

To cancel the try build, run the command @bors2 try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 55a9833 (55a98339ad460f9063d820eb23c41710d6f6e5b9, parent: ca98d4d4b3114116203699c2734805547df86f9a)

[rust-timer]

Finished benchmarking commit (55a9833): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.2%, 3.1%]	20
Regressions ❌ (secondary)	2.0%	[0.4%, 3.9%]	25
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.2%	[0.2%, 3.1%]	20

Max RSS (memory usage)

Results (primary 1.6%, secondary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.2%, 2.0%]	6
Regressions ❌ (secondary)	2.4%	[1.4%, 3.9%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.6%	[1.2%, 2.0%]	6

Cycles

Results (primary 2.4%, secondary 2.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.4%	[2.0%, 2.9%]	6
Regressions ❌ (secondary)	3.1%	[2.4%, 3.7%]	15
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-2.8%, -2.8%]	1
All ❌✅ (primary)	2.4%	[2.0%, 2.9%]	6

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 463.852s -> 465.016s (0.25%)
Artifact size: 372.07 MiB -> 372.15 MiB (0.02%)

[aDotInTheVoid]

(I've not looked at the impl).

I agree that we should probably remove these misleading bounds in HTML.

But I wounder if we should do the same in JSON? Rather than having a separate bool field?

[aDotInTheVoid]

This should test that we don't remove the ?Sized bound from the bounds list, even though it ends up not mattering.

[obi1kenobi]

But I wonder if we should do the same in JSON? Rather than having a separate bool field?

It's a good question. I think there are two broadly-speaking reasonable choices, and one option we should avoid.

We should avoid stripping ?Sized without including a way to say we did so. If we did that, cargo-semver-checks will get flooded with incorrect "false-positive" bug reports of people saying "look ?Sized is right here but c-s-c says I removed it." We'll probably end up having to try to parse source code to figure out if ?Sized is there so we can customize the diagnostic message to explain why the ?Sized bound doesn't matter. This isn't great and I'd love to avoid it if we can. I bet cargo-public-api would have the same issue, so I don't think it's unique to us.

Then the two broadly-acceptable options are both adding a bool, and differ over what the bool says:

• leave ?Sized in but say if unsized types are disallowed despite it (this PR)
• strip ?Sized but say if it was originally present

I'm ambivalent between the two options, and could easily be talked into going for the second one if you have a strong preference that way.

[obi1kenobi]

Taking a look at the benchmarks, I'm surprised that e.g. a simple "hello world" program takes 3% more instructions to document when there are no generics in it. This seems suspect — I wouldn't expect my code changes to get hit basically at all, let alone to the tune of a 3% slowdown.