I don't have a strong preference here, but I think there's a strong argument to be made for having it both ways - it can definitely be annoying to have e.g. an unused Debug.Trace import fail the build locally while you're still exploring. As long as it's relatively easy to switch back locally I'm fine with changing this. I suppose you'd do that by editing stack.yaml? It's a little inconvenient that that will make the working tree dirty but it's not the end of the world.

In any case I think we should omit -Wall from stack.yaml and specify it in package.yaml instead (if it isn't there already, but I imagine it is), so that the set of warnings we want to see is defined in one place and will be the same no matter how the compiler is being built, even if someone is building with a different stack.yaml or none at all (eg via cabal-install). I'd argue that it's just -Werror which should go here, if we want pedantic by default.

I assume you mean the .cabal files? Yeah, that makes sense. purescript-ast.cabal and purescript-cst.cabal already have -Wall, but purescript.cabal doesn't.

I would argue that -Werror belongs in those files as well. Aside from the general consistency argument (between CI and local, between stack and cabal-install), there's a purist position that -Werror is conceptually akin to a language extension, in that it alters the language—changes the set of programs accepted by the compiler. If we manage the language extensions in the .cabal files, that's also the appropriate place for -Werror.

In either case, I think the recommended way to get temporary relief should be to throw a {-# OPTIONS_GHC -Wwarn #-} at the top of any files being tinkered with. Stack (I don't know if this is true of Cabal as well, but I suspect it is) won't automatically rebuild files when -Werror is added or removed, which can lead to the following pit trap: you compile without -Werror, get three warnings in three different files, fix two of them but miss the third, and on the next compilation see no warnings (because the third file was unchanged, it isn't revisited by the compiler). Then you rebuild with -Werror, see no errors, push, and CI fails. The way out of this pit trap is to do a full clean and rebuild before pushing, but that's unnecessarily time-consuming and it's an extra thing to remember to do. Adding the -Wwarn as a file header pragma ensures that removing it counts as a change to the file, which catches any remaining warnings without forcing a full rebuild.

Oh sorry yes, I did mean purescript.cabal. I'm pretty sure that putting -Werror in the cabal file is not an option though, because IIRC Hackage would reject it. If you put -Werror in your cabal file, you're asking downstream users to compile with -Werror enabled when they depend on your package, which can obviously cause problems if the package starts generating benign warnings with newer versions of dependent libraries or compilers (I think that's the reason, at least).

The {-# OPTIONS_GHC -Wwarn #-} strategy sounds promising! Have you used it in practice already?

IIRC Hackage would reject it

Oh... huh. That is an excellent, if annoying, point.

Okay, so -Wall in all the .cabals and -Werror in stack.yaml it is, then!

Have you used it in practice already?

I tested it in the workflow I described, but I haven't needed to use it in anger yet.