Cannot specify Literal attribute in signature file

[auduchinok]

range.fs(203, 17): [FS0034] Module 'FSharp.Compiler.Range' contains�    val UnknownFileName : string    �but its signature specifies�    val UnknownFileName : string    �The literal constant values and/or attributes differ

Related StackOverflow topic:
https://stackoverflow.com/questions/48212721/unable-to-use-the-literal-attribute-in-an-f-signature-file-fsi

[auduchinok]

Please also note the corrupted line separators, previously reported in #4516.

[TIHan]

I've known about this for a while but I never created an issue, which I should have. Thank you a lot for making the issue.

This is actually very annoying because there are a lot of places where [<Literal>] really should be used. I'm just going to go ahead and fix this.

[TIHan]

After looking at the parser, the issue might be related to light status. Funny enough, if I turn light syntax "off", it will work:

module Thingo

#light "off"

[<Literal>]
val hello : string = "world"

val x : int

[abelbraaksma]

From the referenced SO issue, I noticed that auto-generation will trigger 'heavy' syntax. However, the OP didn't use it with light "off", and nobody suggested it (I never even considered it).

Heavy syntax, but not selected:

You're basically saying 'it works', but not the way you'd expect.

[TIHan]

The generation is incorrect, that's a bug as well. The signature should be:

[<Literal>]
val id : string = "some string`

[abelbraaksma]

If you then use the generator-apporach, you'd end up with two places where the literal is defined and assigned a value. That looks like a problem waiting to happen, or will the compiler know & check that the constants are equal?

[TIHan]

It's part of the design and compiler will know about it; if the values are different, the compiler will error.

From FSharpSpec 4.1 - 11.2.1 Signature Conformance for Functions and Values

If either the signature or the implementation has the [<Literal>] attribute, both must have this
attribute. Furthermore, the declared literal values must be identical.

[abelbraaksma]

Fixed in #7901, thanks!