Skip to content

Rollup of 15 pull requests #144382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 43 commits into from
Closed

Conversation

fmease
Copy link
Member

@fmease fmease commented Jul 23, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

dianne and others added 30 commits July 16, 2025 01:44
The previous manual parsing of `serde_json::Value` was a lot of
complicated code and extremely error-prone. It was full of janky
behavior like sometimes ignoring type errors, sometimes erroring for
type errors, sometimes warning for type errors, and sometimes just
ICEing for type errors (the icing on the top).

Additionally, many of the error messages about allowed values were out
of date because they were in a completely different place than the
FromStr impls. Overall, the system caused confusion for users.

I also found the old deserialization code annoying to read. Whenever a
`key!` invocation was found, one had to first look for the right macro
arm, and no go to definition could help.

This PR replaces all this manual parsing with a 2-step process involving
serde.
First, the string is parsed into a `TargetSpecJson` struct. This struct
is a 1:1 representation of the spec JSON. It already parses all the
enums and is very simple to read and write.
Then, the fields from this struct are copied into the actual `Target`.
The reason for this two-step process instead of just serializing into a
`Target` is because of a few reasons

 1. There are a few transformations performed between the two formats
 2. The default logic is implemented this way. Otherwise all the default
    field values would have to be spelled out again, which is
    suboptimal. With this logic, they fall out naturally, because
    everything in the json struct is an `Option`.

Overall, the mapping is pretty simple, with the vast majority of fields
just doing a 1:1 mapping that is captured by two macros. I have
deliberately avoided making the macros generic to keep them simple.

All the `FromStr` impls now have the error message right inside them,
which increases the chance of it being up to date. Some "`from_str`"
impls were turned into proper `FromStr` impls to support this.

The new code is much less involved, delegating all the JSON parsing
logic to serde, without any manual type matching.

This change introduces a few breaking changes for consumers. While it is
possible to use this format on stable, it is very much subject to
change, so breaking changes are expected. The hope is also that because
of the way stricter behavior, breaking changes are easier to deal with,
as they come with clearer error messages.

1. Invalid types now always error, everywhere. Previously, they would
   sometimes error, and sometimes just be ignored (which meant the users
   JSON was still broken, just silently!)
2. This now makes use of `deny_unknown_fields` instead of just warning
   on unused fields, which was done previously. Serde doesn't make it
   easy to get such warning behavior, which was the primary reason that
   this now changed. But I think error behavior is very reasonable too.
   If someone has random stale fields in their JSON, it is likely
   because these fields did something at some point but no longer do,
   and the user likely wants to be informed of this so they can figure
   out what to do.

   This is also relevant for the future. If we remove a field but
   someone has it set, it probably makes sense for them to take a look
   whether they need this and should look for alternatives, or whether
   they can just delete it. Overall, the JSON is made more explicit.

This is the only expected breakage, but there could also be small
breakage from small mistakes. All targets roundtrip though, so it can't
be anything too major.
…nsion

This function can cause false negatives if used incorrectly
(usually "do any of the doc fragments come from a macro" is
the wrong question to ask), and thus it is unused.
rustdoc will not try to do intra-doc linking if the "path"
of a link looks too much like a "real url".

however, only inline links ([text](url)) can actually contain
a url, other types of links (reference links, shortcut links)
contain a *reference* which is later resolved to an actual url.

the "path" in this case cannot be a url, and therefore it should
not be skipped due to looking like a url.

Co-authored-by: Michael Howell <michael@notriddle.com>
this is in an effort to reduce the amount of code churn caused by
this lint triggering on text that was never meant to be a link.

a more principled hierustic for ignoring lints is not possible
without extensive changes, due to the lint emitting code
being so far away from the link collecting code,
and the fact that only the link collecting code
has access to details about how the link appears in the
unnormalized markdown.
collapsed links and reference links have a pretty particular syntax,
it seems unlikely they would show up on accident.

Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay,
  peer_addr and socket_addr.
- peer_addr is needed for implementation of `accept`.

Signed-off-by: Ayush Singh <ayush@beagleboard.org>
…k-warn-more-54191, r=GuillaumeGomez

get rid of some false negatives in rustdoc::broken_intra_doc_links

rustdoc will not try to do intra-doc linking if the "path" of a link looks too much like a "real url".

however, only inline links (`[text](url)`) can actually contain a url, other types of links (reference links, shortcut links) contain a *reference* which is later resolved to an actual url.

the "path" in this case cannot be a url, and therefore it should not be skipped due to looking like a url.

fixes rust-lang#54191

to minimize the number of false positives that will be introduced, the following heuristic is used:

If there's no backticks, be lenient revert to old behavior.
This is to prevent churn by linting on stuff that isn't meant to be a link.
only shortcut links have simple enough syntax that they
are likely to be written accidentlly, collapsed and reference links
need 4 metachars, and reference links will not usually use
backticks in the reference name.
therefore, only shortcut syntax gets the lenient behavior.
here's a truth table for how link kinds that cannot be urls are handled:

|              |  is shortcut link  | not shortcut link |
|--------------|--------------------|-------------------|
| has backtick |    never ignore    |    never ignore   |
| no backtick  | ignore if url-like |    never ignore   |
…petrochenkov

Unquerify extern_mod_stmt_cnum.

Based on rust-lang#143247
r? ``@ghost`` for perf
…ormed, r=oli-obk

Stop using the old `validate_attr` logic for stability attributes

I think this was accidentally missed when implementing the stability attributes?

r? ``@oli-obk``
cc ``@jdonszelmann``
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Jul 23, 2025
@fmease
Copy link
Member Author

fmease commented Jul 23, 2025

@bors r+ rollup=never p=5

@rustbot rustbot added the rollup A PR which is a rollup label Jul 23, 2025
@bors
Copy link
Collaborator

bors commented Jul 23, 2025

📌 Commit 1701ab5 has been approved by fmease

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 23, 2025
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-19-2 failed! Check out the build log: (web) (plain enhanced) (plain)

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

@fmease
Copy link
Member Author

fmease commented Jul 23, 2025

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 23, 2025
@fmease
Copy link
Member Author

fmease commented Jul 23, 2025

Does anyone have a clue which PR is at fault? I'm kinda lost. Nothing touches bootstrap but a bootstrap unit test complains about tests/codegen not being properly registered for x test? How? It's always been there? Nothing changed.

@fmease
Copy link
Member Author

fmease commented Jul 23, 2025

Ah I got it!

@fmease
Copy link
Member Author

fmease commented Jul 23, 2025

codegen/'s been renamed to codegen-llvm and a PR hasn't rebased.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-tidy Area: The tidy tool rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Projects
None yet
Development

Successfully merging this pull request may close these issues.