Opened 10 years ago

Last modified 6 weeks ago

#314 new bug (None)

#line pragmas not respected inside nested comments

Reported by: nobody Owned by:
Priority: high Milestone: 7.12.1
Component: Compiler (Parser) Version: 6.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: read032
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by igloo)

If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong. 

Minimal file exhibiting the error:

---
{-
/*
 * Copyright (c) 2005 Jesper Louis Andersen
<[email protected]>
 *
 * Permission to use, copy, modify, and distribute this
software for any
 * purpose with or without fee is hereby granted,
provided that the above
 * copyright notice and this permission notice appear
in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
 */
-}

c = 3 * "string"

main = putStrLn $ show c
----

; ghc -cpp tmp.hs                              

tmp.hs:6:
    No instance for (Num [Char])
      arising from use of `*' at tmp.hs:6
    In the definition of `c': c = 3 * "string"

Which is clearly wrong, since ``c'' is not defined on
line 6. 

Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.

Fix: cpp(1) seems to output comments in the style
# xx "filename"

where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.

CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005

Submitter: Jesper Louis Andersen <[email protected]>

Change History (13)

comment:1 Changed 10 years ago by simonmar

  • Summary changed from option -cpp and having C comments gives wrong linenumbers to #line pragmas not respected inside nested comments
Logged In: YES 
user_id=48280

Thanks for the report.

GHC does recognise the #line pragmas generated by gcc/cpp,
but unfortunately it doesn't respect them inside {- -} comments.

To fix your example, just remove the {- -} comments around
the C comment.

It isn't an easy fix, so I've renamed the bug and downgraded
it for now.

comment:2 Changed 10 years ago by malcolmwallace

Logged In: YES 
user_id=129223

Just to mention that cpphs would be a solution - by default,
it leaves
the C comment intact within a Haskell comment.  Even with
the --strip and --text options, it replaces the C comment
with equivalent whitespace to preserve the layout.

comment:3 Changed 8 years ago by igloo

  • Architecture set to Unknown
  • Description modified (diff)
  • difficulty set to Unknown
  • Milestone set to 6.8
  • Operating System set to Unknown
  • Test Case set to read032

comment:4 Changed 7 years ago by simonmar

  • Milestone changed from 6.8 branch to _|_

comment:5 Changed 7 years ago by simonmar

  • Owner simonmar deleted
  • Status changed from assigned to new

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:8 Changed 3 years ago by orenbenkiki

  • Type of failure set to None/Unknown

It seems this bug is related to another symptom which affects re-compilation. The issue is as follows. Suppose a Module.hs file contains the following lines:

{-
#include "included"
-}

Then, if the included file contains:

-}
compiled stuff
{-

Then ghc --make will correctly re-compile the Module if the included file is modified. However, if the included file contains:

comment stuff

Then ghc --make will not re-compile the Module if the included file is modified. If the file is changed to include compiled code, then ghc --make will produce incorrect results.

I have encountered this problem while playing around with {-# #include #-} as a poor man's replacement to the proposed {-# DEPENDS #-}. Simon Marlow suggested that the problem is related to bug 314 and that it should be re-evaluated given it affects re-compilation (and not only line numbers).

comment:9 Changed 3 years ago by simonmar

  • Milestone changed from _|_ to 7.8.1
  • Priority changed from low to high

In case it isn't clear from the previous comment:

  • GHC uses #line pragmas to determine what source files were visited by the C preprocessor, and tracks dependencies on these for recompilation
  • The lexer currently ignores #line pragmas inside {- .. -} comments, and hence it misses any preprocessor dependencies inside {- .. -}

I'm raising the priority of this bug.

comment:10 Changed 14 months ago by Ian Lynagh <igloo@…>

In 1433233503b737076913c7a96b6b31edd550c82f/ghc:

Add a test for trac #314 (#line pragmas not respected inside nested comments)

comment:11 Changed 14 months ago by Ian Lynagh <igloo@…>

In 63ca28c0316f51aa2b3e23c67e28c4ed66aa165b/ghc:

read032 is broken: trac #314

comment:12 Changed 10 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

comment:13 Changed 6 weeks ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1

Note: See TracTickets for help on using tickets.