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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
//! Error type returned from the library's top-level entry points.
//!
//! Prior to this module, every entry point returned `Option<…>` and
//! collapsed parse failure, empty input, non-UTF-8 paths, and
//! disabled-language builds into a single `None`. [`MetricsError`]
//! distinguishes those cases so library consumers can react
//! appropriately (e.g. log the parse failure but skip a non-UTF-8
//! path).
//!
//! New variants may be added in future minor versions, so consumers
//! must include a `_` arm when matching exhaustively — this is enforced
//! by the [`#[non_exhaustive]`][non_exhaustive] attribute on the enum.
//!
//! [non_exhaustive]: https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute
use crateLANG;
/// Error returned by the library's metric-computation entry points.
///
/// # Stability
///
/// The variant set is additive: new variants may be introduced in
/// minor versions, so the enum is marked `#[non_exhaustive]`. Existing
/// variants will not be removed without a major version bump. The
/// [`std::error::Error`] and [`std::fmt::Display`] impls are part of
/// the stable surface; the exact wording of the `Display` output is
/// not.
///
/// # Examples
///
/// Most variants are reserved for features that have not yet landed
/// (see each variant's documentation for the issue tracking it). The
/// exception is [`MetricsError::LanguageDisabled`], which is
/// produced by every dispatch entry point when the caller selects a
/// [`LANG`] whose per-language Cargo feature is not enabled in the
/// current build (see #252). The example exercises the happy path
/// and demonstrates the exhaustive-with-`_` match shape that callers
/// should adopt to stay forward-compatible with future variants.
///
/// ```
/// use big_code_analysis::{analyze, MetricsError, MetricsOptions, Source, LANG};
///
/// let source = Source::new(LANG::Cpp, b"int a = 42;");
/// let result = analyze(source, MetricsOptions::default());
///
/// // Today this call succeeds; the match below documents the shape
/// // callers must adopt so adding a future variant is non-breaking.
/// assert!(result.is_ok());
///
/// match result {
/// Ok(_space) => {}
/// Err(MetricsError::EmptyRoot) => {
/// // Reserved: walker produced no top-level FuncSpace.
/// }
/// Err(MetricsError::ParseHasErrors) => {
/// // Reserved: future strict-parsing toggle on `MetricsOptions`.
/// }
/// Err(MetricsError::LanguageDisabled(_lang)) => {
/// // The `LANG` variant the caller asked for has no grammar
/// // crate compiled in for this build (per-language feature
/// // disabled — see the `[features]` table in Cargo.toml).
/// }
/// Err(MetricsError::NonUtf8Path) => {
/// // Reserved: strict-identifier mode (see issue #254).
/// }
/// // `MetricsError` is `#[non_exhaustive]`; new variants may be added.
/// Err(_) => {}
/// }
/// ```