.prof file is not created when running 'stack exec' with +RTS -p flag on Windows.

[ahgibbons]

When building a program with the --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts" flags, a .prof file is not produced when using stack exec with the +RTS -p flag. This problems occurs on Windows 10 with stack version 1.0.4

Steps to Reproduce:

1. Create new stack project with stack new A
2. Build project with profiling flags with stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
3. Run the executable with profiling flags with stack exec A-exe.exe -- +RTS -p

Expected
I expect a profiling file A-exe.prof to be created somewhere within the project directory.

Actual
No profile summary file can be found. A profile file can be made by executing the file directly without using stack.

Here is the stack version output:

> stack --version
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64

This is the stack command I ran with the output:

> stack exec A-exe.exe --verbose -- +RTS -p
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64
2016-04-11 19:12:53.846001: [debug] Checking for project config at: C:\Users\andrew\Dropbox\Haskell\A\stack.yaml @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Config src/St
ack\Config.hs:761:9)
2016-04-11 19:12:53.892878: [debug] Loading project config file stack.yaml @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Config src/Stack\Config.hs:779:13)
2016-04-11 19:12:53.908504: [debug] Trying to decode C:\stack_root\build-plan-cache\x86_64-windows\lts-5.12.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.Versio
nTagged src/Data\Binary\VersionTagged.hs:55:5)
2016-04-11 19:12:53.955378: [debug] Success decoding C:\stack_root\build-plan-cache\x86_64-windows\lts-5.12.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.Versio
nTagged src/Data\Binary\VersionTagged.hs:64:13)
2016-04-11 19:12:53.955378: [debug] Trying to decode C:\stack_root\indices\Hackage\00-index.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.VersionTagged src/Data
\Binary\VersionTagged.hs:55:5)
2016-04-11 19:12:54.471037: [debug] Success decoding C:\stack_root\indices\Hackage\00-index.cache @(stack_7LDm9brrZDRGPali8XJ7ve:Data.Binary.VersionTagged src/Data
\Binary\VersionTagged.hs:64:13)
2016-04-11 19:12:54.502285: [debug] Run process: ghc --info @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.643010: [debug] Run process: ghc --numeric-version @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.721145: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal version @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Rea
d src/System\Process\Read.hs:269:3)
2016-04-11 19:12:54.890404: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack_7LDm9brrZDRGPali8XJ7ve:System.Process.Read src/System\Process\R
ead.hs:269:3)
2016-04-11 19:12:55.063277: [debug] Run process: A-exe.exe  @(stack_7LDm9brrZDRGPali8XJ7ve:Stack.Exec src/Stack\Exec.hs:51:5)
2016-04-11 19:12:55.110172: [debug] Run process: C:\Users\andrew\Dropbox\Haskell\A\.stack-work\install\3fbeae10\bin\A-exe.exe  @(stack_7LDm9brrZDRGPali8XJ7ve:Syste
m.Process.Run src/System\Process\Run.hs:105:5)
someFunc

[mgsloan]

@ahgibbons Ah, I think what's happening is that the +RTS option is getting processed by the stack executable. I've removed the -rtsopts flag from the build. Does latest stack HEAD fix the issue for you? (Use stack upgrade --git to try it out)

[ahgibbons]

@mgsloan So I have done the following:

1. Upgrade stack version using > stack upgrade --git
2. Confirm stack version change using > stack --version with result Version 1.0.5, Git revision afead43a8b881871f250852401a6395fbe650e6b x86_64. I assume this is correct.
3. Create new stack project using stack new A and move into the new directory.
4. Build executable using stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts". This is the same command that I used previously.
5. Execute program using stack exec A-exe.exe -- +RTS -p.

The results are the same as before: I cannot find an A-exe.prof that I would expect to created. I read in the commit comments that you removed the +rtsopts from the stack executable. I'm not sure if that means I shouldn't include it in step 4, so I repeated all the steps except in step 4 I used the command stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto". Again, I have the same results.

[sjakobi]

Here's a stack overflow question describing the same problem.

[mgsloan]

It works fine for me: :/

mgsloan@computer:~/fpco/test-stack$ stack new issue2022
...
mgsloan@computer:~/fpco/test-stack$ cd issue2022/
mgsloan@computer:~/fpco/test-stack/issue2022$ ls
app  issue2022.cabal  LICENSE  Setup.hs  src  stack.yaml  test
mgsloan@computer:~/fpco/test-stack/issue2022$ stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
issue2022-0.1.0.0: configure
Configuring issue2022-0.1.0.0...
issue2022-0.1.0.0: build
Preprocessing library issue2022-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Lib.o )
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/Lib.p_o )
Warning: -rtsopts and -with-rtsopts have no effect with -shared.
    Call hs_init_ghc() from your main() function to set these options.
In-place registering issue2022-0.1.0.0...
Preprocessing executable 'issue2022-exe' for issue2022-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/issue2022-exe/issue2022-exe-tmp/Main.p_o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.7.0/build/issue2022-exe/issue2022-exe ...
issue2022-0.1.0.0: copy/register
Installing library in
/home/mgsloan/fpco/test-stack/issue2022/.stack-work/install/x86_64-linux/lts-5.13/7.10.3/lib/x86_64-linux-ghc-7.10.3/issue2022-0.1.0.0-08X891RwsgX7LLfuHOu4ae
Installing executable(s) in
/home/mgsloan/fpco/test-stack/issue2022/.stack-work/install/x86_64-linux/lts-5.13/7.10.3/bin
Registering issue2022-0.1.0.0...
mgsloan@computer:~/fpco/test-stack/issue2022$ stack exec -- issue2022-exe +RTS -p
someFunc
mgsloan@computer:~/fpco/test-stack/issue2022$ ls
app  issue2022.cabal  issue2022-exe.prof  LICENSE  Setup.hs  src  stack.yaml  test

Note that --profile is essentially the same as --executable-profiling --library-profiling --ghc-options="-fprof-auto".

[ahgibbons]

@mgsloan , I've just tried again now, following the commands you used above and it did not work. I'm using the following stack version Version 1.0.5, Git revision 57eb614df50826f38b923e1892cda904288a8ec9 x86_64 hpack-0.12.0. I am using Windows 10.

PS C:\Users\andrew\Dropbox\Haskell> stack new issue2022
Downloading template "new-template" to create project "issue2022" in issue2022\ ...
...
PS C:\Users\andrew\Dropbox\Haskell> cd issue2022
PS C:\Users\andrew\Dropbox\Haskell\issue2022> ls

    Directory: C:\Users\andrew\Dropbox\Haskell\issue2022

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
da----        4/26/2016  10:48 AM                app
da----        4/26/2016  10:48 AM                src
da----        4/26/2016  10:48 AM                test
-a----        4/26/2016  10:48 AM           1262 issue2022.cabal
-a----        4/26/2016  10:48 AM           1528 LICENSE
-a----        4/26/2016  10:48 AM             46 Setup.hs
-a----        4/26/2016  10:48 AM           2181 stack.yaml


PS C:\Users\andrew\Dropbox\Haskell\issue2022> stack build --executable-profiling --library-profiling --ghc-options="-fprof-auto -rtsopts"
issue2022-0.1.0.0: configure
Configuring issue2022-0.1.0.0...
issue2022-0.1.0.0: build
Preprocessing library issue2022-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering issue2022-0.1.0.0...
Preprocessing executable 'issue2022-exe' for issue2022-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\issue2022-exe\issue2022-exe-tmp\Main.
p_o )
Linking .stack-work\dist\2672c1f3\build\issue2022-exe\issue2022-exe.exe ...
issue2022-0.1.0.0: copy/register
Installing library in
C:\Users\andrew\Dropbox\Haskell\issue2022\.stack-work\install\789b972d\lib\x86_64-windows-ghc-7.10.3\issue2022-0.1.0.0-0
8X891RwsgX7LLfuHOu4ae
Installing executable(s) in
C:\Users\andrew\Dropbox\Haskell\issue2022\.stack-work\install\789b972d\bin
Registering issue2022-0.1.0.0...
PS C:\Users\andrew\Dropbox\Haskell\issue2022> stack exec -- issue2022-exe +RTS -p
someFunc
PS C:\Users\andrew\Dropbox\Haskell\issue2022> ls

    Directory: C:\Users\andrew\Dropbox\Haskell\issue2022

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
da----        4/26/2016  10:49 AM                .stack-work
da----        4/26/2016  10:48 AM                app
da----        4/26/2016  10:48 AM                src
da----        4/26/2016  10:48 AM                test
-a----        4/26/2016  10:48 AM           1262 issue2022.cabal
-a----        4/26/2016  10:48 AM           1528 LICENSE
-a----        4/26/2016  10:48 AM             46 Setup.hs
-a----        4/26/2016  10:48 AM           2181 stack.yaml

[jcbelanger]

I also wanted to report having the issue with Stack 1.1.0 on Windows 10:

E:\Workspace>stack --version
Version 1.1.0, Git revision 0e9430aad55841b5ff2c6c2851f0548c16bce7cf (3540 commits) x86_64 hpack-0.13.0

E:\Workspace>stack new A
Downloading template "new-template" to create project "A" in A\ ...

The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username
You can provide them in C:\Users\Josh\AppData\Roaming\stack\config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
Or you can pass each one as parameters like this:
stack new A new-template -p "author-email:value" -p "author-name:value" -p "category:value" -p "copyright:value" -p "github-username:value"

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- A\A.cabal

Selecting the best among 7 snapshots...

* Matches lts-5.17

Selected resolver: lts-5.17
Initialising configuration using resolver: lts-5.17
Total number of user packages considered: 1
Writing configuration to file: A\stack.yaml
All done.

E:\Workspace>cd A

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/18/2016  04:52 PM    <DIR>          .
05/18/2016  04:52 PM    <DIR>          ..
05/18/2016  04:52 PM             1,206 A.cabal
05/18/2016  04:52 PM    <DIR>          app
05/18/2016  04:52 PM             1,528 LICENSE
05/18/2016  04:52 PM                46 Setup.hs
05/18/2016  04:52 PM    <DIR>          src
05/18/2016  04:52 PM             2,181 stack.yaml
05/18/2016  04:52 PM    <DIR>          test
               4 File(s)          4,961 bytes
               5 Dir(s)  91,627,700,224 bytes free

E:\Workspace\A>stack build --profile
A-0.1.0.0: configure
Configuring A-0.1.0.0...
A-0.1.0.0: build
Preprocessing library A-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering A-0.1.0.0...
Preprocessing executable 'A-exe' for A-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\A-exe\A-exe-tmp\Main.p_o )
Linking .stack-work\dist\2672c1f3\build\A-exe\A-exe.exe ...
A-0.1.0.0: copy/register
Installing library in
E:\Workspace\A\.stack-work\install\e4ebb170\lib\x86_64-windows-ghc-7.10.3\A-0.1.0.0-1EJzdxMFSOaK7jrzDoeFNj
Installing executable(s) in E:\Workspace\A\.stack-work\install\e4ebb170\bin
Registering A-0.1.0.0...

E:\Workspace\A>stack exec A-exe -- +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/18/2016  04:53 PM    <DIR>          .
05/18/2016  04:53 PM    <DIR>          ..
05/18/2016  04:53 PM    <DIR>          .stack-work
05/18/2016  04:52 PM             1,206 A.cabal
05/18/2016  04:52 PM    <DIR>          app
05/18/2016  04:52 PM             1,528 LICENSE
05/18/2016  04:52 PM                46 Setup.hs
05/18/2016  04:52 PM    <DIR>          src
05/18/2016  04:52 PM             2,181 stack.yaml
05/18/2016  04:52 PM    <DIR>          test
               4 File(s)          4,961 bytes
               6 Dir(s)  91,616,243,712 bytes free

However running the executable without stack does produce the .prof file:

E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe>A-exe.exe +RTS -p
someFunc

E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A\.stack-work\dist\2672c1f3\build\A-exe

05/18/2016  04:56 PM    <DIR>          .
05/18/2016  04:56 PM    <DIR>          ..
05/18/2016  04:53 PM    <DIR>          A-exe-tmp
05/18/2016  04:53 PM         4,566,609 A-exe.exe
05/18/2016  04:56 PM             1,739 A-exe.prof
               2 File(s)      4,568,348 bytes
               3 Dir(s)  91,616,174,080 bytes free

So it looks like Stack 1.1.0 is still swallowing RTS flags

[mgsloan]

Very strange! If you do something like stack exec -- echo +RTS -p (or windows equivalent), what do you get?

It should be an adequate workaround to put -rtsopts -with-rtsopts=-p in the ghc-options in the cabal file. Is this a difference in behavior between cabal file ghc-options and those provided by CLI?

[ahgibbons]

In a new stack project A, building with stack build --profile, running stack exec A-exe.exe -- echo +RTS -p returns someFunc and nothing else. There are no .prof files to be found either.

I changed my A.cabal file, the relevant change is here:

executable A-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-p -with-rtsopts=-N
  build-depends:       base
                     , A
  default-language:    Haskell2010

Building and running with this does not make a .prof file. Although as mentioned above, if I run the A-exe.exe directly with .\A-exe.exe +RTS -p I get a .prof file.

[ahgibbons]

@mgsloan, As a side note, as someone who has no experience with the Stack source code and beginner/intermediate experience with Haskell, is this something that I might be able to try and fix on my Windows computer? I assume you develop Stack on Linux or OSX and this seems to be a Windows specific problem.

[jcbelanger]

I was having issues getting stack to run windows echo command. I believe this is because echo is part of cmd.exe and not its own executable. Instead, I modified the default project's Lib.hs to report the flags:

module Lib
    ( someFunc
    ) where

import GHC.Environment (getFullArgs)

someFunc :: IO ()
someFunc = mapM_ putStrLn =<< getFullArgs

Running with stack:

E:\Workspace\A>stack exec A-exe -- hello +RTS -test -RTS world
E:\Workspace\A\.stack-work\install\e4ebb170\bin\A-exe.exe
hello
world

Running the exe directly shows the correct RTS flags:

E:\Workspace\A\.stack-work\install\e4ebb170\bin>A-exe.exe hello +RTS -test -RTS world
A-exe.exe
hello
+RTS
-test
-RTS
world

I tried the workaround by putting -with-rtsopts=-p in the cabal file. Note how I removed the existing -with-rtsopts=-N. More on that later.

executable A-exe
  hs-source-dirs:      app
  main-is:             Main.hs
  ghc-options:         -threaded -rtsopts -with-rtsopts=-p
  build-depends:       base
                     , A
  default-language:    Haskell2010

I built with stack build --profile and tried running both stack exec A-exe and A-exe.exe without any RTS flags and did not get a .prof file. Only directly running the executable without stack A-exe.exe +RTS -p produces a .prof file. Interestingly, looking at the 3rd line of this A-exe.prof file reports the RTS also received the -N flag:

 A-exe.exe +RTS -N -p -RTS

I don't know where the -N flag is coming from because I had explicitly removed it from the cabal file. This line changes if I add the flag manually A-exe.exe +RTS -p -N to:

A-exe.exe +RTS -N -p -N -RTS

I also wanted to ask if adding -with-rtsopts=-p DID work, that we add it to stack build --profile

[mgsloan]

So yeah, it looks like stack is eating the +RTS ... -RTS options. That makes no sense as it isn't built with -rtsopts. What happens if you use the stack fetched via stack upgrade --git? Perhaps it has something to do with how the windows executable is getting built

[ahgibbons]

@mgsloan, I'm not sure about about @jcbelanger but I upgraded my stack version using stack upgrade --git before running my tests.

[jcbelanger]

It took me a while to install because I first needed mingw+mysys for network to build, but I now have an echo command to run for stack. The results were the same; a .prof file is only created when the executable is ran directly, without stack:

E:\Workspace>stack --version
Version 1.1.3, Git revision 607402281ae4a4646ad3b0d3df0e64008884d2e9 x86_64 hpack-0.14.0

E:\Workspace>stack new A
Downloading template "new-template" to create project "A" in A\ ...

The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username
You can provide them in C:\Users\Josh\AppData\Roaming\stack\config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
Or you can pass each one as parameters like this:
stack new A new-template -p "author-email:value" -p "author-name:value" -p "category:value" -p "copyright:value" -p "github-username:value"

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- A\A.cabal

Selecting the best among 7 snapshots...

* Matches lts-5.17

Selected resolver: lts-5.17
Initialising configuration using resolver: lts-5.17
Total number of user packages considered: 1
Writing configuration to file: A\stack.yaml
All done.

E:\Workspace>cd A

E:\Workspace\A>stack build --profile
A-0.1.0.0: configure
Configuring A-0.1.0.0...
A-0.1.0.0: build
Preprocessing library A-0.1.0.0...
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.o )
[1 of 1] Compiling Lib              ( src\Lib.hs, .stack-work\dist\2672c1f3\build\Lib.p_o )
In-place registering A-0.1.0.0...
Preprocessing executable 'A-exe' for A-0.1.0.0...
[1 of 1] Compiling Main             ( app\Main.hs, .stack-work\dist\2672c1f3\build\A-exe\A-exe-tmp\Main.p_o )
Linking .stack-work\dist\2672c1f3\build\A-exe\A-exe.exe ...
A-0.1.0.0: copy/register
Installing library in
E:\Workspace\A\.stack-work\install\e4ebb170\lib\x86_64-windows-ghc-7.10.3\A-0.1.0.0-1EJzdxMFSOaK7jrzDoeFNj
Installing executable(s) in E:\Workspace\A\.stack-work\install\e4ebb170\bin
Registering A-0.1.0.0...

E:\Workspace\A>stack exec A-exe -- +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/20/2016  11:05 AM    <DIR>          .
05/20/2016  11:05 AM    <DIR>          ..
05/20/2016  11:05 AM    <DIR>          .stack-work
05/20/2016  11:05 AM             1,206 A.cabal
05/20/2016  11:05 AM    <DIR>          app
05/20/2016  11:05 AM             1,528 LICENSE
05/20/2016  11:05 AM                46 Setup.hs
05/20/2016  11:05 AM    <DIR>          src
05/20/2016  11:05 AM             2,181 stack.yaml
05/20/2016  11:05 AM    <DIR>          test
               4 File(s)          4,961 bytes
               6 Dir(s)  91,828,965,376 bytes free

E:\Workspace\A>.stack-work\install\e4ebb170\bin\A-exe.exe +RTS -p
someFunc

E:\Workspace\A>dir
 Volume in drive E is Files
 Volume Serial Number is 10C8-9F82

 Directory of E:\Workspace\A

05/20/2016  11:10 AM    <DIR>          .
05/20/2016  11:10 AM    <DIR>          ..
05/20/2016  11:06 AM    <DIR>          .stack-work
05/20/2016  11:10 AM             1,739 A-exe.prof
05/20/2016  11:05 AM             1,206 A.cabal
05/20/2016  11:05 AM    <DIR>          app
05/20/2016  11:05 AM             1,528 LICENSE
05/20/2016  11:05 AM                46 Setup.hs
05/20/2016  11:05 AM    <DIR>          src
05/20/2016  11:05 AM             2,181 stack.yaml
05/20/2016  11:05 AM    <DIR>          test
               5 File(s)          6,700 bytes
               6 Dir(s)  91,783,544,832 bytes free

And now that I can test with echo:

E:\Workspace\A>stack exec -- echo hello +RTS -p -RTS world
hello world

[mgsloan]

Only thing I can think of here is that maybe there is an issue with GHC on windows where it processes the rts options even if -rtsopts isn't passed.

[varosi]

Still happening on Stack 1.1.2 with stripping RTS options from command-line.

[rwbarton]

I just came across this issue randomly, but executables produced by GHC are definitely supposed to process RTS options even if -rtsopts is not passed! -rtsopts just enables some less "safe" RTS options that you might not want to allow in cases where you don't have control over the command line arguments.

[rwbarton]

        // The '--' argument is passed through to the program, but
        // disables all further +RTS ... -RTS processing.

stack exec -- issue2022-exe +RTS -p will work, but stack exec A-exe.exe -- +RTS -p will not because the -- is also visible to A-exe.exe's RTS.

[jcbelanger]

Unfortunately, Even putting the executable after the -- argument didn't work for me:

On windows, with stack Version 1.1.3, Git revision 6074022 x86_64 hpack-0.14.0 with the following test program:

import GHC.Environment (getFullArgs)

main :: IO ()
main = mapM_ putStrLn =<< getFullArgs

stack exec -- issue2022-exe -flagBefore +RTS -p -N -RTS -flagAfter produces:

-flagBefore
-flagAfter

while running the executable without stack, issue2022-exe -flagBefore +RTS -p -N -RTS -flagAfter, produces:

-flagBefore
+RTS
-p
-N
-RTS
-flagAfter

[rwbarton]

What happens with stack exec -- issue2022-exe +RTS -?? Assuming you get the RTS option help, the name of the program that saw +RTS -? will be printed at the start of every line.

[jcbelanger]

Running stack exec -- issue2022-exe +RTS -? produces a single line:

E:\Workspace\issue2022\.stack-work\install\462e5c81\bin\issue2022-exe.exe

Running .stack-work\install\462e5c81\bin\issue2022-exe.exe +RTS -? produces:

issue2022-exe.exe:
issue2022-exe.exe: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
issue2022-exe.exe:
issue2022-exe.exe:     +RTS Indicates run time system options follow
issue2022-exe.exe:     -RTS Indicates program arguments follow
issue2022-exe.exe:    --RTS Indicates that ALL subsequent arguments will be given to the
issue2022-exe.exe:           program (including any of these RTS flags)
issue2022-exe.exe:
issue2022-exe.exe:  The following run time system options are available:
issue2022-exe.exe:
.....so on....

Reading the help, I learned about the --RTS flag which might be a good solution for this issue. Running stack exec issue2022-exe --RTS -- -flagBefore +RTS -p -N -RTS -flagAfter produces:

-flagBefore
+RTS
-p
-N
-RTS
-flagAfter

It also creates a .prof file!!!

Can we get the --RTS flag to always be set with stack? We just have to make sure --RTS appears whenever there is --.

[mgsloan]

Interesting! We can't actually force the --RTS flag because it gets processed by the GHC runtime. This implies that on windows, stack is built with -rtsopts?!?! Very strange, because AFAICT it should not be built with that.

[rwbarton]

No, it doesn't imply that. See my first comment on this thread.

I really don't understand how the above output from stack exec -- issue2022-exe +RTS -? is possible: it seems to imply that something is consuming +RTS but not -?. I can't reproduce though since I don't have Windows. Maybe there is an extra process in the chain?

[mgsloan]

Oh wow! That is news to me, thanks for digging it up! Very surprising behavior from GHC here. I have split off #2640 as a new issue to discuss this specific problem.

[rwbarton]

This confusing situation with Windows turned out to be due to a GHC bug, see https://ghc.haskell.org/trac/ghc/ticket/13287.

[snoyberg]

Now that #3012 has been merged (thanks @AndreasPK!), should this be closed?

[jcbelanger]

Yes, that referenced issue is a good workaround.

Thanks @AndreasPK !