Opened 12 years ago

Last modified 13 days ago

#314 new bug (None)

#line pragmas not respected inside nested comments

Reported by: nobody Owned by:
Priority: normal Milestone: 8.4.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 Rev(s):
Wiki Page:

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
<jlouis@mongers.org>
 *
 * 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 <jlouis@mongers.org>

Change History (17)

comment:1 Changed 12 years ago by simonmar

Summary: option -cpp and having C comments gives wrong linenumbers#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 12 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 11 years ago by igloo

Architecture: Unknown
Description: modified (diff)
difficulty: Unknown
Milestone: 6.8
Operating System: Unknown
Test Case: read032

comment:4 Changed 10 years ago by simonmar

Milestone: 6.8 branch_|_

comment:5 Changed 10 years ago by simonmar

Owner: simonmar deleted
Status: assignednew

comment:6 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:7 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:8 Changed 5 years ago by orenbenkiki

Type of failure: 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 5 years ago by simonmar

Milestone: _|_7.8.1
Priority: lowhigh

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 3 years ago by Ian Lynagh <igloo@…>

In 1433233503b737076913c7a96b6b31edd550c82f/ghc:

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

comment:11 Changed 3 years ago by Ian Lynagh <igloo@…>

In 63ca28c0316f51aa2b3e23c67e28c4ed66aa165b/ghc:

read032 is broken: trac #314

comment:12 Changed 3 years ago by thoughtpolice

Milestone: 7.8.37.10.1

comment:13 Changed 2 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1

comment:14 Changed 21 months ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:15 Changed 17 months ago by bgamari

Milestone: 8.0.18.2.1

This won't happen for 8.0.

comment:16 Changed 6 months ago by bgamari

Milestone: 8.2.18.4.1

This won't get fixed for 8.2.

comment:17 Changed 13 days ago by bgamari

Priority: highnormal

This clearly isn't particularly hurtful to anyone given it has been open for 12 years. Happy birthday, bug!

Note: See TracTickets for help on using tickets.