Skip to content

fix build with latest nightly - #171

Open
mqqz wants to merge 1 commit into
Rust-for-Linux:mainfrom
mqqz:fix-ci
Open

fix build with latest nightly#171
mqqz wants to merge 1 commit into
Rust-for-Linux:mainfrom
mqqz:fix-ci

Conversation

@mqqz

@mqqz mqqz commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Binding a value of an uninhabited type now makes everything following it unreachable. In stack_pin_init! the Infallible annotation is such a binding, so the match x {} after it is reported as unreachable and -Dwarnings turns that into an error.

Annotate the Result instead of the error value, which requires the initializer to be infallible just the same but has nothing following it.

Infallible is also printed as ! in diagnostics now, so bless the two tests that show it.

Binding a value of an uninhabited type now makes everything following it
unreachable. In `stack_pin_init!` the `Infallible` annotation is such a
binding, so the `match x {}` after it is reported as unreachable and
`-Dwarnings` turns that into an error.

Annotate the `Result` instead of the error value, which requires the
initializer to be infallible just the same but has nothing following it.

`Infallible` is also printed as `!` in diagnostics now, so bless the two
tests that show it.

Signed-off-by: Mohamad Alsadhan <mo@sdhn.cc>
@nbdd0121

Copy link
Copy Markdown
Member

I created #172 as an alternative fix which I think is clearer.

nbdd0121 added a commit that referenced this pull request Aug 28, 2026
In Rust 1.100.0, `Infallible` will become an alias of `!`. The let
binding in `stack_pin_init` will thus become unreachable and produce a
"unreachable expression" warning for subsequent match, and thus will fail
`-Dwarnings` build. For this macro, all we need to know is that the error
type is uninhabited, so replace this with a irrefutable pattern instead.

Reported-by: Mohamad Alsadhan <mo@sdhn.cc>
Closes: #171
Signed-off-by: Gary Guo <gary@garyguo.net>
@mqqz

mqqz commented Aug 28, 2026

Copy link
Copy Markdown
Contributor Author

I created #172 as an alternative fix which I think is clearer.

Nice, I'll rebase #155 when it lands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants