Quoted component names containing spaces are impossible to refer to

[leana8959]

Describe the bug
In the library, executable or test section it is possible to define a library with name within quotes.
By quoting the name, the library name can contain spaces.

When a library name contains spaces, it is impossible to refer to it in a build-depends fields because quotes are not allowed.
It is also impossible to refer to it in the CLI.

Cabal doesn't stop the user from quoting component name, nor from putting spaces.

There are in total only roughly 78 cabal files that does this on Hackage.

To Reproduce
Steps to reproduce the behavior:

• Go to the repository https://github.com/leana8959/cabal-quote-component-name-repr
• See the steps to reproduce the error.

TL;DR:

• Add a trailing space to my-lib, and you won't be able to refer to it in the executable.
  It is not possible to put quotes in the build-depends field.

  Building the executable when the executable doesn't depend on the library would work.
  There's no hard parse error.

• Add a trailing space to my-exe, and the executable will have a space in its name.

  Here's a silly example:

  Preprocessing library 'my-lib' for quote-component-name-repr-0.1.0.0...
  Building library 'my-lib' for quote-component-name-repr-0.1.0.0...
  Configuring executable '" m y - e x e "' for quote-component-name-repr-0.1.0.0...
  Preprocessing executable '" m y - e x e "' for quote-component-name-repr-0.1.0.0...
  Building executable '" m y - e x e "' for quote-component-name-repr-0.1.0.0...
  [1 of 1] Compiling Main
  [2 of 2] Linking dist-newstyle/build/x86_64-linux/ghc-9.10.3/quote-component-name-repr-0.1.0.0/x/" m y - e x e "/build/ m y - e x e / m y - e x e
  

Expected behavior

Quotes in component names should be a hard parse error.

System information

• Operating system: NixOS 26.05
• cabal: 10aed4e,
• ghc: 9.10.3 from nixpkgs

Additional context
Add any other context about the problem here.

[Kleidukos]

This is a crazy feature that should definitely be removed with the next version of the cabal syntax.

[Mikolaj]

Personally, I think, absolutely, deprecate and remove?

But Phil warns to check if maybe there is a practice of using spaces somewhere else in the Haskell toolset and we might get cabal incompatible with it or something? Do we know how this was introduced and where it's used?

[leana8959]

Do we know how this was introduced and where it's used?

I think it's an overlook. It is possible to have quoted symbols as section arguments, and field grammar never formally prevented it.

Here in the goSection function parsing field grammar, we don't do any special handling for quotes.

cabal/Cabal-syntax/src/Distribution/PackageDescription/Parsec.hs

Lines 299 to 301 in fa68585

	name' <- parseUnqualComponentName pos args
	let name'' = LSubLibName name'
	lib <- lift $ parseCondTree' (libraryFieldGrammar name'') (libraryFromBuildInfo name'') commonStanzas fields

Under the hood, parseNameBS is called. SecArgName is the normal string, SecArgStr represents a quoted string.

cabal/Cabal-syntax/src/Distribution/PackageDescription/Parsec.hs

Lines 420 to 423 in fa68585

	[SecArgName _pos secName] ->
	pure secName
	[SecArgStr _pos secName] ->
	pure secName

With a rough grep I found ~78 files using quoted library/executable component names. We can still deprecate it before it gets out of hand!

[ulysses4ever]

+1 for removing (bonus point if you avoid the temptation of diving into software archeology and figuring how it came into being)