Commit Graph

1576 Commits

Author SHA1 Message Date
Duncan P. N. Exon Smith 75cd8d756d Support: Add RedirectingFileSystem::create from simple list of redirections
Add an overload of `RedirectingFileSystem::create` that builds a
redirecting filesystem off of a simple vector of string pairs. This is
intended to be used to support `clang::arcmt::FileRemapper` and
`clang::PreprocessorOptions::RemappedFiles`.

Differential Revision: https://reviews.llvm.org/D91317
2020-12-08 17:53:30 -08:00
Duncan P. N. Exon Smith a22eda548b VFS: Return new file systems as uniquely owned when possible, almost NFC
Uniformly return uniquely-owned filesystems from VFS creation APIs. The
one exception is `getRealFileSystem`, which has a single instance and
needs to be shared.

This is almost NFC, except that it fixes a memory leak in
`vfs::collectVFSFromYAML()`.

Depends on https://reviews.llvm.org/D92888

Differential Revision: https://reviews.llvm.org/D92890
2020-12-08 17:33:46 -08:00
Duncan P. N. Exon Smith 4d8bf870a8 ADT: Remove AlignedCharArrayUnion, NFC
Prep commit already migrated users over to std::aligned_union_t; this
just deletes the type / header / test.

Differential Revision: https://reviews.llvm.org/D92517
2020-12-04 14:13:22 -08:00
Duncan P. N. Exon Smith e763e032f8 Support: Change InMemoryFileSystem::addFileNoOwn to take a MemoryBufferRef, NFC
Found this by chance when looking at the InMemoryFileSystem API, seems
like an easy cleanup.

Differential Revision: https://reviews.llvm.org/D90893
2020-12-03 18:09:52 -08:00
Mehdi Amini 6cd9608fb3 Revert "Switch to std::is_trivially_move_constructible and std::is_trivially_copy_constructible"
This reverts commit c8d406c93c.

Builds are broken with some versions of GCC.
2020-12-03 19:58:06 +00:00
serge-sans-paille 9501419e87 Speedup some unicode rendering
Use a fast path for column width computation for ascii characters. Especially
relevant for llvm-objdump.

before:

    % time ./bin/llvm-objdump -D  -j .text /lib/libc.so.6 >/dev/null
    ./bin/llvm-objdump -D -j .text /lib/libc.so.6 > /dev/null  0.75s user 0.01s system 99% cpu 0.757 total

after:

    % time ./bin/llvm-objdump -D  -j .text /lib/libc.so.6 >/dev/null
    ./bin/llvm-objdump -D -j .text /lib/libc.so.6 > /dev/null  0.37s user 0.01s system 99% cpu 0.378 total

Differential Revision: https://reviews.llvm.org/D92180
2020-12-03 20:11:11 +01:00
Fangrui Song c8d406c93c Switch to std::is_trivially_move_constructible and std::is_trivially_copy_constructible
Differential Revision: https://reviews.llvm.org/D92543
2020-12-03 09:15:40 -08:00
Fangrui Song 1d6ebdfb66 Switch from llvm::is_trivially_copyable to std::is_trivially_copyable
GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.

The Optional.h change made MSVC choke
(https://buildkite.com/llvm-project/premerge-checks/builds/18587#cd1bb616-ffdc-4581-9795-b42c284196de)
so I leave it out for now.

Differential Revision: https://reviews.llvm.org/D92514
2020-12-02 22:02:48 -08:00
Reid Kleckner 91e66bfd32 Revert "Use std::is_trivially_copyable", breaks MSVC build
Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE"

This reverts commit 4d4bd40b57.

This reverts commit 557b00e0af.
2020-12-02 14:30:46 -08:00
Fangrui Song 4d4bd40b57 Use std::is_trivially_copyable
GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1
we can migrate to std::is_trivially_copyable.
2020-12-02 09:58:07 -08:00
LemonBoy f502b14d40 [ARMAttributeParser] Correctly parse and print Tag_THUMB_ISA_use=3
I took the "Permitted"/"Not Permitted" combo from the `Tag_ARM_ISA_use` case (GNU tools print "Yes").

Reviewed By: compnerd, MaskRay, simon_tatham

Differential Revision: https://reviews.llvm.org/D90305
2020-11-28 12:28:22 -08:00
Mark Murray 2b6691894a [ARM][AArch64] Adding Neoverse N2 CPU support
Add support for the Neoverse N2 CPU to the ARM and AArch64 backends.

Differential Revision: https://reviews.llvm.org/D91695
2020-11-25 11:42:54 +00:00
Scott Linder 2980933d85 [YAMLIO] Support non-null-terminated inputs
In some places the parser guards against dereferencing `End`, while in
others it relies on the presence of a trailing `'\0'` to elide checks.

Add the remaining guards needed to ensure the parser never attempts to
dereference `End`, making it safe to not require a null-terminated input
buffer.

Update the parser fuzzer harness so that it tests with buffers that are
guaranteed to be non-null-terminated, null-terminated, and 1-terminated,
additionally ensuring the result of the parse is the same in each case.

Some of the regression tests were written by inspection, and some are
cases caught by the fuzzer which required additional fixes in the
parser.

Differential Revision: https://reviews.llvm.org/D84050
2020-11-18 23:06:03 +00:00
Scott Linder b877c35d4b [YAMLIO] Correctly diagnose empty alias/anchor
The `Range` of an alias/anchor token includes the leading `&` or `*`,
but it is skipped while parsing the name. The check for an empty name
fails to account for the skipped leading character and so the error is
never hit.

Fix the off-by-one and add a couple regression tests.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D91462
2020-11-16 18:45:05 +00:00
Nikita Popov 9a85643cd3 [KnownBits] Combine abs() implementations
ValueTracking was using a more powerful abs() implementation. Roll
it into KnownBits::abs(). Also add an exhaustive test for abs(),
in both the poisoning and non-poisoning variants.
2020-11-13 22:23:50 +01:00
Lucas Prates c2c2cc1360 [ARM][AArch64] Adding Neoverse V1 CPU support
Add support for the Neoverse V1 CPU to the ARM and AArch64 backends.

This is based on patches from Mark Murray and Victor Campos.

Reviewed By: dmgreen

Differential Revision: https://reviews.llvm.org/D90765
2020-11-09 13:15:40 +00:00
Sander de Smalen 5ee9ef8519 [TypeSize] Extend UnivariateLinearPolyBase with getWithIncrement/Decrement methods
This patch adds getWithIncrement/getWithDecrement methods to
ElementCount and TypeSize to allow:

  TypeSize::getFixed(8).getWithIncrement(8)     <=> TypeSize::getFixed(16)
  TypeSize::getFixed(16).getWithDecrement(8)    <=> TypeSize::getFixed(8)
  TypeSize::getScalable(8).getWithIncrement(8)  <=> TypeSize::getScalable(16)
  TypeSize::getScalable(16).getWithDecrement(8) <=> TypeSize::getScalable(8)

This patch implements parts of the POC in D90342.

Reviewed By: ctetreau, dmgreen

Differential Revision: https://reviews.llvm.org/D90713
2020-11-06 09:01:19 +00:00
Reid Kleckner f55247456e Fix bugs in EOL marking in command line tokenizers
Add unit tests for this behavior, since the integration test for
clang-cl did not catch these bugs.

Fixes PR47604

Differential Revision: https://reviews.llvm.org/D90866
2020-11-05 13:01:32 -08:00
Simon Pilgrim 6729b6de1f [KnownBits] Move ValueTracking SREM KnownBits handling to KnownBits::srem. NFCI.
Move the ValueTracking implementation to KnownBits, the SelectionDAG version is more limited so I'm intending to replace that as a separate commit.
2020-11-05 14:58:33 +00:00
Simon Pilgrim e237d56b43 [KnownBits] Move ValueTracking/SelectionDAG UREM KnownBits handling to KnownBits::urem. NFCI.
Both these have the same implementation - so move them to a single KnownBits copy.

GlobalISel will be able to use this as well with minimal effort.
2020-11-05 14:30:59 +00:00
Simon Pilgrim 32bee18b84 [KnownBits] Move ValueTracking/SelectionDAG UDIV KnownBits handling to KnownBits::udiv. NFCI.
Both these have the same implementation - so move them to a single KnownBits copy.

GlobalISel will be able to use this as well with minimal effort.
2020-11-05 13:42:42 +00:00
Simon Pilgrim 6c1a31858d [UnitTests] Add exhaustive tests for KnownBits shl/lshr/ashr
Thanks to @foad for the suggestion.
2020-11-05 10:13:16 +00:00
Hans Wennborg 1d3cd7172b Fix GCC error: specialization of 'template<class LeafTy> struct llvm::LinearPolyBaseTypeTraits' in different namespace 2020-11-03 16:55:32 +01:00
Sander de Smalen 1667d23e58 [NFCI] Add StackOffset class and base classes for ElementCount, TypeSize.
This patch adds a linear polynomial base class, called LinearPolyBase, which
serves as a base class for StackOffset. It tries to represent a linear
polynomial like:

  c0 * scale0 + c1 * scale1 + ... + cK * scaleK

where the scale is implicit, meaning that only the coefficients are
encoded.

This patch also adds a univariate linear polynomial, which serves as
a base class for ElementCount and TypeSize. This tries to represent a
linear polynomial where only one dimension can be set at any one time,
i.e. a TypeSize is either fixed-sized, or scalable-sized, but cannot be
a combination of the two.

  class LinearPolyBase
     ^
     |
     +---- class StackOffset  (dimensions = 2 (fixed/scalable), type = int64_t)

  class UnivariateLinearPolyBase
     |
     |
     +---- class LinearPolySize (dimensions = 2 (fixed/scalable))
                  ^
                  |
                  +-------- class ElementCount  (type = unsigned)
                  |
                  |
                  +-------- class TypeSize      (type = uint64_t)

Reviewed By: ctetreau, david-arm

Differential Revision: https://reviews.llvm.org/D88982
2020-11-03 09:41:39 +00:00
Reid Kleckner c0a922b3db Add parallelTransformReduce and parallelForEachError
parallelTransformReduce is modelled on the C++17 pstl API of
std::transform_reduce, except our wrappers do not use execution policy
parameters.

parallelForEachError allows loops that contain potentially failing
operations to propagate errors out of the loop. This was one of the
major challenges I encountered while parallelizing PDB type merging in
LLD. Parallelizing a loop with parallelForEachError is not behavior
preserving: the loop will no longer stop on the first error, it will
continue working and report all errors it encounters in a list.

I plan to use this to propagate errors out of LLD's
coff::TpiSource::remapTpiWithGHashes, which currently stores errors an
error in the TpiSource object.

Differential Revision: https://reviews.llvm.org/D90639
2020-11-02 16:50:14 -08:00
Duncan P. N. Exon Smith c17da8676a Support: Avoid std::tie in Support/FileSystem/UniqueID.h, NFC
Running `-fsyntax-only` on UniqueID.h is 2x faster with this patch
(which avoids calling `std::tie` for `operator<`).  Since the transitive
includers of this file will go up as `FileEntryRef` gets used in more
places, avoid that compile-time hit.  This is a follow-up to
23ed570af1 (suggested by Reid Kleckner).

Also drop the `<tuple>` include from FileSystem.h (which was vestigal
from before UniqueID.h was split out).

Differential Revision: https://reviews.llvm.org/D90471
2020-11-02 13:26:15 -05:00
Georgii Rymar 6487ffafd1 Reland "[yaml2obj][ELF] - Simplify the code that performs sections validation."
This reverts commit 1b589f4d4d and relands the D89463
with the fix: update `MappingTraits<FileFilter>::validate()` in ClangTidyOptions.cpp to
match the new signature (change the return type to "std::string" from "StringRef").

Original commit message:

This:

Changes the return type of MappingTraits<T>>::validate to std::string
instead of StringRef. It allows to create more complex error messages.

It introduces std::vector<std::pair<StringRef, bool>> getEntries():
a new virtual method of Section, which is the base class for all sections.
It returns names of special section specific keys (e.g. "Entries") and flags that says if them exist in a YAML.
The code in validate() uses this list of entries descriptions to generalize validation.
This approach was discussed in the D89039 thread.

Differential revision: https://reviews.llvm.org/D89463
2020-10-20 16:25:33 +03:00
Georgii Rymar 1b589f4d4d Revert "[yaml2obj][ELF] - Simplify the code that performs sections validation."
This reverts commit b9e2b59680.
2020-10-20 15:16:56 +03:00
Georgii Rymar b9e2b59680 [yaml2obj][ELF] - Simplify the code that performs sections validation.
This:
1) Changes the return type of `MappingTraits<T>>::validate` to `std::string`
instead of `StringRef`. It allows to create more complex error messages.

2) It introduces std::vector<std::pair<StringRef, bool>> getEntries():
a new virtual method of Section, which is the base class for all sections.
It returns names of special section specific keys (e.g. "Entries") and flags that
says if them exist in a YAML. The code in validate() uses this list of entries
descriptions to generalize validation.
This approach was discussed in the D89039 thread.

Differential revision: https://reviews.llvm.org/D89463
2020-10-20 11:28:23 +03:00
Hans Wennborg 95fb3542e8 Disable DynamicLibraryTests when using LLVM_INTEGRATED_CRT_ALLOC (PR47881) 2020-10-16 16:49:58 +02:00
Rainer Orth 3b956a58f3 Reland "[Support][unittests] Enforce alignment in ConvertUTFTest"
This relands commit 53b3873cf4.  The failure
of `ConvertUTFTest.UTF16WrappersForConvertUTF16ToUTF8String` detected the
first time is fixed.

Differential Revision: https://reviews.llvm.org/D88824
2020-10-14 12:02:27 +02:00
Duncan P. N. Exon Smith f2b7d9f7fa Support: Allow use of MemoryBufferRef with line_iterator
Split out from https://reviews.llvm.org/D66782, use `Optional<MemoryBufferRef>`
in `line_iterator` so you don't need access to a `MemoryBuffer*`.  Follow up
patches in `clang/` will leverage this.

Differential Revision: https://reviews.llvm.org/D89280
2020-10-13 16:43:49 -04:00
Duncan P. N. Exon Smith f087597124 Support: Add operator== for MemoryBufferRef and split out MemoryBufferRef.h
As preparation for changing `LineIterator` to work with `MemoryBufferRef`:

- Add an `operator==` that uses buffer pointer identity to ensure two buffers
  are equivalent.
- Split out `MemoryBufferRef.h`, to avoid polluting `LineIterator.h` includers
  with everything from `MemoryBuffer.h`. This also means moving the
  `MemoryBuffer` constructor to a source file.

Differential Revision: https://reviews.llvm.org/D89279
2020-10-13 16:42:24 -04:00
Sam McCall 31a575bbc0 [JSON] Add ObjectMapper::mapOptional to validate optional data.
Currently the idiom for mapping optional fields is:
  ObjectMapper O(Val, P);
  if (!O.map("required1", Out.R1) || !O.map("required2", Out.R2))
    return false;
  O.map("optional1", Out.O1); // ignore result
  return true;

If `optional1` is present but malformed, then we won't detect/report
that error. We may even leave `Out` in an incomplete state while returning true.
Instead, we'd often prefer to ignore `optional1` if it is absent, but otherwise
behave just like map().

Differential Revision: https://reviews.llvm.org/D89128
2020-10-12 12:48:08 +02:00
Quentin Colombet d421e0484a [KnownBits] Add a sextOrTrunc method
We already offer zextOrTrunc and it seems natural to offer the
same capability for sign extension.

This patch is a preparatory addition useful for future computeKnownBits
developments.

Differential Revision: https://reviews.llvm.org/D88937
2020-10-08 11:33:06 -07:00
Quentin Colombet 9431f8ad2e [KnownBits] Add a computeForMul method
This patch refactors the logic in ValueTracking.cpp so that
computeKnownBitsForMul now uses a helper function from KnownBits.

NFC

Differential Revision: https://reviews.llvm.org/D88935
2020-10-08 11:33:06 -07:00
Nico Weber a4961f0d8a Revert "[Support][unittests] Enforce alignment in ConvertUTFTest"
This reverts commit 53b3873cf4.
Seems to break SupportTests.exe's
ConvertUTFTest.UTF16WrappersForConvertUTF16ToUTF8String
on Windows.
2020-10-07 22:23:08 -04:00
Daniel Sanders 91a98ec11e [json] Provide a means to delegate writing a value to another API
(Based on D87170 by dsanders)

I recently had need to call out to an external API to emit a JSON object as part
of one an LLVM tool was emitting. However, our JSON support didn't provide a way
to delegate part of the JSON output to that API.

Add rawValueBegin() and rawValueEnd() to maintain and check the internal state
while something else is writing to the stream. It's the users responsibility to
ensure that the resulting JSON output is still valid.

Differential Revision: https://reviews.llvm.org/D88902
2020-10-07 18:31:45 +02:00
Rainer Orth 53b3873cf4 [Support][unittests] Enforce alignment in ConvertUTFTest
`LLVM-Unit :: Support/./SupportTests/ConvertUTFTest.ConvertUTF16LittleEndianToUTF8String`
`FAIL`s on Solaris/sparcv9:

In `llvm/lib/Support/ConvertUTFWrapper.cpp` (`convertUTF16ToUTF8String`)
the `SrcBytes` arg is reinterpreted/accessed as `UTF16` (`unsigned short`,
which requires 2-byte alignment on strict-alignment targets like Sparc)
without anything guaranteeing the alignment, so the access yields a
`SIGBUS`.

This patch avoids this by enforcing the required alignment in the callers.

Tested on `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D88824
2020-10-07 09:08:41 +02:00
Sjoerd Meijer 8825fec37e [AArch64] Add CPU Cortex-R82
This adds support for -mcpu=cortex-r82. Some more information about this
core can be found here:

https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r82

One note about the system register: that is a bit of a refactoring because of
small differences between v8.4-A AArch64 and v8-R AArch64.

This is based on patches from Mark Murray and Mikhail Maltsev.

Differential Revision: https://reviews.llvm.org/D88660
2020-10-02 12:47:23 +01:00
Mikhail Maltsev 07b7a24e3f [unittests] Preserve LD_LIBRARY_PATH in crash recovery test
We need to preserve the LD_LIBRARY_PATH environment variable when
spawning a child process (certain setups rely on non-standard paths
for e.g. libstdc++). In order to achieve this, set
LLVM_CRC_UNIXCRCRETURNCODE in the parent process instead of creating
the child's environment from scratch.

Reviewed By: aganea

Differential Revision: https://reviews.llvm.org/D88308
2020-09-28 17:46:03 +01:00
Alexandre Ganea a6a6ccfc4c Fix f5314d15af - [Support] On Unix, let the CrashRecoveryContext return the signal code
This was causing bots to fail: http://green.lab.llvm.org/green/job/clang-stage1-RA/14828/consoleFull#6384962949ba4694-19c4-4d7e-bec5-911270d8a58c
2020-09-24 09:07:22 -04:00
Alexandre Ganea f5314d15af [Support] On Unix, let the CrashRecoveryContext return the signal code
Before this patch, the CrashRecoveryContext was returning -2 upon a signal, like ExecuteAndWait does. This didn't match the behavior on Windows, where the the exception code was returned.

We now return the signal's code, which optionally allows for re-throwing the signal later. Doing so requires all custom handlers to be removed first, through llvm::sys::unregisterHandlers() which we made a public API.

This is part of https://reviews.llvm.org/D70378
2020-09-24 08:21:43 -04:00
Alexandre Ganea 24f510570f [Support] On Windows, ensure abort() can be catched several times in a row with CrashRecoveryContext
Before this patch, the CrashRecoveryContext would only catch the first abort(). Any further calls to abort() inside subsquent CrashRecoveryContexts would not be catched. This is because the Windows CRT removes the abort() handler before calling it.

This is part of https://reviews.llvm.org/D70378
2020-09-24 08:21:42 -04:00
Mikael Holmen a1217620a8 [unittests] Use std::make_tuple to make some toolchains happy again
My toolchain stopped working (LLVM 8.0, libstdc++ 5.4.0) after 577adda:

06:25:37 ../unittests/Support/Path.cpp:91:7: error: chosen constructor is explicit in copy-initialization
06:25:37       {"", false, false},  {"/", true, true},      {"/foo", true, true},
06:25:37       ^~~~~~~~~~~~~~~~~~
06:25:37 /proj/flexasic/app/llvm/8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.4.0/../../../../include/c++/5.4.0/tuple:479:19: note: explicit constructor declared here
06:25:37         constexpr tuple(_UElements&&... __elements)
06:25:37                   ^

This commit adds explicit calls to std::make_tuple to work around
the problem.
2020-09-24 11:25:36 +02:00
Sam McCall fa69b60806 [JSON] Add error reporting to fromJSON and ObjectMapper
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".

The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
  bool fromJSON(const Value&, T&, Path);

Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.

I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).

All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.

Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 01:20:09 +02:00
Sam McCall 38de1c33a8 [JSON] Display errors associated with Paths in context
When an error occurs processing a JSON object, seeing the actual
surrounding data helps. Dumping just the node where the problem
was identified can be too much or too little information.

printErrorContext() shows the error message in its context, as a comment.
JSON values along the path to the broken place are shown in some detail,
the rest of the document is elided. For example:

```
{
  "credentials": [
    {
      "username": /* error: expected string */ 42,
      "password": "secret"
    },
    { ... }
  ]
  "backups": { ... }
}
```

Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 00:34:11 +02:00
Sam McCall 16619e7139 [JSON] Facility to track position within an object and report errors.
This error model should be rich enough for most applications. It comprises:

- a name for the root object, so the user knows what we're parsing
- a path from the root object to the JSON node most associated with the error
- a local error message

This can be presented as an llvm::Error e.g.
  "expected string at ConfigFile.credentials[0].username"

It's designed to be cheap: Paths are a linked list of lightweight
objects on the stack. No heap allocations unless errors are encountered.

A subsequent commit will make use of this in the JSON-to-object
translation facilities: fromJSON and ObjectMapper.
However it's independent of these and can be used for e.g. validation alone.

Another subsequent commit will support showing the error in its context
within the parsed value.

Differential Revision: https://reviews.llvm.org/D88103
2020-09-24 00:09:09 +02:00
Sam McCall 140b7b6f09 [JSON] Allow emitting comments in json::OStream
This isn't standard JSON, but is a popular extension.
It will be used to show errors in context, rendering pseudo-json for humans.

Differential Revision: https://reviews.llvm.org/D88103
2020-09-23 23:34:57 +02:00
Vinicius Tinti 577adda54f [Support/Path] Add path::is_absolute_gnu
Implements IS_ABSOLUTE_PATH from GNU tools.

C++17 is_absolute behavior is different the from the behavior defined by GNU
tools.

According to cppreference.com, C++17 states: "An absolute path is a path
that unambiguously identifies the location of a file without reference
to an additional starting location."

In other words, the rules are:
 1. POSIX style paths with nonempty root directory are absolute.
 2. Windows style paths with nonempty root name and root directory are
    absolute.
 3. No other paths are absolute.

GNU rules are:
 1. Paths starting with a path separator are absolute.
 2. Windows style paths are also absolute if they start with a character
    followed by ':'.
 3. No other paths are absolute.

On Windows style the path "C:\Users\Default" has "C:" as root name and "\"
as root directory.

Hence "C:" on Windows is absolute under GNU rules and not absolute under
C++17 because it has no root directory. Likewise "/" and "\" on Windows are
absolute under GNU and are not absolute under C++17 due to empty root name.

Related to PR46368.

Differential Revision: https://reviews.llvm.org/D87667
2020-09-23 18:01:32 +01:00