Represent nodes with Node_ instead of Option<Node_>
Summary:
Representing error-nodes with None was a helpful intermediate step away from Result, but the `None` value is a bit redundant. We already have a representation for an empty node--`Node_::Ignored`.
This diff removes the distinction between `None` (which means some unspecified error occurred when computing that node) and `Some(Node_::Ignored)` (which means the node is one the direct decl parser does not care about). The direct decl parser does not care about errors, so it seems reasonable to coalesce the former category into the latter.
Because it is no longer possible to use the `?` operator (it can be used only with `Option` and `Result` for the time being), this diff introduces an `unwrap_or_return!` macro, which returns `Node_::Ignored` if the argument is `None`. This looks a little ugly, but I think it might be a small improvement in one way--returning Ignored just because a helper like node_to_ty returned None/Err is a pretty coarse strategy for error-recovery.
For instance, if we have a class which implements some interface, but `node_to_ty` returns None for the interface type due to some parse error in it, we should just omit that type from the class's implements list. But as implemented currently, we ignore the entire class. Maybe `ignore_none!` will call out these situations a little more clearly than `?` did.
Reviewed By: Wilfred
Differential Revision:
D21695605
fbshipit-source-id:
f4eac23bcc155aa23d3ceba05f7f4371b816b01b