Opened 4 years ago

Closed 7 months ago

#3647 closed feature request (fixed)

unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions

Reported by: eflister Owned by:
Priority: normal Milestone: 7.8.1
Component: Compiler (Parser) Version: 6.10.4
Keywords: language pragma extensions error message warning Cc: erik.flister@…, michal.terepeta@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: many :-) Blocked By:
Blocking: Related Tickets:

Description

it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-#LANGUAGE ...#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accepted in the pragma list. even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable). also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args. see http://hackage.haskell.org/trac/ghc/ticket/3616#comment:8.

Change History (24)

comment:1 Changed 4 years ago by duncan

By all means improve the error message but please do not extend the LANGUAGE pragma syntax. It means every other compiler and tool that has to know about the pragma must also be extended (and in a rather quirky way). Standards are a good thing! :-)

Perhaps we can get ghc's error messages to suggest LANGUAGE pragmas rather than the ghc -XBlah style.

comment:2 follow-up: Changed 4 years ago by eflister

not to be annoying, but i don't understand why it's not ok for ghc to accept (with a warning) a SUPERSET of the official syntax. that doesn't change the standard and it doesn't imply that any other compiler has to do anything different. a warning would be the best user interaction -- "i know what you meant to say, and i'm doing it, you should just know that what you said isn't portable, and here's how to fix it. would you like me to fix it for you?"

comment:3 in reply to: ↑ 2 Changed 4 years ago by duncan

Replying to eflister:

not to be annoying, but i don't understand why it's not ok for ghc to accept (with a warning) a SUPERSET of the official syntax.

At first you'd expect that accepting a superset would not cause any problems. However what happens is that people will start using that new syntax and then suddenly those packages/programs cannot be used with the tools that stick to the official syntax.

that doesn't change the standard and it doesn't imply that any other compiler has to do anything different.

It doesn't change the official standard but it does change the de-facto standard, and other compilers and tools will have to change to keep up so that they can continue to process all code that people write.

a warning would be the best user interaction -- "i know what you meant to say, and i'm doing it, you should just know that what you said isn't portable, and here's how to fix it. would you like me to fix it for you?"

Certainly a nice error message is good however I would suggest that it be "i know what you meant to say, here's how to fix it." (and perhaps an IDE could also do "would you like me to fix it for you?"). Also accepting the program has a low benefit and a non-trivial cost.

comment:4 follow-up: Changed 4 years ago by igloo

  • Resolution set to wontfix
  • Status changed from new to closed
  • Type of failure set to None/Unknown

I agree with Duncan: If GHC accepted

{-# LANGUAGE -XFoo #-}

then people would start using it, and then the code would not be portable.

comment:5 in reply to: ↑ 4 Changed 4 years ago by eflister

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to igloo:

you could still fix the error message. from OP:

the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args.

what about accepting -Extension flags (without the X) at the command line? how is that X helping anyone?

comment:6 Changed 4 years ago by igloo

  • Milestone set to 6.14 branch

comment:7 Changed 4 years ago by igloo

  • Milestone changed from 6.14 branch to 6.14.1

comment:8 Changed 3 years ago by michalt

  • Cc michal.terepeta@… added
  • Status changed from new to infoneeded

To be honest -X<extension> error messages are a bit annoying at times. But what
output exactly do we want? For instance now GHC reports something
like this:

  `Foo' has no constructors (-XEmptyDataDecls permits this)

maybe removing -X would be better?

  `Foo' has no constructors (EmptyDataDecls permits this)

or

  `Foo' has no constructors (-XEmptyDataDecls/EmptyDataDecls permits this)

or even

  `Foo' has no constructors (-XEmptyDataDecls/LANGUAGE EmptyDataDecls permits this)

Personally I think simply removing -X would be both readable and easy to paste
(I usually specify the extensions in LANGUAGE pragmas and not as a command line
arguments). On the other hand the last one is easiest for pasting but quite a
bit longer and somewhat less readable. Any opinions?

comment:9 Changed 3 years ago by simonpj

I liked the "-X" in error messages because it's a brief. 2-character, way of saying that you can use a flag or a LANGUAGE pragma. But I'm happy to adopt whatever convention our users want!

Simon

comment:10 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:11 Changed 3 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:12 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1
  • Status changed from infoneeded to new

comment:13 Changed 3 years ago by igloo

  • Owner set to igloo

comment:14 Changed 2 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1

punting

comment:15 Changed 19 months ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:16 Changed 18 months ago by igloo

  • Difficulty set to Unknown

The main problem I find with "-XFoo" is that you can't easily select it just by double clicking on it. That means that if you want to put it into a LANGUAGE pragma then you have to manually select everything apart from the X.

What do people think about allowing "-X Foo" as a command-line flag, and then using that form in error messages?

comment:17 Changed 18 months ago by igloo

  • Milestone changed from 7.6.2 to 7.8.1

comment:18 Changed 9 months ago by igloo

  • Owner igloo deleted

comment:19 Changed 7 months ago by nomeata

I’m joining the “we need something copyable” section (as expressed in #8269), and I’d also throw in the argument that it is better practice to use {-# LANGUAGE ... #-} than flags.

(To be honest I never understood why there are flags at all: If a source file uses a multi-way if, then it better declares that. Ok, so for GHCi you need command flags, but for anything else?..)

Since error messages compactness is an issue I’m in favour of

  `Foo' has no constructors (EmptyDataDecls permits this)

since by now most GHC users will readily recognize CamelCaseWords? as language extensions. This should hopefully make everyone happy.

comment:20 Changed 7 months ago by nomeata

I have a patch for this at https://github.com/nomeata/ghc/compare/T3647 and https://github.com/nomeata/ghc-testsuite/compare/T3647 and will merge them soon (today or tomorrow) unless someone shouts violently.

comment:21 Changed 7 months ago by nomeata

  • Status changed from new to patch

comment:22 Changed 7 months ago by Joachim Breitner <mail@…>

In 9278994a3606783f60101057646a1fab4e4d217d/ghc:

Give language pragma suggestions without -X

for easier copy'n'paste. This fixes: #3647

comment:23 Changed 7 months ago by Joachim Breitner <mail@…>

In bb0e5b59b11037529b5a1c623fe077988c853056/testsuite:

Adjust test suite to new Language Pragma warnigns

(this is related to #3647)

comment:24 Changed 7 months ago by nomeata

  • Resolution set to fixed
  • Status changed from patch to closed
  • Test Case set to many :-)
Note: See TracTickets for help on using tickets.