[GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input
#11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Create any valid files A.hs and A.c, then run `ghc --make A.hs A.c`. You'll get one `A.o` file for `A.hs`; the `A.o` from `A.c` is lost to the sands of time. I thought this situation would be pretty unlikely but geekosaur mentioned to me that he had seen someone run into this problem before. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11201 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What is the suggested alternative behavior? Fail when detecting that two output filenames would be the same, or just warn that something looks fishy? Presumably handling the situation gracefully (e.g. linking the two object files together, or choosing a different output file name) is out of the question. This is just one of a number of ways to shoot oneself in the foot with poorly named input files (try compiling both `Foo.hs` and `Foo.lhs` in the same command for a good time), so I don't think it is worth investing much complexity here. The more important issue is to keep the compiler's behavior (i.e. "`Foo.hs` gets compiled to `Foo.o` and `Foo.hi`, clobbering the existing files) predictable enough that the user can be expected to reason about it and not get themselves into situations such as this one. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11201#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): GHC's behavior is deterministic, and to some degree makes sense, but I don't think it's very transparent to the user. It goes something like: * If hiDir is set, `A.hs` gets compiled to `$hiDir/B.hi` where `B` is the `module` declaration inside the file. * If hiDir is not set, `A.hs` gets compiled to `A.hi`. And then the `.o` files are handled separately (so if you say `ghc --make A.hs -odir foo` where `A.hs` defines `module B` then you'll get `foo/B.o` and `A.hi`). Non-Haskell files operate differently: * If oDir is set, `b/a.c` gets compiled to `$odir/b/a.o`. * If it is not set, `b/a.c` gets compiled to `$odir/b/a.c`. I don't know what the right alternate behavior is. Possibilities: 1. Simply warn when clobbering can occur 2. Designate some uses of the command line as "blessed" and give warnings if you use it otherwise. For example, it would warn if you specify `hiDir` but not `oDir`. Probably should be OK to specify both. I'd like to also warn if you use `outputDir` with a file whose filename doesn't match the module name, but I'm pretty sure Cabal uses this to build exectuables. 3. Interface/object files for Haskell should never be based off of the internal module name; they should always be based off of the source file name. But you have to munge prefixes because you can also have `ghc --make src1/Foo.hs src2/Bar.hs -isrc1 -isrc2`, ugh! Here is a suggested meta-rule: given an object/interface filename, it should be EASY to tell how to build it. I don't know how to achieve that and maintain BC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11201#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here is a real-life example with an added twist: http://stackoverflow.com/questions/34823628/calling-haskell-from-c -getting-multiple-definition-of-main-linker-error On the one hand, seeing occurrences of this confusing people "in the wild" argues towards doing something; but on the other hand, this particular instance illustrates how it is tricky to do something correct. How do we know whether `inc.o` and `Inc.o` are names that refer to the same file? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11201#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC