LWN: Comments on "Finally continuing the discussion over continue in finally"

Adding warnings in new versions

taladar — Mon, 16 Dec 2024 10:38:37 +0000

To me the most annoying variant is when people convince compiler makers to make something a warning instead of an error as a "compromise" even though it clearly should be one because they want to be able to ignore it in their existing code bases.

Adding warnings in new versions

mathstuf — Sun, 15 Dec 2024 08:12:21 +0000

There's a third way that we use in most of our projects: detect warnings at a higher level and fail the *job*, not the *build* when they show up. Benefits that I've found:

- builds with many warnings don't take umpteen cycles to get quiescence (usually less than a handful)
- ability to ignore warnings based on path (managing flags on such a level is…very obnoxious)
- ignore false positive warnings (GCC seems to have had a number around memcpy/memmove bounds lately)
- the return code can be "special" and allow the pipeline to also run tests on your warning-filled build while blocking merging

AFAIK, this is not possible with GHA as there is no way to specify "run if dependent has a given exit code". There's also no "failed, but allowed to fail" state to visually distinguish this state in the web UI.

Of course, if one doesn't have something that can do higher-level diagnostic management it's harder to build. We use CTest's ability to watch the output of the build, but I think that once SARIF becomes more widespread, it is likely to be a more reliable medium for doing this kind of filtering.

Adding warnings in new versions

rra — Sat, 14 Dec 2024 18:01:52 +0000

> Sadly there are some people who treat warnings as errors.

Speaking as one of those people, I wish everyone on all sides of these discussions would recognize that there is a social contract involved in doing this. As a developer who treats warnings as errors in my CI builds, I make that decision with the full knowledge that this means my builds will periodically break due to new warnings and I will need to go fix them. This is the behavior I want (I like continuous code improvement), which is why I chose that approach. If I don't want that obligation, then I shouldn't treat warnings as errors.

Whenever this topic comes up, there seems to be some amount of people wanting to have it both ways: the benefits of warnings, without the obligation to constantly change your code to keep it warning-free. This is not how the world works. You get to pick one or the other. You can mitigate the impact by only using warnings for development and not for release builds, but at some point you have to pick whether you want the benefits and the pain of warnings, or neither.

Perhaps the most frustrating pattern (and to be clear, I am not saying you are doing this, only that I have seen it elsewhere) is when people who don't like new warnings and therefore do not treat warnings as errors also argue against adding new warnings (that they personally don't see) on the grounds that other people treat warnings as errors. There really are two loose schools of thought about this, and part of the friction is that the two schools don't leave each other alone. I want new warnings to be added. I know that means new maintenance work for me. That's the point. This is the social contract that I am explicitly accepting.

Adding warnings in new versions

NYKevin — Fri, 13 Dec 2024 02:05:04 +0000

It is fine for projects to use -Werror, but it is also fine for compilers to introduce new warnings without any deprecation period. Then it's up to the project to decide what they want to do about the resulting warnings-converted-to-errors. The average compiler will (probably) have little sympathy if you try to make it their problem.

I don't like it so it's bad

DimeCadmium — Thu, 12 Dec 2024 04:58:07 +0000

> In mosaicml there is a return in a finally at the end of the main function, after an except: clause which swallows all exceptions. The return in the finally would swallow an exception raised from within the except: clause, but this seems to be the intention. A possible fix would be to assign the return value to a variable in the finally clause, dedent the return statement and wrap the body of the except: clause by another try-except that would swallow exceptions from it.

Must... make... more... complex!

add recursion for fun

JesseW — Thu, 12 Dec 2024 01:32:27 +0000

That is ... disgusting. Congratulations. Thank you for sharing it.

add recursion for fun

amarao — Wed, 11 Dec 2024 20:03:07 +0000

Many years ago I found this peculiar thing and wrote this abysmal thing:

```
def foo(x):
try:
foo(x+1)
except:
print(x)
finally:
foo(x)
```

Even now I can't properly argue about the sequence it generates.

Adding warnings in new versions

epa — Wed, 11 Dec 2024 17:42:53 +0000

That's true only if the project fixes on a particular exact version of a particular compiler. If you use -Werror then downstream users who are building from source, or packagers for Linux distributions, will have a hard time using a different compiler version. Even if the only change is that their newer version added a warning-level diagnostic.

So yes, it's the project's choice, but they should be aware of the consequence of that choice and explictly declare that a particular compiler version, emitting a particular set of warnings, is required to build the program. Personally, I would think that is imposing too much work on downstream if you want your program to be generally adopted.

Adding warnings in new versions

madscientist — Wed, 11 Dec 2024 13:49:57 +0000

It's a good thing for projects, of any type, to set -Werror for their own builds. The last thing you want is for your "normal" builds to be spewing tons of warnings that then no one pays any attention to. Fix these early and aggressively, before code is pushed to the main branch.

It's a bad thing for FOSS project to ship their source code packages with -Werror enabled by default for other peoples' builds. This just means that the source fails to compile for, usually, fairly innocuous reasons on users' systems in ways they probably (unless they're programmers themselves) can't fix, and generates a lot of extra work for the maintainers and authors.

Adding warnings in new versions

taladar — Wed, 11 Dec 2024 10:00:56 +0000

Honestly, a lot of the time treating warnings as errors is a workaround for compilers treating things that really should be an error as a warning because someone else complained that treating it as an error would break their existing code base.

Adding warnings in new versions

roc — Wed, 11 Dec 2024 01:34:30 +0000

For rr we have debug builds use -Werror and release builds not, on the assumption that the former is mostly people hacking on rr and the latter are mostly users who just want to build it.

Adding warnings in new versions

Paf — Tue, 10 Dec 2024 21:05:04 +0000

"Sadly there are some people who treat warnings as errors. Flags like gcc's -Werror have their place but should not be the standard way to build your program. Otherwise you're not programming C++ but some ever-shifting subset depending on what warnings the latest compiler emits. (It's fine for the developer's personal build to be extra-strict, but not to impose this downstream.)"

It's fine for projects to do this - it is their choice what level of strictness they wish to apply to their codebase. My project finds warn-as-error extremely helpful in reducing weird constructs - correct or not - and catching the occasional bug. That's our choice as a project, and we've decided the occasional silly compiler silencing dance is worth it.

I guess my point is projects can make this choice just as much as individuals and for exactly the same reasons. They get to pick their approach to "clean" builds, etc.

Adding warnings in new versions

epa — Tue, 10 Dec 2024 13:24:42 +0000

Sadly there are some people who treat warnings as errors. Flags like gcc's -Werror have their place but should not be the standard way to build your program. Otherwise you're not programming C++ but some ever-shifting subset depending on what warnings the latest compiler emits. (It's fine for the developer's personal build to be extra-strict, but not to impose this downstream.)

Similarly, if you run a subprocess and treat any output on stderr as failure then you no longer have a distinction between warnings (which you probably want to look at, but shouldn't cause everything to break right now) and errors (which are severe enough that processing should not continue unless the error is explicitly handled).

It's true that an excessively verbose runtime warning could bloat your log files and make it hard to see what's going on. But that doesn't really apply to syntax warnings, which appear only when the interpreter starts up and the program is compiled.

Adding warnings in new versions

pm215 — Tue, 10 Dec 2024 11:20:23 +0000

I think the difference with C++ is that the warnings are generated at compile time, when there's always a developer around who can act on them. So you can build your code, and fix the warnings or not, as you choose -- but either way, when you deploy the final binary your users are not going to see these warnings. With Python, even though a SyntaxWarning only appears the first time python code is byte-compiled, it's still possible or plausible that end-users who just want to use a program may get warnings, and people using a Python library may get warnings about problems in the library that they cannot fix, because "autogenerate the bytecode on demand" is kind of the intended flow.

This seems (from my reading of the comment thread) to be why Steve Dower would prefer to make it a linter error -- because the linter is a tool run by the developer on their code in advance, not something that might happen at runtime when the developer is nowhere in sight.

Adding warnings in new versions

taladar — Tue, 10 Dec 2024 10:59:14 +0000

I find that argument that a warning causes breakage particularly unconvincing in the presence of a comprehensive study that shows that a vast majority of uses (outside of linter tests) are incorrect. If anything I would consider that evidence that something stronger than a warning is warranted.

Adding warnings in new versions

chris_se — Tue, 10 Dec 2024 07:56:08 +0000

I personally don't have a strong opinion on what the best solution for the control-flow logic is (I personally think this is a hard question to answer when it comes to language design), but I find the claim that adding a warning "causes breakage" to be entirely unconvincing. I mostly work with C++ in my day job and newer compiler versions always add additional warnings that better lint the code for potential issues. As long as that new warning doesn't actually change the behavior of the code I really don't get why this would be a huge concern and intimidating to users.

That said, C++ compilers do offer the option to suppress warnings in cases where people say they know what they are doing, and while you can suppress warnings in Python, you can't really do that with SyntaxWarning as far as I am aware, because that happens before the code is executed. (Well, you could suppress them during import, but that kind of defeats the purpose.) Perhaps this could be done via a decorator like

finally:
    @warnings.suppress(warnings.SyntaxWarning)
    continue

Praise for the headline!

sn403lwn — Mon, 09 Dec 2024 23:05:06 +0000

That’s an interesting story about issues in control flow, about which I do not have strong opinions.

Thumbs up for the headline, though! I’m sure I’m not the only reader to enjoy that kind of wordplay.