Not seeing warnings in juce modules

CMake
1

A few people contributing my JUCE modules are fixing warnings that I’m not seeing in my IDE (CLion) or on compile (CMake, clang).

I’m wondering if I’m doing something wrong in CMake or if it’s possible there’s a discrepancy between CMake and Projucer for juce modules.

I’m linking against juce::juce_recommended_warning_flags. My CMake setup does have some indirection, as there’s a SharedCode INTERFACE target involved but I’ve also tried linking the plugin target directly to the warning target, and no luck).

I also tried listing the warning target under dependencies of the module header, but that’s not happy either…

I tried peeking at the juceaide code behind juce_add_module but it wasn’t apparent to me if modules have the chance to be linked to the warning target or if that’s even needed…

2

There were some discrepancies between the warnings in juce::juce_recommended_warning_flags and the recommended warnings enabled by the Projucer, I spotted this recently too. Could this have been the source of your problem?

It was recently fixed.

1 Like
3

I think potentially the biggest difference was that the CMake library enabled -Wpedantic but the Projucer didn’t.

1 Like
4

Thanks Anthony! Heh, you guys need a “I promise I pulled develop and tried again” checkbox for new forum posts! I was 2 days behind this commit on develop…

The warnings the other person saw (VS2022/win10/Projucer) still aren’t showing up for me on MacOS/CMake (after clearing out the build cache):

melatonin_inspector\melatonin\components\box_model.h(110,47): warning C4244: 'argument': conversion from 'double' to 'int'

melatonin_inspector\melatonin\components\colour_property_component.h(106,26): warning C4458: declaration of 'flags' hides class member

melatonin_inspector\melatonin\components\component_tree_view_item.h(288): warning C4702: unreachable code

melatonin_inspector\melatonin\components\properties.h(75,18): warning C4458: declaration of 'cachedImage' hides class member

It’s definitely not module specific. I tried to reproduce those pieces of code in my main plugin and I’m not getting warnings their either…

Maybe it’s just compiler implementation specific. For example, if I add a juce::Image cachedImage as a member on a component of mine, I get a warning on clang, but not if it’s in a local scope (as in my module), just member scope.

CLion is definitely not helping, indexing has been sluggish lately and it showing some other set of clang tidy warnings confuses things… maybe i need to embrace and align the clang-tidy…

5

Ah yes warnings between compilers will be different (MSVC vs Apple clang in this case I assume). Unfortunately there is not a lot we can do about that. My best suggestion is setup CI and enable warnings as errors. Maybe if everyone starts moving to the clang compiler on Windows this issue will somewhat disappear, that being said having multiple compilers find different warnings has its advantages too.

I guess it might also be possible to write some clang-tidy plugins to pick up warnings that match those in MSVC but that would probably be a lot of work!

1 Like
6

Looked a bit more closely (so I don’t go too crazy) and it seems unlike MSVC, clang doesn’t fire warnings on the following:

g.drawRect (getLocalBounds(), 1.0f); // float to int
g.drawRect (getLocalBounds(), 1.0); // double to int

Wliteral-conversion fires if the values are 1.1 instead of 1.0.

Wfloat-conversion does fire on implicit conversions like so:

float size = 1.1f;
g.drawRect (getLocalBounds(), size);

So, yeah, just implementation specific!

My best suggestion is setup CI and enable warnings as errors

I’ve migrated to happily running Windows clang in CI, but for shared modules it’s probably a good call to go MSVC.

Sorry for the false alarm!

7

@anthony-nicholls Oh, while we’re on warnings, looks like juce::Line<float> isHorizontal and isVertical need some of that sweet approximatelyEqual sauce…

modules/juce_graphics/geometry/juce_Line.h:126:94: warning: comparing floating point with == or != is unsafe [-Wfloat-equal]
bool isHorizontal() const noexcept { return start.y == end.y; }
8

Why? We use Windows clang everywhere.

9

To keep the kitchen clean for folks using defaults on VS2022 and friends.

I had someone wanting to use a module as a dependency but there were 17 unique MSVC warnings, each firing multiple times, translated to ~300 warnings cluttering their build messages.

10

I think this is because 1.0 can be exactly represented as a floating point number but 1.1 can’t.

1 Like