GHC 8.4 syntax error (on Windows specifically; Linux and OS X are fine)

[chrisdone]

The following syntax error happens when compiling network-2.6.3.4 on Windows https://ci.appveyor.com/project/chrisdone/intero/build/1.0.260#L34319

34318    Preprocessing library for network-2.6.3.4..
34319    Building library for network-2.6.3.4..
34320    [1 of 9] Compiling Network.Socket.ByteString.Internal ( Network\Socket\ByteString\Internal.hs, .stack-work\dist\893fbf7f\build\Network\Socket\ByteString\Internal.o )
34321    [2 of 9] Compiling Network.Socket.Types ( .stack-work\dist\893fbf7f\build\Network\Socket\Types.hs, .stack-work\dist\893fbf7f\build\Network\Socket\Types.o )
34322    
34323    C:\Users\appveyor\AppData\Local\Temp\1\stack2232\network-2.6.3.4\Network\Socket\Types.hsc:764:16: error:
34324        parse error on input `CALLCONV'
34325        |
34326    764 | foreign import CALLCONV unsafe "ntohs" ntohs :: Word16 -> Word16
34327        |                ^^^^^^^^
34328
34329
34330--  While building custom Setup.hs for package hspec-discover-2.4.8 using:
34331      C:\sr\setup-exe-cache\i386-windows\Cabal-simple_Z6RU0evB_2.2.0.0_ghc-8.4.1.exe --builddir=.stack-work\dist\893fbf7f build --ghc-options " -ddump-hi -ddump-to-file"
34332    Process exited with code: ExitFailure (-1073741819)
34333    Logs have been written to: C:\stack\.stack-work\logs\hspec-discover-2.4.8.log
34334
34335

I suppose that calling convention syntax isn't allowed on Windows?

[kazu-yamamoto]

Strange. AppVeyor works well for the 2.6 branch.

@Mistuke Do you have any ideas?

[Mistuke]

The module is deferring #include <HsNetDef.h> (note the two #), so hsc2hs won't process the preprocessor macro.

Since it's been deferred you need to enable CPP to have GHC preprocess the hs file.
So add {-# LANGUAGE CPP #-} at the top and that should fix it.

[kazu-yamamoto]

@chrisdone Could you modify files according to @Mistuke's suggestion, confirm and send a PR?

[DanBurton]

I am not able to reproduce this error on my windows machine.

stack unpack network-2.6.3.4
cd network-2.6.3.4
notepad.exe stack.yaml # resolver: nightly-2018-03-16
stack build

Instead I merely get warnings that say:

* the 'stdcall' calling convention is unsupported on this platform
  treating as ccall

stack-1.6.5 (windows 64 bit version)
Windows 10 Home edition (64 bit)

[ndmitchell]

I am using 32bit GHC, which might be the difference

[Mistuke]

That's a different issue, that issue is that the definition of CALLCONV is wrong, it checks for _WIN32 which is also defined when the target is a 64 bit target https://msdn.microsoft.com/en-us/library/b0084kay.aspx

It should instead check for the GHC Macros we put out for this stuff like Win32 does or check _WIN64 first.

[RyanGlScott]

In that case, I'm extremely confused as to what is causing the original issue since, if I'm reading that correctly, CALLCONV should always be defined to something?

(I am also unable to reproduce the issue with 32-bit GHC 8.4.1.)

[Mistuke]

CALLCONV is never included correctly. I'm more confused by why it has been working thus far. The only time a preprocessor runs over this file is when it's told to skip processing of the include. So this shouldn't have ever worked. Unless hsc2hs had a bug or unexpected behavior

…

On Sat, Mar 17, 2018, 00:13 Ryan Scott ***@***.***> wrote: In that case, I'm extremely confused as to what is causing the original issue since, if I'm reading that correctly, CALLCONV should always be defined to *something*? (I am also unable to reproduce the issue with 32-bit GHC 8.4.1.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#313 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABH3KeWQ2xTpdQoe_EzIOzsAcA4PQA5cks5tfFU2gaJpZM4SoYfD> .

[RyanGlScott]

@Mistuke, CPP is set, in network.cabal:

network/network.cabal

Lines 82 to 83 in b548b0c

	extensions:
	CPP, DeriveDataTypeable, ForeignFunctionInterface, TypeSynonymInstances

[Mistuke]

Yes but whatever is processing the cabal file is not passing it along to the compiler as the preprocessor is not running. so my suggestion would still work.

I can't reproduce this issue with cabal-install nor with ghc 8.4. So it's not a network problem or a problem with the ghc HQ produced bindists.

the warning @ndmitchell is seeing I'll fix.