core::error, no_std

[jordens]

error_in_core has been stabilized in 1.81. This PR builds on the work of #64/#211/#244.

• Introduce a std feature (default enabled) to gate the std components (currently only std::path)
• Private re-export of std::error or core::error to avoid bumping MSRV for std. no_std does require 1.81.
• Tests/docs/CI updates
• Macro hygiene: impl/expand.rs uses full absolute paths.

It's unclear to me whether it's better to bump the MSRV (1.56 -> 1.81) or use a private re-export of either std::error or core::error (as done here) to keep support for rustc < 1.81.

[jstarks]

Given the wide use of this crate, it seems very unlikely that an MSRV bump would be accepted.

[jordens]

@dtolnay what's your take on the PR, especially regarding the MSRV question?

It's unclear to me whether it's better to bump the MSRV (1.56 -> 1.81 as done in this draft) or use a private re-export of either std::error or core::error (as done previously) to keep support for rustc < 1.81.

[umgefahren]

What if one is just able to somehow pass core::error instead of std::error?

[kayabaNerve]

My personal belief is default-features = false should be MSRV 1.81 and features = ["std"] should be MSRV 1.56.

[jordens]

@dtolnay any guidance on how you'd like to see it done?

[kayabaNerve]

PR LGTM with edge case that I don't believe you can import thiserror with a distinct package name with this path (I'm unsure if you could already).

[jordens]

@dtolnay I know this is at least the third PR attempting it and this has come up many times in the past. But now that your condition can be met, what's missing? And what can we do to get this in?

[ognevny]

this code doesn't work with my #![no_std] lib...

60 | #[derive(Debug, Error, PartialEq, Eq)]
   |                 ^^^^^
   |                 |
   |                 use of undeclared crate or module `std`
   |                 in this derive macro expansion
   |
  ::: ~/.cargo/git/checkouts/thiserror-8e8b6321d051832b/c9cd3b9/impl/src/lib.rs:33:1
   |
33 | pub fn derive_error(input: TokenStream) -> TokenStream {
   | ------------------------------------------------------ in this expansion of `#[derive(Error)]`
   |
help: consider importing this module
   |
5  + use core::error;

[ZhekaS]

this code doesn't work with my #![no_std] lib...

I am getting a similar one for a bin crate:

error[E0433]: failed to resolve: use of undeclared crate or module `std`
  --> src/********:49:17
   |
49 | #[derive(Debug, Error)]
   |                 ^^^^^ use of undeclared crate or module `std`
   |
   = note: this error originates in the derive macro `Error` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider importing this module
   |
1  + use core::error;
   |

For more information about this error, try `rustc --explain E0433`.

Looks like it only happens when fn source is derived. Then the macro expansion looks like:

fn source(&self) -> ::core::option::Option<&(dyn std::error::Error + 'static)> ....

Note the std there...
Can be fixed by:

diff --git a/impl/src/expand.rs b/impl/src/expand.rs
index 7c1e351..7e05e8e 100644
--- a/impl/src/expand.rs
+++ b/impl/src/expand.rs
@@ -267,7 +267,7 @@ fn impl_enum(input: Enum) -> TokenStream {
             }
         });
         Some(quote! {
-            fn source(&self) -> ::core::option::Option<&(dyn std::error::Error + 'static)> {
+            fn source(&self) -> ::core::option::Option<&(dyn ::thiserror::__private::error::Error + 'static)> {
                 use thiserror::__private::AsDynError as _;
                 #[allow(deprecated)]
                 match self {

[jdygert-spok]

PR LGTM with edge case that I don't believe you can import thiserror with a distinct package name with this path (I'm unsure if you could already).

Looks like you already couldn't, at least when using certain attributes, since there's existing use of the __private module.

this code doesn't work with my #![no_std] lib...

Missed one: https://github.com/dtolnay/thiserror/pull/304/files#diff-bb7dbcae2958da4ff43be22e512a8abfb22393983d7e49717d5a8ec25ea7abaeR270

I think this PR would be more likely to be merged if CI would catch this.

[ZhekaS]

Missed one: https://github.com/dtolnay/thiserror/pull/304/files#diff-bb7dbcae2958da4ff43be22e512a8abfb22393983d7e49717d5a8ec25ea7abaeR270

Works like a charm with the above fix on a somewhat large no_std project. Really need it to get in ASAP.

[jordens]

Fixed in the commit above.

[ognevny]

now it fails to publish my lib into crates-io

error[E0433]: failed to resolve: use of undeclared crate or module `std`
  --> src/....rs:62:17
   |
62 | #[derive(Debug, Error, PartialEq, Eq)]
   |                 ^^^^^
   |                 |
   |                 use of undeclared crate or module `std`
   |                 in this derive macro expansion
   |
  ::: ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thiserror-impl-1.0.63/src/lib.rs:33:1
   |
33 | pub fn derive_error(input: TokenStream) -> TokenStream {
   | ------------------------------------------------------ in this expansion of `#[derive(Error)]`
   |
help: consider importing this module
   |
5  + use core::error;
   |

error[E0433]: failed to resolve: use of undeclared crate or module `std`
  --> src/....rs:68:13
   |
68 |     #[error(transparent)]
   |             ^^^^^^^^^^^ use of undeclared crate or module `std`
   |
help: consider importing one of these items
   |
5  + use core::error::Error;
   |
5  + use core::fmt::Error;
   |
5  + use regex::Error;
   |

error[E0433]: failed to resolve: use of undeclared crate or module `std`
  --> src/....rs:9:17
   |
9  | #[derive(Debug, Error, PartialEq, Eq)]
   |                 ^^^^^
   |                 |
   |                 use of undeclared crate or module `std`
   |                 in this derive macro expansion
   |
  ::: ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thiserror-impl-1.0.63/src/lib.rs:33:1
   |
33 | pub fn derive_error(input: TokenStream) -> TokenStream {
   | ------------------------------------------------------ in this expansion of `#[derive(Error)]`
   |
help: consider importing this module
   |
5  + use core::error;
   |

For more information about this error, try `rustc --explain E0433`.
error: could not compile `...` (lib) due to 3 previous errors

while tests without default features (std disabled) compile and run successfully

[jordens]

You can't publish if you have git dependencies.

[jmwample]

It might be more palatable if this PR made no-std a feature such that enabling it bumps the MSRV to 1.81 instead of forcing an MSRV bump for the library. You could make no-std default for compilers 1.81+ and then an organic bump could be done when the library actually wants to drop support for older versions.

[kayabaNerve]

Features are intended to be additive. no-std disables some functionality so it isn't additive. std is additive, and when enabled, maintains the existing MSRV.

[jmwample]

I recognize that typically you want an additive std or alloc feature to enable broader functionality than the scope of the original package, but I feel like this is a special case because it is a widely used, existing crate. I would argue that (at least for now) no-std is additive in that it adds a new mode of usage, and does so without a breaking change for packages already using thiserror.

In my view this all depends on the type of release that this change goes out in. If it is a major or minor version bump then msrv 1.81 with backward support via feature is probably fine. If it is just a patch though, it should stay msrv 1.56 w/ a no-std feature.

[kayabaNerve]

Enabling a no-std feature would be a breaking change for some packages already using thiserror.

no-std disables some functionality

If this had a no-std feature, it'd be possible for one dependency to enable it in a way which irrecoverably breaks another dependency who relies on the std functionality. This cannot happen with the std feature present here.

Since this is a new feature, semver rules would mean this should be done with a minor version bump (satisfying your preferences) yet AFAIK, dtolnay does not follow semver for their crates (at least not all of them). I'd presume this to be released as 1.0.64 accordingly.