Fix lldb build with -DLLVM_ENABLE_MODULES=On

[llunak]

Summary

I'm not actually sure if this is the proper fix, but without this the build fails on openSUSE 15.2 x86_64 with:

[2/274] Building CXX object tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/UriParser.cpp.o
FAILED: tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/UriParser.cpp.o 
/home/seli/build/src/llvm/lldb/source/Utility/UriParser.cpp:59:5: error: declaration of 'uint16_t' must be imported from module 'lldb_Utility.Flags' before it is required
    uint16_t port_value = 0;
    ^
/usr/include/bits/stdint-uintn.h:25:20: note: previous declaration is here
typedef __uint16_t uint16_t;
                   ^
1 error generated.
[4/274] Building CXX object tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TildeExpressionResolver.cpp.o
FAILED: tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TildeExpressionResolver.cpp.o 
In file included from /home/seli/build/src/llvm/lldb/source/Utility/TildeExpressionResolver.cpp:21:
/usr/include/pwd.h:93:34: error: unknown type name 'FILE'; did you mean 'std::FILE'?
extern struct passwd *fgetpwent (FILE *__stream) __nonnull ((1));
                                 ^
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../include/c++/9/cstdio:98:11: note: 'std::FILE' declared here
  using ::FILE;
          ^
1 error generated.

[dblaikie]

Including <cstdint> is probably more correct - the clang warning points to the Flags module as one module that defines the typedef, but because this is probably being tested against an unmodularized standard library, the module chosen is somewhat arbitrary/not directly relevant to the issue (it's just one module that itself happens to include <cstdint> or some other standard header that pulls in a definition of uint16_t )

[llunak]

In D85090#2189549, @dblaikie wrote:

Including <cstdint> is probably more correct - the clang warning points to the Flags module as one module that defines the typedef, but because this is probably being tested against an unmodularized standard library, the module chosen is somewhat arbitrary/not directly relevant to the issue (it's just one module that itself happens to include <cstdint> or some other standard header that pulls in a definition of uint16_t )

That makes sense, but that doesn't actually change anything. UriParser.cpp even has stdint.h already there, changing it to cstdint doesn't make a difference. So this looks like a Clang bug. But it doesn't happen with git Clang, so it's been presumably fixed. Good enough for me, closing.

lldb/source/Utility/TildeExpressionResolver.cpp

 
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/raw_ostream.h"
 
 #if !defined(_WIN32)
+#include "lldb/Utility/FileSpec.h"
 #include <pwd.h>
 #endif
 
 using namespace lldb_private;
 using namespace llvm;
 
 namespace fs = llvm::sys::fs;
 namespace path = llvm::sys::path;

lldb/source/Utility/UriParser.cpp

 //===-- UriParser.cpp -----------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "lldb/Utility/UriParser.h"
+#include "lldb/Utility/Flags.h"
 
 #include <string>
 
 #include <stdint.h>
 #include <tuple>
 
 using namespace lldb_private;