fix(ext/node): node compatibility issue missing fd in createServer callback socket object

[muthu90tech]

This PR will address the node compatibility issue where, the callback socket object in net.createServer is missing a fd in socket._handle

Modified this PR to use internal symbol to expose fd instead of exposing it via lib.deno.d.ts
denoland/deno_core#1061

fixes: #27788

[bartlomieju]

@muthu90tech I merged your deno_core PR. It will be a few days before it gets released, so for now you can use Cargo patch functionality to point to a latest commit on main branch in deno_core instead of a fixed version.

[muthu90tech]

@muthu90tech I merged your deno_core PR. It will be a few days before it gets released, so for now you can use Cargo patch functionality to point to a latest commit on main branch in deno_core instead of a fixed version.

Thanks @bartlomieju , Once the deno_core version with the fix is released, should I update the current PR to point to the deno_core version with the fix, or will that be handled ? Thank you

[muthu90tech]

@muthu90tech I merged your deno_core PR. It will be a few days before it gets released, so for now you can use Cargo patch functionality to point to a latest commit on main branch in deno_core instead of a fixed version.

Thanks @bartlomieju , Once the deno_core version with the fix is released, should I update the current PR to point to the deno_core version with the fix, or will that be handled ? Thank you

@bartlomieju , I noticed main branch has deno_core 0.336.0, which has the new symbol, so I rebased. Thanks

[muthu90tech]

The api to get the fd in tokio library is not implemented on windows, I notice build issues around it. Is there a way to exclude implementation just for windows, like a MACRO ? thank you

[kt3k]

Is there a way to exclude implementation just for windows, like a MACRO ? thank you

You can use #[cfg(unix)], #[cfg(windows)], etc for writing OS specific code. ref

deno/ext/fs/std_fs.rs

Lines 643 to 646 in 17a51c4

	#[cfg(unix)]
	std::os::unix::fs::symlink(from, to)?;
	#[cfg(windows)]
	std::os::windows::fs::symlink_file(from, to)?;

[muthu90tech]

@kt3k , I addressed the lint issues, but when running the integration tests locally even without my changes I see 60 failures, I noticed the integration failed in CI too, are there flaky issues with test bed? Thank you

[muthu90tech]

@kt3k , I addressed the lint issues, but when running the integration tests locally even without my changes I see 60 failures, I noticed the integration failed in CI too, are there flaky issues with test bed? Thank you

Nvm, I think tests in CI are passing now.

[kt3k]

nit: probably this shouldn't be prefixed with _ as the value is used later.

[muthu90tech]

@kt3k , yes I initially had fd_raw, but the lint on linux complained about

error: value assigned to `fd_raw` is never read
   --> ext/net/ops.rs:185:11
    |
185 |   let mut fd_raw: Option<Fd> = None;
    |           ^^^^^^
    |
    = help: maybe it is overwritten before being read?
    = note: `-D unused-assignments` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(unused_assignments)]`

[kt3k]

Ok. Makes sense

[kt3k]

LGTM with nits

@bartlomieju Can you take another look?

[kt3k]

Thanks for your contribution!