MSVC: Fix unhandled MissingConfiguration exception.

[jcbrill]

Fix an issue with an unhandled MissingConfiguration exception due to an msvc registry query that returns a path that does not exist. Multiple invocation paths were not prepared to handle the MissingConfiguration exception. The MissingConfiguration exception type was removed.

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt (and read the README.rst)
• I have updated the appropriate documentation

[jcbrill]

The [Scons-users] Build fails due to MissingConfiguration error mailing list issue was caused by a vc find_vc_dir method call in vs.py. The find_vc_dir function raised MissingConfiguration which was not handled by the vs.py invocation.

The MissingConfiguration exception was raised inside the loop evaluating registry queries for an msvc version. In general, it is better to ignore the missing msvc folder and continue because there may be additional registry key queries that might be successful.

The MissingConfiguration exception was removed in #4409 for this reason.

[bdbaddog]

So now the bad configuration yields no errors or warnings unless you're in debug mode?

[jcbrill]

So now the bad configuration yields no errors or warnings unless you're in debug mode?

Yes.

The "main" paths simply caught the exception and ignored it anyway (one caught MissingConfiguration and another caught VisualCException). Unfortunately, not all paths handled the exception. It almost appears like MissingConfiguration was meant for internal use.

It is a bad configuration in the sense that the registry and file system don't agree. There is still not a usable msvc installation which was detected and should be ignored as it is in a detection loop. Although for 10.0 it doesn't matter.

10.0 folders and registry entries are also created by winsdk 7.1 rather than the visual studio installer (although the vc folder should have been present).

[jcbrill]

The "unprotected" code path was from get_installed_visual_studios in vs.py.

get_installed_vcs in vc.py catches and ignores VisualCException.

msvc_find_valid_batch_script in vc.py used to catch and ignore MissingConfiguration.

There are three (fairly recent) toolset query methods that are "unprotected" as well.

Summary:

• The two "main" vc.py invocations caught and ignored the exception.
• The one vs.py invocation was not protected.
• The three "toolset" vc.py invocations are not protected.

[bdbaddog]

So this PR is about removing partially or poorly implemented detection of corrupted or incorrectly configured msvc install.

That sounds reasonable, but should we add an issue to handle this properly so we don't lose the idea?

[jcbrill]

So this PR is about removing partially or poorly implemented detection of corrupted or incorrectly configured msvc install.

Yes.

The intent is to ignore the corrupted or incorrectly configured msvc install. This was achieved by raising an exception and catching it somewhere higher up in the call stack.

The bug is that the exception was never caught in vs.py.

Looking solely at the typical vc.py usage, only the debug log would indicate the registry/filesystem inconsistency. It does not appear like this exception was intended to terminate the build but rather as a way to move up the call stack via catching the exception.

Due to the code evolution, ignoring the msvc root should continue in the detection loop for the version. A msvc root not found is handled correctly.

That sounds reasonable, but should we add an issue to handle this properly so we don't lose the idea?

Up to you. It really is an implementation detail. I suspect that it goes back a long way. For tracking, it wouldn't hurt though.