Diagnostic: extend from_env function

[belovdv]

Implements major part of #51.

This pr adds error type for from_env() and returns possibility to check if fds refer to pipe as optional feature.

[weihanglo]

This looks good to me in general. Let's see other's thought on the change :)

[belovdv]

Thanks for review, I'll wait other's comments.

[NobodyXu]

This is also not a good idea since features should be additive.

With this do_not_check_pipe feature,if one of the crate enables this, then every other crate is opt out of checking.

[belovdv]

Otherwise if one enables check then one uses smth different from pipe will fail. I'm not sure should be this option or not and, if should, how should it behave, imho it should be decided by maintainer

[petrochenkov]

If checking or not checking the pipe-ness should be configurable, then it should probably be a runtime option passed to from_env.

Not checking is the GNU Make behavior, checking catches errors in practice.

[belovdv]

Thanks for review. Hopefully, I managed to implement most requests and suggestions.

As for choice between checking pipe and checking only fd, I'd rather wait for alexcrichton decision.

[alexcrichton]

Given how low-level this crate is I don't think that the Cargo feature added here will be all that useful since if it's in use it's buried so deep and will be difficult to configure.

Can you explain a bit more what the error handling around pipe detection is doing? Why is fcntl not sufficient and what is fstat catching otherwise? Is that catching real issues happening in the wild and allowing callers to recover?

[petrochenkov]

I don't think that the Cargo feature added here will be all that useful

+1

Can you explain a bit more what the error handling around pipe detection is doing? Why is fcntl not sufficient and what is fstat catching otherwise?

The pipe check is the same thing that jobserver-rs did before #6.

Is that catching real issues happening in the wild and allowing callers to recover?

It catches a real issue that happens in the wild.
The caller won't be able to recover, but it will be able to report a useful error that will allow the "second order caller" (build engineer) to fix the build environment.

[alexcrichton]

If this is reverting back, is the use case in #6 no longer valid?

For "catching things in the wild" I meant moreso the new logic to detect a valid file descriptor, less so "should this return errors at all" because that's naturally a "sure this should happen when the effort is put in".

[petrochenkov]

I meant moreso the new logic to detect a valid file descriptor

Yes, I meant the corrupted non-pipe descriptors appear in the wild.

If this is reverting back, is the use case in #6 no longer valid?

The PR author says that the use case is no longer relevant in #27 (comment).
Also, descriptor being a pipe seems to be a POSIX requirement - #52 (comment).

[petrochenkov]

@weihanglo
Could you try this interface in cargo before it's in a "stable" release of jobserver-rs?

It's possible that in practice we'll need to discern between different kinds of erros (e.g. "descriptors are closed" and everything else) to avoid bothering users with warnings too often.

This PR, however, merges all the errors into a single io::Error with multiple vague ErrorKinds.
I'm not sure users will be able to use it reliably without relying on "string typing" (inspecting string descriptions returned by errors) or implementation details ("we know that closed descriptors are ErrorKind::InvalidData by reading source code of jobserver-rs").
(I don't like this part and I wish I read this PR in detail before its merge.)

[weihanglo]

Sure. I'll try taking a look this week.

[NobodyXu]

implementation details ("we know that closed descriptors are ErrorKind::InvalidData by reading source code of jobserver-rs").

Maybe jobserver can have the error kind documented on docs.rs?

[weihanglo]

Sorry for the late response. I think the change works fine with Cargo. Cargo can just ignore the jobserver if there are bad pipes. No harm to get this patch released on Cargo side I believe :)

[ASISBusiness]

RQ