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
//! Test-only helpers for mutating process environment variables.
//!
//! **Crate-wide, deliberately.** `std::env::set_var` is `unsafe` because
//! it races any concurrent `env::var` in the same process — and cargo runs
//! every test in a binary on parallel threads. A per-module lock is
//! therefore not enough: `config::config` mutates `XDG_CONFIG_HOME` while
//! `cli::doctor` reads it, and `terminal::capabilities` mutates
//! `TERM_PROGRAM` while `cli::doctor` reads that too. One lock shared by
//! the whole crate is what actually excludes them.
//!
//! Two rules for any test that touches the environment:
//!
//! 1. Take [`env_lock`] first, and hold it for the whole test.
//! 2. Mutate only through [`EnvGuard`], so the variable is restored even
//! if an assertion panics — a leaked `XDG_CONFIG_HOME` pointing at a
//! deleted `tempdir` fails every later config test for no reason.
//!
//! A test that only *reads* the environment must also take the lock; it
//! is the read side of the same race.
//!
//! The same lock also serialises [`config::persistence::SuppressGuard`],
//! which flips a process-global `AtomicBool` rather than an environment
//! variable — and the read side of *that* race is easy to miss, because
//! such a test touches no environment variable of its own. Any test
//! that observes `config_reads_allowed` / `config_writes_allowed` — which
//! means any test calling `list_export_stylesheets`, `list_theme_names`,
//! `read_theme_named`, or `Config::save` — must take the lock too, or it
//! reads the gate while a suppressing test on another thread holds it
//! closed and sees an empty list it can't explain.
//!
//! [`config::persistence::SuppressGuard`]: crate::config::persistence::SuppressGuard
use env;
use ;
/// Serialises every environment-touching test in the crate.
///
/// Poisoning is ignored: [`EnvGuard`]'s `Drop` has already restored the
/// variable by the time a panicking test releases the lock, so there is
/// no corrupt state for the next holder to inherit.
/// Sets (or clears) one environment variable and restores its previous
/// value on drop. Create it only while holding [`env_lock`].
/// The crate-wide env lock plus suppressed config reads and writes, as
/// one guard.
///
/// A test that drives a code path calling [`Config::save`] must hold
/// this. Nothing in the test environment redirects
/// `~/.config/edamame` by default, so an unguarded `save()` rewrites the
/// *developer's own* config — and a value asserted in a test is exactly
/// the kind of value that does damage there (an update-check test
/// recording a `v999.0.0` tag suppresses the real update notice
/// forever). Suppressing the gate is preferable to pointing
/// `XDG_CONFIG_HOME` at a tempdir: the write is what the test wants
/// gone, not merely relocated, and `Config::save` already returns
/// `Ok(())` under it, so no assertion has to know.
///
/// Reads are suppressed alongside writes because the gate is one flag —
/// see [`crate::config::persistence`]. A test that needs a real write
/// (`save_writes_nothing_while_config_writes_are_suppressed`) takes
/// [`env_lock`] and an [`EnvGuard`] on `XDG_CONFIG_HOME` instead.
/// Take [`ConfigIsolation`] for the rest of the current scope. Hold it
/// for the whole test body, and take it only once — it is a mutex.