Gate UnixStream behind #[cfg(unix)] for Windows compatibility#742
Open
klod-exe wants to merge 1 commit into
Open
Gate UnixStream behind #[cfg(unix)] for Windows compatibility#742klod-exe wants to merge 1 commit into
klod-exe wants to merge 1 commit into
Conversation
tokio::net::UnixStream does not exist on cfg(windows), causing yellowstone-grpc-client to fail to compile on Windows targets. This commit gates the UnixStream import (and the std::path::PathBuf import used only by connect_uds) plus the connect_uds method itself behind #[cfg(unix)], leaving Linux/macOS unchanged. Verified: cargo check -p yellowstone-grpc-client succeeds on Linux.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
yellowstone-grpc-clientfails to compile on Windows targets becausetokio::net::UnixStreamis not available oncfg(windows)— the typelives at
tokio::net::windows::named_pipe::*on Windows. The currentunconditional import in
yellowstone-grpc-client/src/lib.rs:…blows up with
unresolved importwhen building any downstream cratethat targets
x86_64-pc-windows-msvc/gnu.Fix
Gate the platform-specific bits behind
#[cfg(unix)]:tokio::net::UnixStreamimport.std::path::PathBufimport (only used byconnect_uds).connect_uds(...)method on the builder.This leaves the TCP/TLS connect paths (
.connect(),.connect_lazy(),etc.) untouched on every target, and
connect_uds()continues to workon Linux/macOS as before. The change is purely additive gating — no
behavior change on
cfg(unix).Verification
cargo check -p yellowstone-grpc-clientpasses on Linux (Rust1.93.1, tonic 0.14.3) against this branch.
UnixStreamis the onlynon-portable item touched, gating it behind
#[cfg(unix)]is sound.The PR author does not have a Windows host to run
cargo check --target x86_64-pc-windows-msvcend-to-end against this fork.Motivation
I'm building a cross-platform crate that subscribes to a Yellowstone
gRPC endpoint from both a Linux producer and a Windows consumer. The
consumer only ever uses TCP+TLS, never UDS — but it can't depend on
yellowstone-grpc-clientat all today because of the unconditionalUnixStreamimport. This PR is the minimal change that unblocksWindows consumers without changing any Linux behavior.