fix: pass error when failed to parse toml

[gaojunran]

fixes #337 (reply in thread).

[greptile-apps]

Greptile Summary

This PR fixes a silent-failure bug in all_merged_from: when a pitchfork.toml could not be parsed, the error was only printed to stderr and processing continued. The fix returns the error (wrapped with the file path) so callers abort with a clear message. The doc comment is also corrected to reflect the new hard-fail contract, and the test that relied on the old soft-fail behavior is removed.

Confidence Score: 5/5

Safe to merge — the change is minimal, correct, and the doc comment is already updated.

Only P2 findings (missing test for the new hard-fail path); no logic or security issues introduced.

tests/test_e2e_namespace.rs — no test verifies the new hard-fail behavior introduced by the fix.

Important Files Changed

Filename	Overview
src/pitchfork_toml.rs	Error branch in all_merged_from changed from eprintln! (soft-fail/continue) to return Err(e.wrap_err(...)) (hard-fail/propagate); doc comment updated to match.
tests/test_e2e_namespace.rs	Two tests removed: one correctly retired (it asserted the now-removed soft-fail behavior), one (test_local_namespace_override_mismatch_reports_error) removed without a clear replacement; no new test covers the hard-fail path.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[all_merged_from] --> B[list_paths_from]
    B --> C{for each path}
    C --> D[Self::read]
    D --> E{Result?}
    E -- Ok --> F[namespace collision check]
    F --> G[pt.merge]
    G --> C
    E -- "Err (old)" --> H["eprintln! — continue loop"]
    H --> C
    E -- "Err (new)" --> I["return Err(e.wrap_err(...))"]
    I --> J[Caller receives error]

Loading

_{Reviews (3): Last reviewed commit: "fix: pass error when failed to parse tom..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request modifies the error handling in src/pitchfork_toml.rs to propagate errors encountered during file reading instead of just printing them. A review comment correctly identifies that the current implementation will fail to compile because wrap_err is being called on the error object itself rather than a Result type. The feedback also suggests using wrap_err_with for better performance and notes that the function's documentation needs to be updated to reflect the new error-returning behavior.