Opened 3 months ago

Last modified 4 weeks ago

#15660 new bug

source file modify race leads to inconsistent error message

Reported by: joeyhess Owned by:
Priority: low Milestone:
Component: Compiler Version: 8.2.2
Keywords: newcomer Cc: osa1
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Poor/confusing error message Test Case:
Blocked By: Blocking:
Related Tickets: #15917 Differential Rev(s):
Wiki Page:

Description

I got this odd error message from ghc:

Command/AddUrl.hs:120:32: error:
    lexical error in string/character literal at character '-'
    |
120 |                 BatchNull -> '\0'
    |                                ^

Part of the error message says that '-' is the problem character, but the quoted line of code does not contain that.

What happened is I started the build, noticed I had typoed '\-' and quickly corrected it in my editor and saved. It seems ghc must have read the source file twice, so I raced it and so experienced this inconsistency.

I wonder if it could display the wrong line entirely if a larger change was made to the file?

Thanks for your time with such a minor thing as this bug.

Change History (7)

comment:1 Changed 2 months ago by bgamari

Indeed this is a known limitation of GHC's implementation of caret diagnostics (which indeed re-reads the source file to extract the span indicated in the error message).

comment:2 Changed 2 months ago by osa1

Cc: osa1 added

comment:3 Changed 2 months ago by osa1

Does anyone know how do other compilers (gcc, clang, ...) do this? I see two options:

  • Copy the files to /tmp/ before reading, use the files in /tmp/ in consecutive reads. We need to make sure we clean /tmp/ after each run.
  • Keep the parsed source in memory, use it in caret diagnostics.

comment:4 Changed 2 months ago by bgamari

I argued for your second option when we were discussion how to implement caret diagnostics. However, others made the very reasonable counterpoint that this won't work well with CPP. This is unfortunate, but CPP is too commonplace to ignore at this point.

Copying sources to /tmp sounds plausible, although could be a bit painful to implement.

comment:5 Changed 2 months ago by joeyhess

When I experienced this in the wild, the only problem was the surprise that it was mixing versions of the file; once past the surprise it was little bother to need to look up the code manually. So it would probably suffice for ghc to detect the race and not quote the wrong version of the file. I suppose it could use file stat information or a hash and so avoid keeping a copy.

comment:6 Changed 2 months ago by bgamari

Keywords: newcomer added

So it would probably suffice for ghc to detect the race and not quote the wrong version of the file. I suppose it could use file stat information or a hash and so avoid keeping a copy.

Yes, this sounds like a good 80% solution. Sounds like a good task for someone new to GHC.

comment:7 Changed 4 weeks ago by RyanGlScott

Note: See TracTickets for help on using tickets.