1 unstable release

0.1.0 Jan 15, 2019

#5 in #lark

Download history 55/week @ 2024-03-24 92/week @ 2024-03-31 29/week @ 2024-04-07 34/week @ 2024-04-14 39/week @ 2024-04-21 28/week @ 2024-04-28 40/week @ 2024-05-05 41/week @ 2024-05-12 31/week @ 2024-05-19 36/week @ 2024-05-26 26/week @ 2024-06-02 19/week @ 2024-06-09 36/week @ 2024-06-16 32/week @ 2024-06-23 8/week @ 2024-06-30 17/week @ 2024-07-07

94 downloads per month
Used in 13 crates (10 directly)

Custom license

52KB
1.5K SLoC

Representation of an error in the Lark compiler.

For more information, see the main readme and internals doc.


lib.rs:

Types for tracking errors through queries.

Here is how it works:

  • Queries that can themselves report errors return WithError<T>; the errors contained in that value were discovered during executing that query.
  • If another query uses the result of a query that returns WithError, it can just use into_value to ignore the errors -- WithError always includes some form of sentinel value that you can use (i.e., you can just ignore the errors and try to get on with life).
  • In the worst case, one can you Result<T, ErrorReported> and have Err(ErrorReported) act as a sentintel value for "failed to produce a value because of some error". This is not preferred because now downstream queries have to care whether you propagated an error or not, but sometimes it's the best/easiest thing to do.
    • To help with this, the or_sentinel! query acts as a kind of ? operator for bridging a Result<T, ErrorReported> into a U where U has a proper sentinel -- if the result is Err(ErrorReported), it creates the error-sentinel for U and returns it.
    • This relies on the ErrorSentinel trait, which defines the error-sentinel for a given type.

This scheme is not the most ergonomic and I would like to change it, but it will do for now. -nikomatsakis

Dependencies

~6–15MB
~211K SLoC