Use Base.o_* instead of raw {#const O_*}
#339
Conversation
|
Set to draft while https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13856 is in progress |
`stage1` cross compilers could use different values instead of system-defined. GHC JS Backend change these constants to be compatible with Node.js environment.
|
It became actual after https://gitlab.haskell.org/ghc/ghc/-/issues/25190 Which were raised after These changes are for restoring consistency across cross compile targets with packages which have custom |
| -- them overridden. | ||
| -- For example GHC JS Backend provides its own constants | ||
| -- which should be used at the target of cross compilation | ||
| -- into Node.JS environment. |
There was a problem hiding this comment.
Could you reference a GHC source file which contain overriding logic for JS backend? It would help future readers.
There was a problem hiding this comment.
Yes, we have a test which can be referenced for such overridings:
grep -rn testsuite -e 'o_CREAT'
testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs:13590: o_CREAT :: GHC.Internal.Foreign.C.Types.CInt
testsuite/tests/interface-stability/base-exports.stdout:10544: o_CREAT :: GHC.Internal.Foreign.C.Types.CInt
testsuite/tests/interface-stability/base-exports.stdout-mingw32:10812: o_CREAT :: GHC.Internal.Foreign.C.Types.CInt
testsuite/tests/interface-stability/base-exports.stdout-ws-32:10544: o_CREAT :: GHC.Internal.Foreign.C.Types.CInt
So, files testsuite/tests/interface-stability/base-exports.stdout* can be useful to determine which targets have foreigns (exports? 🤔 ).
There was a problem hiding this comment.
Actual overrides are collected at ./libraries/ghc-internal/src/GHC/Internal/System/Posix/Internals.hs. For example o_CREAT:
JS Backend
foreign import javascript unsafe "(() => { return h$base_o_creat; })" o_CREAT :: CInt
Other
foreign import ccall unsafe "HsBase.h __hscore_o_creat" o_CREAT :: CInt
There was a problem hiding this comment.
Probably need create a [Note] there at sources?
| fdOption2Int AppendOnWrite = (#const O_APPEND) | ||
| fdOption2Int NonBlockingRead = (#const O_NONBLOCK) | ||
| fdOption2Int AppendOnWrite = (Base.o_APPEND) | ||
| fdOption2Int NonBlockingRead = (Base.o_NONBLOCK) | ||
| fdOption2Int SynchronousWrites = (#const O_SYNC) |
There was a problem hiding this comment.
Is there a reason for the inconsistency, beyond GHC exporting incomplete set? Could you please raise an issue on GHC side to provide a complete set in future? (We can leave unix source code inconsistent for the time being, but I'd like this to be rectified in future)
There was a problem hiding this comment.
I'm fine with accepting a tactical fix, but it raises questions about viability of hsc2hs for cross-compilation. What's the plan? CC @bgamari @mpickering
@bgamari sent a response here. If I understand it correctly, tactical fix is OK but for further changes we need to do something with |
I did obvious fixes for the CI, but need some clues about |
|
NetBSD and OpenBSD are constantly broken. I don't mind if we ignore them. |
|
I have no rights to merge, so, I am needed to wait. |
stage1cross compilers can use different values instead of system-defined. GHC JS Backend overrides these constants to be compatible with Node.js environment.Details of investigation.
Interface stability tests have the following overridden constants:
Blocks: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13856