Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add no_std support #244

Closed
wants to merge 3 commits into from
Closed

Add no_std support #244

wants to merge 3 commits into from

Commits on Aug 7, 2023

  1. Replace DisplayAsDisplay and PathAsDisplay with AsDisplay trait 

    Rather than having separate traits implementing as_display method,
replace DisplayAsDisplay and PathAsDisplay traits with a AsDisplay
trait.  The difference between those two traits is in the result
returned by the as_display method.  With AsDisplay trait this is
captured by an associated type.

The main motivation for the change is making it simpler to support
no_std builds in the future.  Previously, PathAsDisplay would have to
be handled specially in such builds on the side of macro expansion.
Now, thiserror-impl doesn’t need to be aware of any complications
around AsDisplay since they are all contained in thiserror crate.
    @mina86
    mina86 committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    c67aeda View commit details
    Browse the repository at this point in the history

  2. Prefer core crate in macro expansions 

    Prefer core crate to std crate when expanding macros.  Like before,
the main motivation is easier support of no_std.

Two symbols needed to be handled specially.  Firstly, re-export
std::error::Error from thiserror::__private so that macro expansion
can use it without having to refer to std crate.  The idea here is
that in future commits, based on selected features, either std::error
or core::error will be used.

Secondly, leave std::backtrace::Backtrace as is since it doesn’t have
no_std equivalent.  Thankfully, the type is only used when user type
refers to it so it should not be a hindrance for no_std support.

While at it, use leading :: for core and std paths so they don’t
conflict with modules of the same name.
    @mina86
    mina86 committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    5fc62e0 View commit details
    Browse the repository at this point in the history

  3. Add no_std support 

    Introduce no_std feature which, when enabled, uses core::error::Error
trait rather than std::error::Error and thus makes it possible to use
the crate in no_std builds.

Importantly though, using core::error module requires a unstable
error_in_core feature thus enabling no_std requires building with
nightly compiler.

Furthermore, enabling `no_std` disables handling of Backtrace fields
and support for displaying paths.  Since those types aren’t available
in no_std environments this shouldn’t be an issue.
    @mina86
    mina86 committed Aug 7, 2023
    Configuration menu
    Copy the full SHA
    c7cf563 View commit details
    Browse the repository at this point in the history