stelae 0.5.0

A collection of tools in Rust and Python for preserving, authenticating, and accessing laws in perpetuity.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

//! # Stelae
//!
//! Stelae is a collection of tools in rust and python for preserving,
//! authenticating, and accessing laws in perpetuity.
//!
//! ## About the name
//!
//! Stelae, or large stone slabs, were used in some ancient cultures to
//! publish the law. The Code of Hammurabi, one of the earliest preserved
//! written laws, was published on a Stelae in ~1750 BCE and is still readable
//! nearly four millennia later.

// =========================================================================
//                  Canonical lints for whole crate
// =========================================================================
// Official docs:
//   https://doc.rust-lang.org/nightly/clippy/lints.html
// Useful app to lookup full details of individual lints:
//   https://rust-lang.github.io/rust-clippy/master/index.html
//
// We set base lints to give the fullest, most pedantic feedback possible.
// Though we prefer that they are just warnings during development so that build-denial
// is only enforced in CI.
//
#![warn(
    // `clippy::all` is already on by default. It implies the following:
    //   clippy::correctness code that is outright wrong or useless
    //   clippy::suspicious code that is most likely wrong or useless
    //   clippy::complexity code that does something simple but in a complex way
    //   clippy::perf code that can be written to run faster
    //   clippy::style code that should be written in a more idiomatic way
    clippy::all,

    // It's always good to write as much documentation as possible
    missing_docs,

    // > clippy::pedantic lints which are rather strict or might have false positives
    clippy::pedantic,

    // > new lints that are still under development"
    // (so "nursery" doesn't mean "Rust newbies")
    clippy::nursery,

    // > The clippy::cargo group gives you suggestions on how to improve your Cargo.toml file.
    // > This might be especially interesting if you want to publish your crate and are not sure
    // > if you have all useful information in your Cargo.toml.
    clippy::cargo
)]
// > The clippy::restriction group will restrict you in some way.
// > If you enable a restriction lint for your crate it is recommended to also fix code that
// > this lint triggers on. However, those lints are really strict by design and you might want
// > to #[allow] them in some special cases, with a comment justifying that.
#![allow(
    clippy::blanket_clippy_restriction_lints,
    reason = "See above explanation."
)]
#![warn(clippy::restriction)]
//
//
// =========================================================================
//   Individually blanket-allow single lints relevant to this whole crate
// =========================================================================
#![allow(clippy::implicit_return, reason = "This is idiomatic Rust")]
#![allow(
    clippy::multiple_crate_versions,
    reason = "Multiple deps are currently pinning `hermit-abi` — December 2022"
)]
#![allow(
    clippy::std_instead_of_alloc,
    reason = "We're not interested in becoming no-std compatible"
)]
#![allow(
    clippy::std_instead_of_core,
    reason = "Import items from std instead of core"
)]
#![allow(
    clippy::mod_module_files,
    reason = "TODO: But I think the mod.rs is more conventional — @tombh"
)]
#![allow(
    clippy::missing_inline_in_public_items,
    reason = "
    Although performance is of course important for this application, it is not currently
    such that it would benefit from explicit inline suggestions. Besides, not specifying
    `#[inline]` doesn't mean that a function won't be inlined. And if performance does start
    to become a problem, there are other avenues to explore before deciding on which functions
    would benefit from explicit inlining
"
)]
#![allow(
    clippy::exhaustive_structs,
    reason = "I think marking `#[non_exhaustive]` is more for structs/enums that are imported into other crates"
)]
#![allow(
    clippy::exhaustive_enums,
    reason = "I think marking `#[non_exhaustive]` is more for structs/enums that are imported into other crates"
)]
#![allow(
    clippy::question_mark_used,
    reason = "We rely on propagating errors with question mark extensively"
)]
#![allow(
    clippy::semicolon_outside_block,
    reason = "Opt in to have semicolon in the outside block across codebase"
)]
#![allow(
    clippy::single_call_fn,
    reason = "We tend to break up long functions into smaller ones, so this lint is not useful"
)]
#![allow(
    clippy::arithmetic_side_effects,
    reason = "Our arithmetic is very simple for now, so no side effects are expected at the time of writing this"
)]
#![allow(
    clippy::unimplemented,
    reason = "We'll allow unimplemented! in code, but disallow todo!"
)]
#![allow(
    clippy::renamed_function_params,
    reason = "
    Sometimes collides with `min_ident_chars`, in cases where trait params consist of a single char.
    So we disallow single chars, and allow renamed_function_params.
"
)]

pub mod db;
pub mod history;
pub mod server;
pub mod stelae;
pub mod utils;