Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

With packages in subdirs, compiler warnings leave subdirectory off file names #1259

Closed
chreekat opened this issue Oct 31, 2015 · 8 comments
Closed
Milestone

Comments

@chreekat
Copy link
Member

I have a package in the subdirectory 'original/'. A compiler warning mentions a file in that package, Mechanism.hs. However, it's listed as "src/Mechanism.hs", not "original/src/Mechanism.hs":

b@fuzzbomb $ stack test --pedantic
Snowdrift-0.1.4: build
Preprocessing library Snowdrift-0.1.4...
[ 61 of 110] Compiling Mechanism        ( src/Mechanism.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Mechanism.o )

src/Mechanism.hs:113:1: Warning:
    Top-level binding with no type signature:
      potentialPledge :: forall (m :: * -> *).
                         (MonadResource m, MonadBaseControl IO m, MonadLogger m) =>
                         Key Fixme.User
                         -> ProjectId
                         -> Control.Monad.Trans.Reader.ReaderT
                              SqlBackend m (Maybe (Entity Pledge), [Int64], [Int64])
<snip>...

b@fuzzbomb $ find . -name 'Mechanism.hs'
./original/src/Mechanism.hs
@borsboom
Copy link
Contributor

I've reproduced. It looks to me like this code tries to canonicalize the path from the current directory rather than from the package's root directory. So if you do cd original; stack test --pedantic it will show the fully qualified path as expected.

@borsboom borsboom added this to the P2: Should milestone Oct 31, 2015
@borsboom
Copy link
Contributor

Should now be fixed in master.

@chreekat
Copy link
Member Author

Thanks for quick action! Unfortunately I still have the problem. Or, a similar problem.

$ stack test --pedantic --no-run-tests
Snowdrift-0.1.4: build
Preprocessing library Snowdrift-0.1.4...
[ 61 of 110] Compiling Mechanism        ( src/Mechanism.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Mechanism.o )

src/Mechanism.hs:113:1: Warning:
    Top-level binding with no type signature:
      potentialPledge :: forall (m :: * -> *).
                         (MonadResource m, MonadBaseControl IO m, MonadLogger m) =>
                         Key Fixme.User
                         -> ProjectId
                         -> Control.Monad.Trans.Reader.ReaderT
                              SqlBackend m (Maybe (Entity Pledge), [Int64], [Int64])

<no location info>:
Failing due to -Werror.
Progress: 1/2
--  While building package Snowdrift-0.1.4 using:
      /home/b/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build lib:Snowdrift exe:Snowdrift exe:SnowdriftEmailDaemon exe:SnowdriftProcessPayments exe:sdm exe:sendmail-mock --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
$ stack --version
Version 0.1.7.0, Git revision eba1f2bd4ac0deb1bf946d7fb8113536963a20f9 (dirty) (2463 commits) x86_64
$

@chreekat chreekat reopened this Oct 31, 2015
@borsboom
Copy link
Contributor

borsboom commented Nov 1, 2015

Hm, strange. I actually tested the fix with the Snowdrift repo.

@chreekat
Copy link
Member Author

chreekat commented Nov 1, 2015

Let me double-triple-confirm, because I appear to be getting different
output sometimes.

On Sat, Oct 31, 2015 at 5:00 PM, Emanuel Borsboom [email protected]
wrote:

Hm, strange. I actually tested the fix with the Snowdrift repo.


Reply to this email directly or view it on GitHub
#1259 (comment)
.

@chreekat
Copy link
Member Author

chreekat commented Nov 1, 2015

Oops, can't do it now. I'll check it tomorrow.

@borsboom
Copy link
Contributor

borsboom commented Nov 1, 2015

Ok, there was a second issue: it wasn't canonicalizing paths for warnings, only those for errors. That's now fixed on master as well.

@chreekat
Copy link
Member Author

chreekat commented Nov 1, 2015

Ah, that was my hunch. Great!
On Nov 1, 2015 4:06 AM, "Emanuel Borsboom" [email protected] wrote:

Ok, there was a second issue: it wasn't canonicalizing paths for warnings,
only those for errors. That's now fixed on master as well.


Reply to this email directly or view it on GitHub
#1259 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants