-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Rollup of 7 pull requests #143026
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
Rollup of 7 pull requests #143026
Conversation
Signed-off-by: Karan Janthe <[email protected]>
Signed-off-by: Karan Janthe <[email protected]>
The cross-build megatest gets extremely conflict-prone, so start cutting it into smaller pieces.
… restore snapshot when set subdiag arg Signed-off-by: xizheyin <[email protected]>
…secure-abis-always-match-c, r=compiler-errors Withdraw the claim `extern "C-cmse-nonsecure-*"` always matches `extern "C"` We currently claim that `extern "C-cmse-nonsecure-*"` ABIs will always match `extern "C"`, but that seems... **optimistic** when one considers that `extern "C"` is ambiguous enough to be redefined in ways we may not want the Cortex M Security Extensions ABIs to mirror. If some configuration, feature, or other platform quirk that applied to Arm CPUs with CMSE would modify the `extern "C"` ABI, it does not seem like we should guarantee that also applies to the `extern "cmse-nonsecure-*"` ABIs. Anything involving target modifiers that might affect register availability or usage could make us liars if, for instance, clang decides those apply to normal C functions but not ones with the CMSE attributes, but we still want to have interop with the C compiler. We simply do not control enough of the factors involved to both force these ABIs to match and still provide useful interop, so we shouldn't implicitly promise they do. We should leave this judgement call to the decisions of platform experts who can afford to keep up with the latest news from Cambridge, instead of enshrining today's hopeful guess forever in Rust's permitted ABIs. It's a bit weird anyways. - The attributes are `__attribute__((cmse_nonsecure_call))` and `__attribute__((cmse_nonsecure_entry))`, so the obvious choice is `extern "cmse-nonsecure-call"` and `extern "cmse-nonsecure-entry"`. - We do not prefix any other ABI that reflects (or even *is*) a C ABI with "C-", with the exception of the Rust-defined `extern "C-unwind`", e.g. we do not have `extern "C-aapcs"` or `extern "C-sysv64"`. Tracking issues: - rust-lang#75835 - rust-lang#81391
`tests/ui`: A New Order [8/N] Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang#133895.
…li-obk Add runtime check to avoid overwrite arg in `Diag` ## Origin PR description At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it. For the code before the rust-lang#142015 change, it won't compile because it will report an error ``` arg `instance`already exists. ``` This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure: 1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~ 2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to rust-lang#142031 (comment), and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~ ## Final Decision After trying and discussing, we made a final decision. For `#[derive(Subdiagnostic)]`, This PR made two changes: 1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`. 2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
…useZ4 Add PrintTAFn flag for targeted type analysis printing ## Summary This PR adds a new `PrintTAFn` flag to the `-Z autodiff` option that allows printing type analysis information for a specific function, rather than all functions. ## Changes ### New Flag - Added `PrintTAFn=<function_name>` option to `-Z autodiff` - Usage: `-Z autodiff=Enable,PrintTAFn=my_function_name` ### Implementation Details - **Rust side**: Added `PrintTAFn(String)` variant to `AutoDiff` enum - **Parser**: Updated `parse_autodiff` to handle `PrintTAFn=<function_name>` syntax with proper error handling - **FFI**: Added `set_print_type_fun` function to interface with Enzyme's `FunctionToAnalyze` command line option - **Documentation**: Updated help text and documentation for the new flag ### Files Modified - `compiler/rustc_session/src/config.rs`: Added `PrintTAFn(String)` variant - `compiler/rustc_session/src/options.rs`: Updated parser and help text (now shows `PrintTAFn` in the list) - `compiler/rustc_codegen_llvm/src/llvm/enzyme_ffi.rs`: Added FFI function and static variable - `compiler/rustc_codegen_llvm/src/back/lto.rs`: Added handling for new flag - `src/doc/rustc-dev-guide/src/autodiff/flags.md`: Updated documentation - `src/doc/unstable-book/src/compiler-flags/autodiff.md`: Updated documentation ## Testing The flag can be tested with: ```bash rustc +enzyme -Z autodiff=Enable,PrintTAFn=square test.rs ``` This will print type analysis information only for the function named "square" instead of all functions. ## Error Handling The parser includes proper error handling: - Missing argument: `PrintTAFn` without `=<function_name>` will show an error - Unknown options: Invalid autodiff options will be reported r? ```@ZuseZ4```
…-dead Check CoerceUnsized impl validity before coercing Self-explanatory from the title. Fixes rust-lang#126982 Fixes rust-lang#131048 Fixes rust-lang#134217 Fixes rust-lang#126269 Fixes rust-lang#138265
…ty-abis, r=jieyouxu Convert some ABI tests to use `extern "rust-invalid"`
Make `Sub`, `Mul`, `Div` and `Rem` `const_traits` Generally useful for implementation, like Add.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 0fa4ec6cde In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 0fa4ec6 (parent) -> bc4376f (this PR) Test differencesShow 106 test diffsStage 1
Stage 2
Additionally, 64 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard bc4376fa73b636eb6f2c7d48b1f731d70f022c4b --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Successful merges:
extern "C-cmse-nonsecure-*"
always matchesextern "C"
#142146 (Withdraw the claimextern "C-cmse-nonsecure-*"
always matchesextern "C"
)tests/ui
: A New Order [8/N] #142200 (tests/ui
: A New Order [8/N])Diag
#142724 (Add runtime check to avoid overwrite arg inDiag
)extern "rust-invalid"
#142992 (Convert some ABI tests to useextern "rust-invalid"
)Sub
,Mul
,Div
andRem
const_traits
#143000 (MakeSub
,Mul
,Div
andRem
const_traits
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup