31–40 of 72 posts
Earlier quoted context omitted.
genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?
The deprecated attribute is useless when -Werror and -Wall are both on. You can't land the attribute if any uses exist because any use is now a compiler error. You might as well just delete the entity and sort things out from there.
> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…
genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?
So it really depends if you're testing code or committing it. When you're debugging something locally, warnings like "unused parameter" or "dead code" become extremely annoying as errors. I need to be able to put "return 0;" in the middle of my function and run it as-is without having to battle the toolchain for five minutes after that every damn time.
Earlier quoted context omitted.
genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?
The issue is that not every snapshot of a source file is intended to be committed as-is. So it really depends if you're testing code or committing it. When you're debugging something locally, warnings like "unused parameter" or "dead code" become extremely annoying as errors. I need to be able to put "return 0;" in the middle of my function and run it as-is without having to battle the toolchain for five minutes afte…
But i do agree that Werror on the code/build/test cycle sound like a pain.
> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…
Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.
Unless you never build locally? And never look at a build log? You really never improve code if Werror doesn't force you to?
It's really obnoxious to also immediately and completely fail the build for someone who wants to use an updated compiler, or wants to compile for a different architecture, or wants to compare to an older compiler, or a different vendor's compiler, or test with and updated library with changed headers, or ...
Earlier quoted context omitted.
Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.
Use -Werror for the build server and have a policy that you can't commit code that generates warnings. That lets you still build locally without having to immediately fix minor warnings that would be a distraction.
Earlier quoted context omitted.
it takes a bit of discipline, but i think it is entirely possible. Even when some OSS project support a lot of different build environment, the support is usually tiered with some of the target having daily or per commit builds. Those should be setup with -Werror + exceptions where it makes sense. Once a project get to stable state (as in for a given target, all the warning are either turned off, or handled). Upgradi…
Even projects with a “stable” set of targets have too much churn for this to be practical. Just because you support “latest macOS” doesn’t mean my build should fail if I’m on a beta build ahead.
Earlier quoted context omitted.
genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?
The deprecated attribute is useless when -Werror and -Wall are both on. You can't land the attribute if any uses exist because any use is now a compiler error. You might as well just delete the entity and sort things out from there.
> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…
Earlier quoted context omitted.
Use -Werror for the build server and have a policy that you can't commit code that generates warnings. That lets you still build locally without having to immediately fix minor warnings that would be a distraction.
How can the build system differentiate between new and old errors? Maybe I misunderstand you, but it seems like that piece is missing.
Earlier quoted context omitted.
Even projects with a “stable” set of targets have too much churn for this to be practical. Just because you support “latest macOS” doesn’t mean my build should fail if I’m on a beta build ahead.
Please let me know so I can fix issues. Or let the compiler vendor know, sometimes they add something new to get feedback on how useful it is in the real world.