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
//! Minimal file-handle abstraction shared between `lua-vm` (hook type) and
//! `lua-stdlib` (io library).
//!
//! `std::fs` and `std::io` are banned in `lua-stdlib` by PORTING.md §1. The
//! concrete implementation (backed by `std::fs::File`) lives in `lua-cli` and
//! is installed via [`crate::error::LuaError`]-returning function pointers on
//! [`lua_vm::state::GlobalState`]. This trait is the shared seam that allows
//! `lua-stdlib` to program against file handles without importing `std::fs`.
//!
//! ## Trait design
//! The trait mirrors the subset of `LuaFileOps` (defined in `lua-stdlib`) that
//! is required to run the built-in io library at the level needed for
//! `attrib.lua`-class tests: sequential write, byte-by-byte read, flush, and
//! seek. `LuaFileOps` in `lua-stdlib` extends this trait so that a single
//! concrete type (the `FsFile` in `lua-cli`) satisfies both.
use ;
/// Capabilities required by the io library from an OS file handle.
///
/// Designed to be object-safe (`Box<dyn LuaFileHandle>`). Implementations
/// backed by `std::fs::File` live in `lua-cli`; implementations for the
/// standard streams live in `lua-stdlib/src/io_lib.rs`.
// ──────────────────────────────────────────────────────────────────────────
// PORT STATUS
// source: (new abstraction — not a direct port of a C file)
// target_crate: lua-types
// confidence: high
// todos: 0
// port_notes: 0
// unsafe_blocks: 0
// notes: Introduced in Phase B to break the dependency cycle that
// would arise if `lua-vm` tried to use `LuaFileOps` from
// `lua-stdlib`. The concrete `FsFile` implementation in
// `lua-cli` implements this trait; `LuaFileOps` in
// `lua-stdlib` is a type alias for this same trait.
// ──────────────────────────────────────────────────────────────────────────