Nuke `Buffer` abstraction from `librustdoc`, take 2 💣
In https://github.com/rust-lang/rust/pull/136656 I found out that the for_html field in the Buffer struct was never read, and pondered if Buffer had any utility at all. `@GuillaumeGomez` said he agrees that it can be just removed. So this PR is me removing it. So, r? `@aDotInTheVoid` , maybe?
Supersedes #136748
tests: `-Copt-level=3` instead of `-O` in codegen tests
An effective blocker for redefining the meaning of `-O` is to stop reusing this somewhat ambiguous alias in our own codegen test suite. The choice between `-Copt-level=2` and `-Copt-level=3` is arbitrary for most of our tests. In most cases it makes no difference, so I set most of them to `-Copt-level=3`, as it will lead to slightly more "normalized" codegen.
try-job: test-various
try-job: arm-android
try-job: armhf-gnu
try-job: i686-gnu-1
try-job: i686-gnu-2
try-job: i686-mingw
try-job: i686-msvc-1
try-job: i686-msvc-2
try-job: aarch64-apple
try-job: aarch64-gnu
tests: `-Copt-level=3` instead of `-O` in assembly tests
An effective blocker for redefining the meaning of `-O` is to stop reusing this somewhat ambiguous alias in our own assembly test suite. The choice between `-Copt-level=2` and `-Copt-level=3` is arbitrary for most of our tests. In most cases it makes no difference, so I set most of them to `-Copt-level=3`, as it will lead to slightly more "normalized" assembly.
Rollup of 8 pull requests
Successful merges:
- #134981 ( Explain that in paths generics can't be set on both the enum and the variant)
- #136698 (Replace i686-unknown-redox target with i586-unknown-redox)
- #136767 (improve host/cross target checking)
- #136829 ([rustdoc] Move line numbers into the `<code>` directly)
- #136875 (Rustc dev guide subtree update)
- #136900 (compiler: replace `ExternAbi::name` calls with formatters)
- #136913 (Put kobzol back on review rotation)
- #136915 (documentation fix: `f16` and `f128` are not double-precision)
r? `@ghost`
`@rustbot` modify labels: rollup
compiler: replace `ExternAbi::name` calls with formatters
Most of these just format the ABI string, so... just format ExternAbi? This makes it more consistent and less jank when we can do it.
[rustdoc] Move line numbers into the `<code>` directly
Fixes#84242.
This is the first for adding support for https://github.com/rust-lang/rust/issues/127334 and also for another feature I'm working on.
A side-effect of this change is that it also fixes source code pages display in lynx since they're not directly in the source code.
To allow having code wrapping, the grid approach doesn't work as the line numbers are in their own container, so we need to move them into the code. Now with this, it becomes much simpler to do what we want (with CSS mostly). One downside: the highlighting became more complex and slow as we need to generate some extra HTML tags directly into the highlighting process. However that also allows to not have a huge HTML size increase.
You can test the result [here](https://rustdoc.crud.net/imperio/move-line-numbers-into-code/scrape_examples/fn.test_many.html) and [here](https://rustdoc.crud.net/imperio/move-line-numbers-into-code/src/scrape_examples/lib.rs.html#10).
The appearance should have close to no changes.
r? ``@notriddle``
improve host/cross target checking
Using an invalid equality operator on `builder.config.build !=/==` can be hard to detect in reviews (which is quite dangerous). Replaced them with `is_host_target`, which is much clearer as it explicitly states what it does.
Explain that in paths generics can't be set on both the enum and the variant
```
error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
--> $DIR/enum-variant-generic-args.rs:54:29
|
LL | Enum::<()>::TSVariant::<()>(());
| --------- ^^ type argument not allowed
| |
| not allowed on tuple variant `TSVariant`
|
= note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
|
LL - Enum::<()>::TSVariant::<()>(());
LL + Enum::TSVariant::<()>(());
|
LL - Enum::<()>::TSVariant::<()>(());
LL + Enum::<()>::TSVariant(());
|
```
Fix#93993.
Rollup of 8 pull requests
Successful merges:
- #135549 (Document some safety constraints and use more safe wrappers)
- #135965 (In "specify type" suggestion, skip type params that are already known)
- #136193 (Implement pattern type ffi checks)
- #136646 (Add a TyPat in the AST to reuse the generic arg lowering logic)
- #136874 (Change the issue number for `likely_unlikely` and `cold_path`)
- #136884 (Lower fn items as ZST valtrees and delay a bug)
- #136885 (i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change)
- #136891 (Check sig for errors before checking for unconstrained anonymous lifetime)
r? `@ghost`
`@rustbot` modify labels: rollup
i686-linux-android: increase CPU baseline to Pentium 4 (without an actual change
As per ``@maurer's`` [comment](https://github.com/rust-lang/rust/issues/136495#issuecomment-2648743078), this shouldn't actually change anything since we anyway add a bunch of extensions that bump things up way beyond Pentium 4. But Pentium 4 is consistent with the other i686 targets and I don't know enough about the exact sequence of CPU generations to be confident with more than this. ;)
Lower fn items as ZST valtrees and delay a bug
Lower it as a ZST instead of a const error, which we can handle mostly fine. Delay a bug so we don't accidentally support it tho.
r? BoxyUwU
Fixes#136855Fixes#136853Fixes#136854Fixes#136337
Only added one test bc that's really the crux of the issue (fn item in array length position).
Change the issue number for `likely_unlikely` and `cold_path`
These currently point to rust-lang/rust#26179, which is nearly a decade old and has a lot of outdated discussion. Move these features to a new tracking issue specifically for the recently added API.
New tracking issue: https://github.com/rust-lang/rust/issues/136873
Add a TyPat in the AST to reuse the generic arg lowering logic
This simplifies ast lowering significantly with little cost to the pattern types parser.
Also fixes any problems we've had with generic args (well, pushes any problems onto the `generic_const_exprs` feature gate)
follow-up to https://github.com/rust-lang/rust/pull/136284#discussion_r1939292367
r? ``@BoxyUwU``
Implement pattern type ffi checks
Previously we just rejected pattern types outright in FFI, but that was never meant to be a permanent situation. We'll need them supported to use them as the building block for `NonZero` and `NonNull` after all (both of which are FFI safe).
best reviewed commit by commit.
In "specify type" suggestion, skip type params that are already known
When we suggest specifying a type for an expression or pattern, like in a `let` binding, we previously would print the entire type as the type system knew it. We now look at the params that have *no* inference variables, so they are fully known to the type system which means that they don't need to be specified.
This helps in suggestions for types that are really long, because we can usually skip most of the type params and make the annotation as short as possible:
```
error[E0282]: type annotations needed for `Result<_, ((..., ..., ..., ...), ..., ..., ...)>`
--> $DIR/really-long-type-in-let-binding-without-sufficient-type-info.rs:7:9
|
LL | let y = Err(x);
| ^ ------ type must be known at this point
|
help: consider giving `y` an explicit type, where the type for type parameter `T` is specified
|
LL | let y: Result<T, _> = Err(x);
| ++++++++++++++
```
Fix#135919.
Document some safety constraints and use more safe wrappers
Lots of unsafe codegen_llvm code has safe wrappers already, so I used some of them and added some where applicable. I stopped here because this diff is large enough and should probably be reviewed independently of other changes.
Properly deeply normalize in the next solver
Turn deep normalization into a `TypeOp`. In the old solver, just dispatch to the `Normalize` type op, but in the new solver call `deeply_normalize`. I chose to separate it into a different type op b/c some normalization is a no-op in the new solver, so this distinguishes just the normalization we need for correctness.
Then use `DeeplyNormalize` in the callsites we used to be using a `CustomTypeOp` (for normalizing known type outlives obligations), and also use it to normalize function args and impl headers in the new solver.
Finally, use it to normalize signatures for WF checks in the new solver as well. This addresses https://github.com/rust-lang/trait-system-refactor-initiative/issues/146.
```
error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
--> $DIR/enum-variant-generic-args.rs:54:29
|
LL | Enum::<()>::TSVariant::<()>(());
| --------- ^^ type argument not allowed
| |
| not allowed on tuple variant `TSVariant`
|
= note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
|
LL - Enum::<()>::TSVariant::<()>(());
LL + Enum::<()>::TSVariant(());
|
```
```
error[E0109]: type arguments are not allowed on enum `Enum` and tuple variant `TSVariant`
--> $DIR/enum-variant-generic-args.rs:54:12
|
LL | Enum::<()>::TSVariant::<()>(());
| ---- ^^ --------- ^^ type argument not allowed
| | |
| | not allowed on tuple variant `TSVariant`
| not allowed on enum `Enum`
|
= note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
|
LL - Enum::<()>::TSVariant::<()>(());
LL + Enum::<()>::TSVariant(());
|
```
Fix#93993.
This should guarantee it tests what we want it to test and no more.
It should probably also run on 64-bit platforms that are not x86-64,
which will often have the vector registers the opt implies.
chore: update rustc-hash 2.1.0 to 2.1.1
This PR updates the rustc-hash crate to include a palliative fix for #135477.
The discussion for this can be found in the issue and on https://github.com/rust-lang/rustc-hash/pull/55.
This PR is the output of running `cargo +nightly update rustc-hash@2.1.0`. I ran all tests locally and they all seem to pass, with the exception of `tests/ui/process/nofile-limit.rs` which always fails on my setup.
`@steffahn` `@orlp` and `@Noratrieb` all have full context on this, I'm opening the pull request trying to be helpful. I'm not sure if anything else needs to be done, like documentation I'm not aware of or running any special CIs but if I can do anything else please let me know!
