MIR-build: No longer emit assumes in enum-as casting
This just uses the `valid_range` from the backend, so it's duplicating the range metadata that now we include on parameters and loads, and thus no longer seems to be useful -- notably there's no codegen test failures from removing it.
(Because it's using data from the same source as the backend annotations, it doesn't do anything to mitigate things like rust-lang/rust#144388 where the range in the layout is more permissive than the actual possible discriminants. A variant of this that actually checked the discriminants more specifically might be useful, so could potentially be added in future, but I don't think the *current* checks are actually providing value.)
r? mir
Randomly turns out that this
Fixes https://github.com/rust-lang/rust/issues/121097
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#143374 (Unquerify extern_mod_stmt_cnum.)
- rust-lang/rust#143838 (std: net: uefi: Add support to query connection data)
- rust-lang/rust#144014 (don't link to the nightly version of the Edition Guide in stable lints)
- rust-lang/rust#144094 (Ensure we codegen the main fn)
- rust-lang/rust#144218 (Use serde for target spec json deserialize)
- rust-lang/rust#144221 (generate elf symbol version in raw-dylib)
- rust-lang/rust#144240 (Add more test case to check if the false note related to sealed trait suppressed)
- rust-lang/rust#144247 (coretests/num: use ldexp instead of hard-coding a power of 2)
- rust-lang/rust#144276 (Use less HIR in check_private_in_public.)
- rust-lang/rust#144278 (add Rev::into_inner)
- rust-lang/rust#144317 (pass build.npm from bootstrap to tidy and use it for npm install)
- rust-lang/rust#144320 (rustdoc: avoid allocating a temp String for aliases in search index)
- rust-lang/rust#144334 (rustc_resolve: get rid of unused rustdoc::span_of_fragments_with_expansion)
- rust-lang/rust#144335 (Don't suggest assoc ty bound on non-angle-bracketed problematic assoc ty binding)
- rust-lang/rust#144358 (Stop using the old `validate_attr` logic for stability attributes)
r? `@ghost`
`@rustbot` modify labels: rollup
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`````
rustc_resolve: get rid of unused rustdoc::span_of_fragments_with_expansion
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.
r? `````@GuillaumeGomez`````
generate elf symbol version in raw-dylib
For link names like `aaa@bbb`, it generates a symbol named `aaa` and a version named `bbb`.
For link names like `aaa\0bbb`, `aaa@`@bbb`` or `aa@bb@cc`, it emits errors.
It adds a test that the executable is linked with glibc using raw-dylib.
cc rust-lang/rust#135694
Use serde for target spec json deserialize
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.
fixesrust-lang/rust#144153
Ensure we codegen the main fn
This fixes two bugs. The one that was identified in the linked issue is that when we have a `main` function, mono collection didn't consider it as an extra collection root.
The other is that since CGU partitioning doesn't know about the call edges between the entrypoint functions, naively it can put them in different CGUs and mark them all as internal. Which would result in LLVM just deleting all of them. There was an existing hack to exclude `lang = "start"` from internalization, which I've extended to include `main`.
Fixes https://github.com/rust-lang/rust/issues/144052
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
Various refactors to the LTO handling code (part 2)
Continuing from https://github.com/rust-lang/rust/pull/143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.
resolve: Make disambiguators for underscore bindings module-local (take 2)
The difference with https://github.com/rust-lang/rust/pull/144013 can be seen in the second commit.
Now we just keep a separate disambiguator counter in every `Module`, instead of a global counter in `Resolver`.
This will be ok for parallel import resolution because we'll need to lock the module anyway when updating `resolutions` and other fields in it.
And for external modules the disabmiguator could be just passed as an argument to `define_extern`, without using any cells or locks, once https://github.com/rust-lang/rust/pull/143884 lands.
Unblocks https://github.com/rust-lang/rust/pull/143884.
coverage: Enlarge empty spans during MIR instrumentation, not codegen
This re-lands the part of rust-lang/rust#140847 that was (hopefully) not responsible for the coverage-instrumentation regressions that caused that PR to be reverted.
---
Enlarging empty spans was historically performed during MIR instrumentation, but had to be moved to codegen as part of larger changes in rust-lang/rust#134497, leading to the status quo. But now there should be no reason not to move that step back to its more logical home in instrumentaion.
mbe: Use concrete type for `get_unused_rule`
Rather than adding `get_unused_rule` to the `TTMacroExpander` trait, put
it on the concrete `MacroRulesMacroExpander`, and downcast to that type
via `Any` in order to call it.
Suggested-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
r? ```````@petrochenkov```````
Clean `rustc/parse/src/lexer` to improve maintainability
This PR refactors the lexer code to improve maintainability and eliminate code duplication.
In the first commit, I improve the error handling:
- rename `make_unclosed_delims_error` to more appropriate `make_mismatched_closing_delims_errors`
- changes return type from Option<Diag> to `Vec<Diag>` to avoid lengthy vec processing at `lex_token_trees`
- use `splice` instead of `extend` to make the logic clearer, since `errs` sounds more generic and better suited as a return value
In the second commit, I replace the magic number 5 with UNCLOSED_DELIMITER_SHOW_LIMIT constant.
In the third commit, I moves `eof_err` function below parsing logic for better code flow.
In the forth one, I extract `calculate_spacing` function to eliminate duplicate spacing logic between `bump` and `bump_minimal` functions.
r? compiler
Implement AST visitors using a derive macro.
AST visitors are large and error-prone beasts. This PR attempts to write them using a derive macro.
The design uses three traits: `Visitor`, `Visitable`, `Walkable`.
- `Visitor` is the trait implemented by downstream crates, it lists `visit_stuff` methods, which call `Walkable::walk_ref` by default;
- `Walkable` is derived using the macro, the generated `walk_ref` method calls `Visitable::visit` on each component;
- `Visitable` is implemented by `common_visitor_and_walkers` macro, to call the proper `Visitor::visit_stuff` method if it exists, to call `Walkable::walk_ref` if there is none.
I agree this is quite a lot of spaghetti macros. I'm open to suggestions on how to reduce the amount of boilerplate code.
If this PR is accepted, I believe the same design can be used for the HIR visitor.
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.
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of https://github.com/rust-lang/rust/pull/144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang/rust#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
Rather than adding `get_unused_rule` to the `TTMacroExpander` trait, put
it on the concrete `MacroRulesMacroExpander`, and downcast to that type
via `Any` in order to call it.
Suggested-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
