Rollup of 8 pull requests #132343
Closed
Rollup of 8 pull requests #132343
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By using `token_descr`, as is done for many other errors, we can get slightly better descriptions in error messages, e.g. "macro expansion ignores token `let` and any following" becomes "macro expansion ignores keyword `let` and any tokens following". This will be more important once invisible delimiters start being mentioned in error messages -- without this commit, that leads to error messages such as "error at ``" because invisible delimiters are pretty printed as an empty string.
Much like the previous commit. I think the removal of "the token" in each message is fine here. There are many more error messages that mention tokens without saying "the token" than those that do say it.
Chaofan and Kai will be passing over maintainership for the target over to David Tenty and Chris Cambly.
The initial naming of "Abi" was an awful mistake, conveying wrong ideas about how psABIs worked and even more about what the enum meant. It was only meant to represent the way the value would be described to a codegen backend as it was lowered to that intermediate representation. It was never meant to mean anything about the actual psABI handling! The conflation is because LLVM typically will associate a certain form with a certain ABI, but even that does not hold when the special cases that actually exist arise, plus the IR annotations that modify the ABI. Reframe `rustc_abi::Abi` as the `BackendRepr` of the type, and rename `BackendRepr::Aggregate` as `BackendRepr::Memory`. Unfortunately, due to the persistent misunderstandings, this too is now incorrect: - Scattered ABI-relevant code is entangled with BackendRepr - We do not always pre-compute a correct BackendRepr that reflects how we "actually" want this value to be handled, so we leave the backend interface to also inject various special-cases here - In some cases `BackendRepr::Memory` is a "real" aggregate, but in others it is in fact using memory, and in some cases it is a scalar! Our rustc-to-backend lowering code handles this sort of thing right now. That will eventually be addressed by lifting duplicated lowering code to either rustc_codegen_ssa or rustc_target as appropriate.
This is a standard pattern: ``` MyAnalysis.into_engine(tcx, body).iterate_to_fixpoint() ``` `into_engine` and `iterate_to_fixpoint` are always called in pairs, but sometimes with a builder-style `pass_name` call between them. But a builder-style interface is overkill here. This has been bugging me a for a while. This commit: - Merges `Engine::new` and `Engine::iterate_to_fixpoint`. This removes the need for `Engine` to have fields, leaving it as a trivial type that the next commit will remove. - Renames `Analysis::into_engine` as `Analysis::iterate_to_fixpoint`, gives it an extra argument for the optional pass name, and makes it call `Engine::iterate_to_fixpoint` instead of `Engine::new`. This turns the pattern from above into this: ``` MyAnalysis.iterate_to_fixpoint(tcx, body, None) ``` which is shorter at every call site, and there's less plumbing required to support it.
It's no longer needed. `Engine::iterate_to_fixpoint` can be inlined into `Analysis::iterate_to_fixpoint` and removed. The commit also renames `engine.rs` as `results.rs`.
…=Nadrieril Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains fixes rust-lang#128661 Is there any preference where the test goes? There looks to be several places it could fit.
TypingMode: merge intercrate, reveal, and defining_opaque_types This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s. Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists. As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`. #### `TypingMode::from_param_env` I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598 r? `@compiler-errors`
… r=compiler-errors Rename `rustc_abi::Abi` to `BackendRepr` Remove the confabulation of `rustc_abi::Abi` with what "ABI" actually means by renaming it to `BackendRepr`, and rename `Abi::Aggregate` to `BackendRepr::Memory`. The type never actually represented how things are passed, as that has to have `PassMode` considered, at minimum, but rather it just is how we represented some things to the backend. This conflation arose because LLVM, the primary backend at the time, would lower certain IR forms using certain ABIs. Even that only somewhat was true, as it broke down when one ventured significantly afield of what is described by the System V AMD64 ABI either by using different architectures, ABI-modifying IR annotations, the same architecture **with different ISA extensions enabled**, or other... unexpected delights. Unfortunately both names are still somewhat of a misnomer right now, as people have written code for years based on this misunderstanding. Still, their original names are even moreso, and for better or worse, this backend code hasn't received as much maintenance as the rest of the compiler, lately. Actually arriving at a correct end-state will simply require us to disentangle a lot of code in order to fix, much of it pointlessly repeated in several places. Thus this is not an "actual fix", just a way to deflect further misunderstandings.
…ainters, r=workingjubilee powerpc64-ibm-aix: update maintainters Chaofan (``@ecnelises)`` and Kai (``@bzEq)`` will be passing over maintainership for the target over to David Tenty (``@daltenty)`` and Chris Cambly (``@gilamn5tr)``
…ners, r=compiler-errors Point to Fuchsia team in platform support docs This consolidates our docs into a single source of truth for the current Fuchsia maintainers. r? ``@tmandry``
…r=estebank Use `token_descr` more in error messages This is the first two commits from rust-lang#124141, put into their own PR to get things rolling. Commit messages have the details. r? `@estebank` cc `@petrochenkov`
Remove `Engine` It's just unnecessary plumbing. Removing it results in less code, and simpler code. r? `@cjgillot`
…rrors cg_llvm: Consistently use safe wrapper function `set_section` Follow-up to rust-lang#131962 and rust-lang#132260 (comment). To avoid too much scope creep, I've deliberately kept the changes to `LLVMRustGetSliceFromObjectDataByName` as minimal as possible.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 30, 2024
…kingjubilee Rollup of 8 pull requests Successful merges: - rust-lang#129394 (Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains) - rust-lang#131856 (TypingMode: merge intercrate, reveal, and defining_opaque_types) - rust-lang#132246 (Rename `rustc_abi::Abi` to `BackendRepr`) - rust-lang#132322 (powerpc64-ibm-aix: update maintainters) - rust-lang#132327 (Point to Fuchsia team in platform support docs) - rust-lang#132332 (Use `token_descr` more in error messages) - rust-lang#132338 (Remove `Engine`) - rust-lang#132340 (cg_llvm: Consistently use safe wrapper function `set_section`) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
irrefutable_let_patternson leading patterns ifelse iflet-chains #129394 (Don't lintirrefutable_let_patternson leading patterns ifelse iflet-chains)rustc_abi::AbitoBackendRepr#132246 (Renamerustc_abi::AbitoBackendRepr)token_descrmore in error messages #132332 (Usetoken_descrmore in error messages)Engine#132338 (RemoveEngine)set_section#132340 (cg_llvm: Consistently use safe wrapper functionset_section)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup