Two blocks of code were trying to do the same thing in different ways;
standardise on one, and only add the compile flags if CMake won't do it
itself (policy CMP0067).
Previously, the block stack was a true stack. However in most cases, you
want to traverse the stack from the topmost frame down. This is awkward
to do with range-based for loops.
Switch it to pushing new blocks to the front of the block list.
This simplifies some traversals.
Work around the issue in CMake where C++ standard doesn't get propagated
to CHECK_CXX_SOURCE_COMPILES. Also correctly check for std::make_unique;
the define was missing from the config.h header.
GCC 4.8 requires the use of `-std=gnu++11` or similar to enable atomic
features. However, older versions of CMake don't pick up the
project-wide target for C++11 when building the configure check targets.
Although CMake policy 0067 could be set to NEW to enable this, it only
exists on CMake 3.8 and newer, while many of our supported platforms are
on an older version.
This was previously required so that, if there was a redirection to a
file, we would fork a process to create the file even if there was no
output. For example `echo -n >/tmp/file.txt` would have to create
file.txt even though it would be empty.
However now we open the file before fork, so we no longer need special
logic around this.
780bac671f did not actually successfully
compile on any platforms, leading to -latomic always being added
(including on platforms it does not exist on).
Work on #5865.
Do this only when splitting on IFS characters which usually contains
whitespace characters --- read --delimiter is unchanged; it still
consumes no more than one delimiter per variable. This seems better,
because it allows arbitrary delimiters in the last field.
Fixes#6406
user_supplied was used to distinguish IO redirections which were
explicit, vs those that came about through "transmogrphication." But
transmogrification is no more. Remove the flag.
"-C" is short for "--case-sensitive", which is entirely okay with "--delete".
The one that isn't okay is "-X", which is short for "--Clear".
Seen on gitter.im
This patch keeps the existing `make` shims via `GNUmakefile` and
`BSDmakefile` but also resolves the issue reported in #6264 with
CMake-generated `Makefile` overwriting the extant `Makefile` causing the
source directory to become dirty once again.
Closes#6264
This prefixes files beginning with `-` with a `./` when generating
completions *in fish code*. Standard completions for directory listings
generated by the C++ directory traversal code are not afected by this
patch.
Most fish completions defer to `__fish_complete_suffix` to generate the
file/directory completions, these *will* be corrected.
As of GCC 7.4 (at least under macOS 10.10), the previous workaround of
casting a must-use result to `(void)` to avoid warnings about unused
code no longer works.
This workaround is uglier but it quiets these warnings.
The C++ spec (as of C++17/n4713) does not specify the sign of `wchar_t`,
saying only (in section 6.7.1: Fundamental Types)
> Type wchar_t shall have the same size, signedness, and alignment
> requirements (6.6.5) as one of the other integral types, called its
> underlying type.
On most *nix platforms on AMD64 architecture, `wchar_t` is a signed type
and can be compared with `int32_t` without incident, but on at least
some platforms (tested: clang under FreeBSD 12.1 on AARCH64), `wchar_t`
appears to be unsigned leading to sign comparison warnings:
```
../src/widecharwidth/widechar_width.h:512:48: warning: comparison of
integers of different signs: 'const wchar_t' and 'int32_t' (aka 'int')
[-Wsign-compare]
return where != std::end(arr) && where->lo <= c;
```
This patch forces the use of wchar_t for the range start/end values in
`widechar_range` and the associated comparison values.
