Remove redundant is_dyn_thread_safe checks

[zetanumbers]

Refactor uses of FromDyn to reduce number of redundant is_dyn_thread_safe checks by replacing FromDyn::from with check_dyn_thread_safe in tandem with existing FromDyn::derive so that the users would avoid redundancy in the future.

PR is split up into multiple commits for an easier review.

[rustbot]

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 16 candidates

[Zoxc]

The change to reduce the number of checks is good here.

I'm not sure about adding a separate type for it. The new type DynThreadSafe is equivalent to FromDyn<()> and the same change could be done by adding a FromDyn::try_from method. The naming of DynThreadSafe seem quite trait-like to me too. It seems like it could be more something like DynThreadSafetyEnabled.

[zetanumbers]

The naming of DynThreadSafe seem quite trait-like to me too.

Yes. That's because traits are predicates over types. Analogously DynThreadSafe is also a predicate but over a static variable. These are the same in dependent type systems.

[zetanumbers]

I'm not sure about adding a separate type for it. The new type DynThreadSafe is equivalent to FromDyn<()> and the same change could be done by adding a FromDyn::try_from method.

FromDyn is simply a newtype over a pair (T, DynThreadSafe) to implement Send and Sync. If those weren't rust traits which require a unique implementation then having a newtype wouldn't be necessary.

[Zoxc]

FromDyn is simply a newtype over a pair (T, DynThreadSafe) to implement Send and Sync. If those weren't rust traits which require a unique implementation then having a newtype wouldn't be necessary.

Not quite sure what your point is here. The addition of DynThreadSafe isn't necessary since it's the same type as FromDyn<()> (both before and after the PR). What I'm unsure about is if its addition is a good idea.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[zetanumbers]

Well fine, no renames - no renames.

[rust-log-analyzer]

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

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

Executing "/scripts/stage_2_test_set1.sh"
+ /scripts/stage_2_test_set1.sh
PR_CI_JOB set; skipping tidy
+ '[' 1 == 1 ']'
+ echo 'PR_CI_JOB set; skipping tidy'
+ SKIP_TIDY='--skip tidy'
+ ../x.py --stage 2 test --skip tidy --skip compiler --skip src
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.04s
##[endgroup]
downloading https://static.rust-lang.org/dist/2026-03-05/rustfmt-nightly-aarch64-unknown-linux-gnu.tar.xz
---
   Compiling rustc_parse v0.0.0 (/checkout/compiler/rustc_parse)
[RUSTC-TIMING] rustc_parse test:false 15.791
   Compiling rustc_attr_parsing v0.0.0 (/checkout/compiler/rustc_attr_parsing)

Session terminated, killing shell...::group::Clock drift check
##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
  local time: Tue Mar 17 11:53:28 UTC 2026
  network time: Tue, 17 Mar 2026 11:53:29 GMT
##[endgroup]
 ...killed.
##[error]The operation was canceled.

[zetanumbers]

What

[JonathanBrouwer]

GitHub moment... I've restarted PR ci

[JonathanBrouwer]

@bors r+ rollup

View changes since this review

[rust-bors]

📌 Commit 3973d9f has been approved by JonathanBrouwer

It is now in the queue for this repository.

[JonathanBrouwer]

Always love some extra static checks, thanks for the work!
(I'm also a big fan of dependent types btw :3)