12 lines
3.5 KiB
Markdown
12 lines
3.5 KiB
Markdown
FAIL
|
|
|
|
Ran: `cargo test -p ely-platform` (all pass, including `tests/startup.rs`), `cargo clippy -p ely-platform -p ely-ui --all-targets` (clean), `ELY_NO_DIALOG=1 tests/scripts/apps-start.sh` (8 of 8). Also built a scratch probe against the pinned gpui 1a28cff with `runtime_shaders`, the same features the apps use: `catch_unwind(|| gpui_platform::application().run(|_| panic!(..)))`.
|
|
|
|
1. crates/ely-ui/src/run.rs:22-35 — on macOS the `catch_unwind` never catches a startup panic. gpui runs the `run` callback from `did_finish_launching`, an `extern "C" fn` (gpui_macos/src/platform.rs:1317). A panic there cannot unwind, so the process aborts. Scenario: the probe printed `panic in a function that cannot unwind … thread caused non-unwinding panic. aborting.` and exited 134, without printing `caught`. So `open`, `ely_gpui_component::init`, `Theme::set_mode_now`, `Shell::new` and Metal renderer creation (`expect("error building metal library")`, gpui_apple/src/metal_renderer.rs:219-224) all end in an abort with no dialog and no "could not start" text. Windows behaves the same way inside `extern "system" window_procedure`. Fix direction: install the failure path in a panic hook (`logging::init_in` already sets one) so it runs before the abort, or have it call `startup::fail` from the hook during startup. Do not rely on unwinding out of `run`.
|
|
|
|
2. crates/ely-ui/src/run.rs:57-68 — the "window did not open" branch cannot catch the case §4.1 is about on macOS. `MacPlatform::open_window` returns `Err` only for `AnchoredPopup` (gpui_macos/src/platform.rs:693). The renderer is built without returning a `Result` (gpui_macos/src/window.rs:1101). When no Metal device is found, gpui logs and calls `std::process::exit(1)` (gpui_apple/src/metal_renderer.rs:205-208). Scenario: on a Mac or VM without a usable Metal device, ElyDoc exits 1 with only gpui's log line. No dialog appears and `startup::fail` never runs, which breaks "无法初始化图形后端时显示原因". Fix direction: check for a Metal device yourself before `run` (macOS), or do the equivalent wgpu adapter probe (Linux/Windows), and call `startup::fail` with the reason. Alternatively, patch gpui so renderer creation returns `Err` through `open_window`, and record it in `patches/`.
|
|
|
|
3. crates/ely-ui/src/run.rs:22-35 — on Linux, where the event loop is Rust and panics do unwind, `catch_unwind` covers the app's whole lifetime, not just startup. Scenario: a panic an hour into editing unwinds out of `run`, and the user sees "ElyDoc could not start … the graphics backend did not start: <panic>". That is a false reason in the log and the dialog (rule 2: no masking or mislabeling). Fix direction: limit this path to startup. For example, set a "started" flag after the first window opens and stop treating later panics as startup failures. The real panic text should go through the normal panic path.
|
|
|
|
4. tasks/TASKS.md:21 — "本机验证：…窗口打不开与启动期 panic 都走这条路" has no evidence. No test or script makes a window fail or makes a startup panic go through `run`. `tests/startup.rs` calls `startup::fail` directly, and `apps-start.sh` covers only the success path. Findings 1 and 2 show the claim is false on macOS, the only machine it was "verified" on. Fix direction: add a test or smoke hook that triggers a startup panic and a window-open failure through `ely_ui::run` (for example an env-gated fault in a test binary) and asserts exit 1, the stderr text and the log line. Until that passes, move these two paths under 未验证.
|