Enum variants can't be imported via type alias
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
In chrono 0.4.36 we renamed a LocalResult enum to MappedLocalTime, and added a type alias with the name LocalResult.
This turned out to be a breaking change because enum variants can't be imported through a type alias.
enum MappedLocalTime {
Single,
Ambiguous,
None,
}
type LocalResult = MappedLocalTime;
use LocalResult::*;
Gives the error:
Checking alias v0.1.0 (C:\Users\dicke\Documents\alias)
error[E0432]: unresolved import `LocalResult`
--> src\main.rs:9:5
|
9 | use LocalResult::*; // fails
| ^^^^^^^^^^^ `LocalResult` is a type alias, not a module
For more information about this error, try `rustc --explain E0432`.
error: could not compile `alias` (bin "alias") due to previous error
I expected the type alias to behave identical to the enum.
Maybe related to RFC 2338 Type alias enum variants.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the provided MappedLocalTime/LocalResult example and read RFC 2338, Type alias enum variants, to understand the intended language behavior. Done means enum variants can be imported through the type alias without the unresolved-import error, with coverage for the demonstrated case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100