hamzasood added inline comments.
================
Comment at: CMakeLists.txt:550
+endif()
add_compile_flags_if_supported(
+ -Wextra -W -Wwrite-strings
----------------
EricWF wrote:
> Couldn't we keep the "-Wall" here? And just add something else that adds
> "/W4"?
>
> Also, we don't yet support building with MSVC's frontend. Only clang-cl. Does
> clang-cl not like this existing code?
The `-Wall` flag gets converted to `-Weverything` by Clang-CL; I don’t think we
should keep it (it causes thousands of warnings per header).
`/W4` is the equivalent flag on Windows.
================
Comment at: include/filesystem:1396
- _LIBCPP_FUNC_VIS
void __create_what(int __num_paths);
----------------
EricWF wrote:
> hamzasood wrote:
> > compnerd wrote:
> > > This possibly changes the meaning on other targets. What was the error
> > > that this triggered?
> > I've re-uploaded the patch with full context to make this clearer.
> >
> > That's a member function on an exported type, which I don't think should
> > have any visibility attributes. The specific issue in this case is that
> > both the class type and the member function are marked as dllimport, which
> > causes a compilation error.
> Perhaps part of the problem here is that filesystem builds to a static
> library, not a shared one.
>
> None the less, this macro is important once we move the definitions from
> libc++fs.a to libc++.so.
I don’t think member functions are meant to have function visibility, and I
wasn’t able to find any other such cases in libc++. That’ll always be a hard
error on Windows because a dllimport class can’t have dllimport member
functions.
================
Comment at: test/support/test_macros.h:147
-# elif defined(_WIN32)
-# if defined(_MSC_VER) && !defined(__MINGW32__)
-# define TEST_HAS_C11_FEATURES // Using Microsoft's C Runtime library
----------------
EricWF wrote:
> hamzasood wrote:
> > hamzasood wrote:
> > > STL_MSFT wrote:
> > > > compnerd wrote:
> > > > > I think that the condition here is inverted, and should be enabled
> > > > > for MinGW32.
> > > > What error prompted this? It hasn't caused problems when running
> > > > libc++'s tests against MSVC's STL (with both C1XX and Clang).
> > > The comment above this says that it's copied from `__config`, but they
> > > must've gone out of sync at some point because `__config` doesn't have
> > > that extra section that I deleted.
> > >
> > > This causes lots of errors when testing libc++. E.g. libc++ isn't
> > > declaring `std::timespec` on Windows because `_LIBCPP_HAS_C11_FEATURES`
> > > isn't defined, but the tests think that it's available so they try to use
> > > it (which causes compilation failures in lots of tests).
> > >
> > > The better solution here might be to update `__config` to match this, but
> > > I'm not familiar with some of those platforms so this seemed like the
> > > safest approach for now.
> > This is a workaround for a libc++ issue rather than an MSVC one. See the
> > response to @compnerd for the full details.
>
> What tests are failing?
Any test that requires `TEST_HAS_C11_FEATURES` or `TEST_HAS_TIMESPEC_GET`.
Those test macros aren’t in sync with the corresponding `__config` ones.
================
Comment at: utils/libcxx/test/config.py:518
self.cxx.compile_flags += ['-DNOMINMAX']
+ # Disable auto-linking; the library is linked manually when
+ # configuring the linker flags.
----------------
EricWF wrote:
> I think the correct fix here is to disabling linking libc++ when auto linking
> is enabled by the headers. Because we want to test that the auto link pragmas
> work.
In that case, it might be worth adding separate auto-linking tests that
specifically use Clang-CL. Making it work here would involve defining `_DLL`
for dynamic builds, but I’m not sure if that would interfere with the CRT.
https://reviews.llvm.org/D51868
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
