[Solved] Build warning latest tip

Tip no longer builds without warnings in release mode using Visual Studio 2015:

\juce_bufferingaudiosource.cpp(95): warning C4717: ‘juce::BufferingAudioSource::releaseResources’: recursive on all control paths, function will cause runtime stack overflow

Tested with commit:
SHA: 348dc1fa79acafcb025ebe37270caa390815ad88
Message: Fixed a bug where the Projucer would delete rsrc files in your ~/Library/Audio/Plug-Ins folder when re-saving audio plug-in projects

Kind of a strange place for that warning - especially since that code line hasn’t changed since 2011. What project were you building? I couldn’t reproduce this with VS 2015 when compiling the Juce Demo in both Debug/Release and 32/64-bit.

It’s a VST plugin project, 32bit target. Seems like the warning actually comes from the Linker during link-time optimization phase.

The exact commit to blame is this one:
SHA: a347689d961227bf5ab55d019f239c6b1e764755
Message: Moved simple sound player to audio_utils module

The project uses the following built-in modules:

VS2015 config pretty much the defaults:
Optimization: Maximise Speed
Whole Program Optimization: Enable link-time code generation when possible

OK This is fixed now on develop.

Quite a strange bug: by removing the simple sound player API from juce_audio_devices, MSVC somehow thinks that the only possible source object in BufferingAudioSource must be a pointer to itself - which in deed would cause an endless recursion. No idea why MSVC thinks this, especially as source can only be assigned by a parameter in the constructor which can never be this (as the object hasn’t been constructed yet when passing the source parameter to the constructor). I’ve added a non-sense if statement and that seems to make MSVC happy.

That warning has always been there (on vs2015).

@fabian, excellent, thanks for quick fix.

@Mayae, I have never seen this particular warning before the exact commit mentioned above, but perhaps it could exist under other circumstances. Nevertheless, treating every warning as an error is a pretty good habit IMO.

1 Like