XCode 10: -Wauto-var-id raises several warnings


#1

After updating to XCode 10, the -Wauto-var-id warning is raised in several JUCE module files, e.g.:

In file included from /Users/work/Documents/pluginval/JuceLibraryCode/include_juce_gui_extra.mm:9:
In file included from ../../modules/juce/modules/juce_gui_extra/juce_gui_extra.mm:27:
In file included from ../../modules/juce/modules/juce_gui_extra/juce_gui_extra.cpp:133:
../../modules/juce/modules/juce_gui_extra/misc/juce_RecentlyOpenedFilesList.cpp:161:9: error: 'auto' deduced as 'id' in declaration of
      'sharedDocController' [-Werror,-Wauto-var-id]
        auto* sharedDocController = [NSDocumentController sharedDocumentController];

This breaks build scripts that treat warnings as errors, such as @dave96’s pluginval.


#2

How are you enabling the warning? I’ve added -Wauto-var-id to the Extra Compiler Flags section of the Projucer’s Xcode exporter but I’m not getting these warnings after re-saving and opening in Xcode 10.


#3

I didn’t manually enable the warning, I just got it :confused:


#4

Hmm still not seeing it, even with -Weverything turned on. What project are you building?


#5

It happens to me when building any JUCE project, for example when executing the buildscript of https://github.com/Tracktion/pluginval.

I’ve done a bit of research, and it seems like -Wauto-var-id is a clang-only warning. I couldn’t find out in which verson of clang it was introduced, but perhaps you’re using a different compiler (version)?

> clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.2)

#6

No, doing:

/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version

gives me

Apple LLVM version 10.0.0 (clang-1000.11.45.5)

I’m at a bit of a loss on this one, perhaps other people are seeing the same warning and could chime in?


#7

I’m on macOS 10.14 (Mojave), and got XCode Version 10.0 (10A255).
I can’t think of any other differences we could have in our setup.


#8

I noticed you’re using Xcode-beta.app, while I use a full release - perhaps that’s the relevant difference?


#9

Nope, I’ve tried with both. In the line which you’ve posted can you try changing:

auto* sharedDocController = [NSDocumentController sharedDocumentController];

to

auto sharedDocController = [NSDocumentController sharedDocumentController];

and see if the warning goes away?


#10

Yes, that indeed fixes the warning.

I would like to help you by eliminating all of the respective warnings and making a PR, but when updating from the latest JUCE release’s modules folder to the develop branch’s latest tip, it doesn’t build anymore…

/Users/work/Documents/JUCE/modules/juce_video/native/juce_mac_Video.h:223:52: No type or protocol named 'NSKeyValueChangeKey'

This is probably related to macOS 10.13 Deployment Target: AU build fails.

I’m starting to believe there’s something terribly wrong with my setup…


#11

Are you sure you’ve updated the modules fully and you’re not mixing-and-matching JUCE versions? What tool are you using for version control?


#12

I’m using git for version control.

When starting out with JUCE, I’ve been using the modules from the JUCE folder I downloaded with the latest release (I didn’t know I could also pull them from Github).

I now switched to the modules on the develop branch by cloning it from git, setting it as the global modules path and enabling “Use global path” for each module:

I like to believe I know what I’m doing, but there has to be something off about my setup.


#13

Yeah that all sounds correct. Just to double-check: you’ve set all of the modules in the project to use the global path which contains the latest modules? And re-saved the project in the Projucer? It might be worth also trashing the Builds folder of the project and re-saving just in case.


#14

Yes, I did a double-check - all modules set to global, the global path is correct, and this is the git status of the modules folder:

I trashed the Builds folder, executed Clean Build Folder in XCode - same errors.


#15

Hmm, OK I’m not sure what could be going on there sorry. I’ll do a quick skim of the codebase and remove all of the id -> auto* conversion warnings though.