Skip to content
This repository has been archived by the owner on Aug 16, 2021. It is now read-only.

WIP: Make tests and examples compile with Rust 1.10 #104

Conversation

joshtriplett
Copy link
Contributor

This still fails to work with 1.10 due to
rust-lang/rust#22250 . Because of that issue,
an invocation of #[derive(Debug)] inside a macro doesn't take cfg(...)
attributes into account, and fails to compile due to referencing enum
variants that don't exist. Posted for reference only.

error_chain uses attributes on statements, stablized in Rust 1.13.
Factor them out of functions in the non-backtrace codepath, making it
possible to build a crate that uses error_chain with Rust 1.10.

The backtrace feature still requires Rust 1.13 for attributes on
statements, due to the impl_extract_backtrace macro, which needs to emit
a function with one block for each linked error type, some of which may
have attributes on them.  And any code using compile-time conditionals
in attributes on variants within an error_chain! invocation (which
includes many of the tests and examples) will produce an error due to
rust-lang/rust#22250 (fixed in Rust 1.11).
But a crate using error_chain with default-features = false and avoiding
such compile-time conditionals will now compile.
let state = error_chain::State {
next_error: None,
};
println!(" State.next_error: {}", size_of_val(&state.next_error));
}
size_of_state();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you change the code to use State::default()? That way, only the second println would be compiled conditionally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. But this isn't intended to merge, anyway, since it doesn't work completely. #103 works, this just archives the attempt to make tests and examples work.

@@ -262,6 +262,8 @@ fn links() {
Test(test::Error, test::ErrorKind);
}
}

{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documented in the commit message: this works around a Rust 1.10 bug (fixed in 1.11 via rust-lang/rust#34436 ), which causes Rust to think that an item-generating macro invoked at the end of a function can only generate expressions instead (and then producing piles of errors when the macro attempts to generate items instead of expressions).


error_chain! {
foreign_links {
Fmt(fmt::Error);
Var(env::VarError);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documented in the commit message: in Rust 1.10, fmt::Error doesn't impl Error.

@Yamakaky
Copy link
Contributor

Sorry, I only checked the diff ^^

- Avoid using attributes on statements; use them on items instead.

- Change a test to use std::env::VarError instead of std::fmt::Error,
  because the latter didn't impl Error until Rust 1.11.

- Add an empty block after invocations of `error_chain!` inside
  functions, to work around rust-lang/rust#34436
  (fixed in Rust 1.11).

- Replace a single instance of `?` with `try!`.

This still fails to work with 1.10 due to
rust-lang/rust#22250 .  Because of that issue,
an invocation of `#[derive(Debug)]` inside a macro doesn't take cfg(...)
attributes into account, and fails to compile due to referencing enum
variants that don't exist.  Posted for reference only.
@Yamakaky
Copy link
Contributor

So, do you want to also merge this PR?

@joshtriplett
Copy link
Contributor Author

No, it doesn't seem worthwhile if it only partially works (and if Travis can't test it to make sure it keeps working). Someone who wants to try to make this work can use this PR as a starting point, but for now, closing and leaving for reference.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants