Remove the From derive macro from prelude
#145563
Merged
+57
−22
Conversation
This file contains hidden or 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
rustbot
added
S-waiting-on-review
|
Changes to the code generated for builtin derived traits. cc @nnethercote |
This comment was marked as outdated.
This comment was marked as outdated.
To avoid backwards compatibility problems.
Kobzol
force-pushed
the
remove-from-from-prelude
branch
from
bcb8a5b to
a6a760e
Compare
|
If #139493 lands, this could just be |
|
@bors r+ |
bors
added
S-waiting-on-bors
|
Wouldn't |
|
It can't be |
bors
added a commit
that referenced
this pull request
Aug 19, 2025
Rollup of 19 pull requests Successful merges: - #140956 (`impl PartialEq<{str,String}> for {Path,PathBuf}`) - #141744 (Stabilize `ip_from`) - #142681 (Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]`) - #142871 (Trivial improve doc for transpose ) - #144252 (Do not copy .rmeta files into the sysroot of the build compiler during check of rustc/std) - #144476 (rustdoc-search: search backend with partitioned suffix tree) - #144567 (Fix RISC-V Test Failures in ./x test for Multiple Codegen Cases) - #144804 (Don't warn on never to any `as` casts as unreachable) - #144960 ([RTE-513] Ignore sleep_until test on SGX) - #145013 (overhaul `&mut` suggestions in borrowck errors) - #145041 (rework GAT borrowck limitation error) - #145243 (take attr style into account in diagnostics) - #145405 (cleanup: use run_in_tmpdir in run-make/rustdoc-scrape-examples-paths) - #145432 (cg_llvm: Small cleanups to `owned_target_machine`) - #145484 (Remove `LlvmArchiveBuilder` and supporting code/bindings) - #145557 (Fix uplifting in `Assemble` step) - #145563 (Remove the `From` derive macro from prelude) - #145565 (Improve context of bootstrap errors in CI) - #145584 (interpret: avoid forcing all integer newtypes into memory during clear_provenance) Failed merges: - #145359 (Fix bug where `rustdoc-js` tester would not pick the right `search.js` file if there is more than one) - #145573 (Add an experimental unsafe(force_target_feature) attribute.) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Aug 19, 2025
Rollup merge of #145563 - Kobzol:remove-from-from-prelude, r=petrochenkov Remove the `From` derive macro from prelude The new `#[derive(From)]` functionality (implemented in #144922) caused name resolution ambiguity issues (#145524). The reproducer looks e.g. like this: ```rust mod foo { pub use derive_more::From; } use foo::*; #[derive(From)] // ERROR: `From` is ambiguous struct S(u32); ``` It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require #139493 to land. I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue. Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit. Fixes: #145524 r? ``@petrochenkov``
|
Bors hasn't noticed that this was merged. @bors r- retry |
bors
added
S-waiting-on-author
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Aug 20, 2025
…=petrochenkov Remove the `From` derive macro from prelude The new `#[derive(From)]` functionality (implemented in rust-lang#144922) caused name resolution ambiguity issues (rust-lang#145524). The reproducer looks e.g. like this: ```rust mod foo { pub use derive_more::From; } use foo::*; #[derive(From)] // ERROR: `From` is ambiguous struct S(u32); ``` It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang#139493 to land. I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue. Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit. Fixes: rust-lang#145524 r? ``@petrochenkov``
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.
The new
#[derive(From)]functionality (implemented in #144922) caused name resolution ambiguity issues (#145524). The reproducer looks e.g. like this:It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the
Frommacro into the prelude. That will probably require #139493 to land.I created a new module in core (and re-exported it in std) called
from, where I re-exported theFrommacro. I think that since this is a new module, it should not have the same backwards incompatibility issue.Happy to hear suggestions about the naming - maybe it would make sense as
core::macros::from::From? But we already had a precedent in thecore::assert_matchesmodule, so I just followed suit.Fixes: #145524
r? @petrochenkov