String formatting should validly assume that printing a list means
printing the list itself. Instead, something like this broke:
'one is: @0@ and two is: @1@'.format(['foo', 'bar'], ['baz'])
which would evaluate as:
'one is: foo and two is: bar'
or:
'the value of array option foobar is: @0@'.format(get_option('foobar'))
which should evaluate with '-Dfoobar=[]' as
'the value of array option foobar is: []'
But instead produced:
meson.build:7:0: ERROR: Format placeholder @0@ out of range.
Fixes#9530
This reverts commit c0efa7ab22.
This was a nice idea, or a beautiful hack depending on your perspective.
Unfortunately, it turns out to be a lot harder than we originally
thought. By operating on bare nodes, we end up triggering a FeatureNew
on anything that isn't a string literal, rather than anything that
isn't a string.
Since no one else has come up with a better idea for implementing a
FeatureNew, let's just revert it. Better to not have a warning, than
have it trigger way too often.
Another commit in my quest to rid InterpreterBase from all higher
level object processing logic.
Additionally, there is a a logic change here, since `str.join` now
uses varargs and can now accept more than one argument (and supports
list flattening).
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
bool to_int() will return 0 or 1, useful if one wants to set
a define to 0 or 1 based on a boolean result instead of having
it just defined or undefined.
bool to_string() will return 'true' or 'false' by default same
as when using it to format a string, but with the additional
possibility to specify two extra string arguments to be returned
as true/false values, e.g. to_string('yes', 'no'). This can be
useful when outputting messages to be shown to the user.