There several different probing schemes in different places, so the best way to figure this out would be to look at every specific case. For Cargo.tomls, we are calling an external process (cargo metadata
), we do not read them ourselves.
More generally, rust-analyzer happens to be a long-lived process, so point-in-time APIs are not suitable. Sadly, to get a watching API with guarantees you need something like watchman.
In most of those cases it would make sense to at least log the error so the user is aware of it. You can't do that if you don't have the error.
I do think that selectively propagating error or continuing based on the ErrorKind would create more problems. I agree that logging errors is a good idea. But that is true of all fs
errors, so it probably makes sense to create an application specific app::fs
module which just wraps the whole of std::fs
with logging? We should do this for rust-analyzers main code (we already effectively have such wrapper for internal build system) ... This reasoning about app-specific wrappers around fs
make me even more sympathetic towards @sunfishcode 's proposal to deprecate IOing Path methods.
Here too - does something else in the application open the path?
Again, this needs looking into every specific example. One that I remember is that we by default skip slow tests. However, we run them on CI, and we also have a dedicated test, which runs only on CI, which verifies that slow tests were not skipped. It works by checking if a special cookie file, created by slow tests, .exists()
. Error message is irrelevant in this case.