Now that LLManifest.prefix() supports use as a context manager:
with self.prefix(...):
...
convert existing calls to that form.
This was an interesting exercise because it surfaced at least two places where
the indentation did not match the self.prefix() nesting, plus another place
where existing code was undented without a self.end_prefix() call. (That last
was an uncaught logic bug.) This underscores the value of using a SINGLE
consistent, idiomatic mechanism to limit the scope of each self.prefix() call.
LLManifest.prefix() dates back to before Python had a 'with' statement or the
notion of a context manager. That's why every prefix() call requires a
corresponding end_prefix() call.
Existing usage is of the form:
if self.prefix(...some args...):
self.path(...)
...
self.end_prefix()
The use of an 'if' statement is solely to allow the coder to indent the
statements between the self.prefix() call and the corresponding call to
self.end_prefix() -- there is no intention to make that code conditional.
self.prefix() unconditionally returned True to facilitate that usage.
But now that we have the 'with' statement, this all feels a little silly. Make
prefix() return an instance of a context-manager class so that it's reasonable
to say instead:
with self.prefix(...some args...):
self.path(...)
...
and have the Right Things happen simply by leaving the 'with' block.
The only tricky part is code to preserve compatibility with old-style usage:
* The context manager has a __nonzero__() method so that if it's tested in an
'if' statement, it can unconditionally return True.
* On leaving the 'with' block, rather than simply popping the top of each
prefix stack, the context manager restores its length to the same length it
had before that prefix() call. This allows for (erroneous but hardly
unlikely) usage of the form:
with self.prefix(...some args...):
self.path(...)
...
self.end_prefix()
Restoring the previous length makes the context manager insensitive to whether
or not end_prefix() has popped the most recent prefix() entries.
* do not redirect stderr to stdout
* catch errors generated in platform specific code and display them more nicely
* run_command no longer captures output (only used in one place;
replaced that with direct use of subprocess)
You can't legitimately perform an ordered comparison between a pointer and an
int, even 0. Fix a number of 'if (ptr > 0)' to plain 'if (ptr)'.
Fix LLEditWearableDictionary::WearableEntry constructor to avoid varargs
mechanism. It used to accept three different counts, followed by three
different lists of enums, fetched in each case as 'int' -- dubious in itself.
The constructor body performed three different loops to populate those enums
into three different member vectors.
Instead, make the constructor accept three vectors and initialize the member
vectors from the passed vectors. Now that C++ has inline vector
initialization, change existing constructor calls to pass temporary vectors
initialized with what used to be the varargs enum values.
The viewer's 00-COMPILE-LINK-RUN.txt recommends passing -gdwarf-2 to the Mac
compiler, and so we've been doing ever since before the viewer-build-variables
repo was engaged. Now we discover that when CMake sees -gdwarf-2, it removes
the -g switch entirely. It also removes it when you pass plain -g. Only when
you pass -gdwarf-with-dsym or just -gdwarf does CMake pass plain -g to the
compiler. Change -gdwarf-2, if specified, to -gdwarf so we at least get -g.
Rider Linden