Skip to content

Name conflict if Result exists#5

Open
tropf wants to merge 2 commits intotmyers273:mainfrom
tropf:result-name-conflict
Open

Name conflict if Result exists#5
tropf wants to merge 2 commits intotmyers273:mainfrom
tropf:result-name-conflict

Conversation

@tropf
Copy link
Copy Markdown

@tropf tropf commented Nov 7, 2025

Dear Maintainer,

if there is a type called Result in the same scope as the macro invocation to impl_context!, the compilation fails as of now (with a rather cryptic error):

90 | impl_context!(ErrorWithContext(SimpleErr));
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `std::fmt::Error`, found `error::Error`
   |
   = note: expected signature `fn(&ErrorWithContext, &mut Formatter<'_>) -> std::result::Result<_, std::fmt::Error>`
              found signature `fn(&ErrorWithContext, &mut Formatter<'_>) -> std::result::Result<_, error::Error>`
   = note: this error originates in the macro `impl_context` (in Nightly builds, run with -Z macro-backtrace for more info)
help: change the output type to match the trait
  --> /home/s9105947/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/thiserror-context-0.1.2/src/lib.rs:303:63
   |
303-             fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> Result<(), core::fmt::Error> {
303+             fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error> {
   |

error[E0277]: `?` couldn't convert the error to `error::Error`
  --> src/error.rs:90:1
   |
90 | impl_context!(ErrorWithContext(SimpleErr));
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   | |
   | this can't be annotated with `?` because it has type `Result<_, std::fmt::Error>`
   | the trait `From<std::fmt::Error>` is not implemented for `error::Error`

This PR (1) adds a test case for this, and (2) fixes it by referring to core::result::Result instead of only Result.

This is my first time working with macros, and I just followed my gut with the fix. It works, but if it goes against best practices please let me know.

tropf added 2 commits November 7, 2025 17:29
As of now, having a type named "Result" in the same scope as the
impl_context! macro invocation result in a failure. This test reproduces
the behavior. The test passes if it compiles.
Clarify the reference to the type result by explicitly referring to
core::result::Result. This avoids conflicts if there is a non-default
Result type.

Using core::result::Result over std::result::Result to keep minimal.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant