New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added libUUID to Glibc module map #3095
Conversation
# Conflicts: # stdlib/public/Glibc/module.map
Its a dependency for Foundation and already a dependency for the Swift Compiler. Also part of Linux and POSIX.
Considering uuid is already a dependency for Swift, this seems like a good addition. |
@@ -389,5 +389,10 @@ module SwiftGlibc [system] { | |||
header "${GLIBC_INCLUDE_PATH}/utime.h" | |||
export * | |||
} | |||
module uuid { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation is 2 spaces.
Could you explain how apple/swift-corelibs-foundation#417 depends on this PR? I looked at it, and the diff only includes some naming changes and a test as far as I see. |
@gribozavr There is currently no way to import this POSIX library without the Swift Package Manager. While this works fine for third party code, the new As you can read here https://bugs.swift.org/browse/SR-1756 there is no defined way to import this library in Swift right now (SwiftPM). I believe this would solve that problem. Maybe it does not belong in Glibc, but it should be able to me importable in playgrounds and such without a third party module. |
@@ -389,5 +389,10 @@ module SwiftGlibc [system] { | |||
header "${GLIBC_INCLUDE_PATH}/utime.h" | |||
export * | |||
} | |||
module uuid { | |||
header "{GLIBC_INCLUDE_PATH}/uuid/uuid.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing a dollar sign here.
@colemancda Could you move the header into |
@colemancda Could you also squash the history to remove the unimportant merges? |
Sure, give me a min.
|
|
Same file would be fine. |
Gonna squash commits now. Please check that the module map is acceptable. |
@colemancda Indentation should be 2 spaces. Would you mind also adding a simple test to make sure the module map continues working going forward? |
Ok, fixed the indentation, gonna add a test. Where would be ideal for me to put it in? |
|
@gribozavr Added the validation test, could you check it please. Once you think everything is good I'll squash the commits. |
fixed indentation for CUUID module map Added validation test for CUUID
Added test cases for expected-errors and validating that suggested fix works.
The rules for 'fileprivate' (the old 'private') and the rules for the new "scoped" 'private' are the same.
LD_LIBRARY_PATH is one of the few environment variables the LLVM 'lit' tool /doesn't/ strip out, presumably because on some Linux systems it's necessary to run some of the built products being tested. However, the Swift driver also uses LD_LIBRARY_PATH when providing -L options to the script interpreter on Linux. Weaken some of our tests when there's an LD_LIBRARY_PATH in the environment. (There are similar environment variables on OS X, but we don't have to do anything special there because lit /does/ strip those out. This is presumably okay because all of LLVM's load-time dependencies on OS X are in standard system locations.) https://bugs.swift.org/browse/SR-813
gold only supports ELF. This adds two new helper functions (is_windows_based_sdk and is_elfish_sdk) to ensure that we dont try to use gold on non-ELF targets. This comes up when trying to setup cross-compilation for the standard library for Windows. The ELF check is implemented as the negation of Darwin (which uses MachO) and Windows (which uses COFF). The reason for this is that there are additional targets which also use ELF. Rather than enumerating the larger set, enumerate the smaller set (windows) and use the negation.
So that we can easily invoke manual testing: cmake --build ${SWIFT_BUILD_DIR} -- upload-stdlib-{variant} python ${LLVM_SOURCE_DIR}/utils/lit/lit.py -sv ${TEST_PATH}
These functions are not XPC-specific and can be treated as part of the common implementation.
…r::resolveTypeInContext(…) Add crash case with stack trace: ``` swift: /path/to/swift/lib/Sema/TypeCheckType.cpp:404: swift::Type swift::TypeChecker::resolveTypeInContext(swift::TypeDecl *, swift::DeclContext *, TypeResolutionOptions, bool, swift::GenericTypeResolver *, UnsatisfiedDependency *): Assertion `incomplete && "Should have found type by now"' failed. 8 swift 0x0000000000f0d7f3 swift::TypeChecker::resolveTypeInContext(swift::TypeDecl*, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, bool, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 2851 12 swift 0x0000000000f0e65e swift::TypeChecker::resolveIdentifierType(swift::DeclContext*, swift::IdentTypeRepr*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, bool, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 158 14 swift 0x0000000000f0f5a4 swift::TypeChecker::resolveType(swift::TypeRepr*, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 164 15 swift 0x0000000000f0e550 swift::TypeChecker::validateType(swift::TypeLoc&, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 192 16 swift 0x0000000000fd3e1f swift::IterativeTypeChecker::processResolveInheritedClauseEntry(std::pair<llvm::PointerUnion<swift::TypeDecl*, swift::ExtensionDecl*>, unsigned int>, llvm::function_ref<bool (swift::TypeCheckRequest)>) + 159 17 swift 0x0000000000fac54d swift::IterativeTypeChecker::satisfy(swift::TypeCheckRequest) + 493 18 swift 0x0000000000e99489 swift::TypeChecker::resolveInheritanceClause(llvm::PointerUnion<swift::TypeDecl*, swift::ExtensionDecl*>) + 137 19 swift 0x0000000000e9c22f swift::TypeChecker::validateDecl(swift::ValueDecl*, bool) + 1183 23 swift 0x0000000000f0e65e swift::TypeChecker::resolveIdentifierType(swift::DeclContext*, swift::IdentTypeRepr*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, bool, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 158 25 swift 0x0000000000f0f5a4 swift::TypeChecker::resolveType(swift::TypeRepr*, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 164 26 swift 0x0000000000f0e550 swift::TypeChecker::validateType(swift::TypeLoc&, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver*, llvm::function_ref<bool (swift::TypeCheckRequest)>*) + 192 27 swift 0x0000000000ee1237 swift::TypeChecker::typeCheckPattern(swift::Pattern*, swift::DeclContext*, swift::OptionSet<swift::TypeResolutionFlags, unsigned int>, swift::GenericTypeResolver*) + 967 30 swift 0x0000000000ea1586 swift::TypeChecker::typeCheckDecl(swift::Decl*, bool) + 150 33 swift 0x0000000000f0738a swift::TypeChecker::typeCheckFunctionBodyUntil(swift::FuncDecl*, swift::SourceLoc) + 346 34 swift 0x0000000000f071ee swift::TypeChecker::typeCheckAbstractFunctionBodyUntil(swift::AbstractFunctionDecl*, swift::SourceLoc) + 46 35 swift 0x0000000000f07db3 swift::TypeChecker::typeCheckAbstractFunctionBody(swift::AbstractFunctionDecl*) + 179 37 swift 0x0000000000ec3831 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) + 1281 38 swift 0x0000000000c59299 swift::CompilerInstance::performSema() + 3289 40 swift 0x00000000007d72b9 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2857 41 swift 0x00000000007a32c8 main + 2872 Stack dump: 0. Program arguments: /path/to/swift/bin/swift -frontend -c -primary-file validation-test/compiler_crashers/28322-swift-typechecker-resolvetypeincontext.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -module-name main -o /tmp/28322-swift-typechecker-resolvetypeincontext-f548db.o 1. While type-checking 'a' at validation-test/compiler_crashers/28322-swift-typechecker-resolvetypeincontext.swift:10:21 2. While type-checking declaration 0x6499750 at validation-test/compiler_crashers/28322-swift-typechecker-resolvetypeincontext.swift:10:28 3. While resolving type A at [validation-test/compiler_crashers/28322-swift-typechecker-resolvetypeincontext.swift:10:32 - line:10:32] RangeText="A" 4. While resolving type A at [validation-test/compiler_crashers/28322-swift-typechecker-resolvetypeincontext.swift:10:62 - line:10:62] RangeText="A" <unknown>:0: error: unable to execute command: Aborted <unknown>:0: error: compile command failed due to signal (use -v to see invocation) ```
Python's builtin set uses intersection not intersect.
usage: utils/run-test --build-dir <build_dir> <path_to_test> [<path_to_test> ...]
llvm/Support/Compiler.h recently grew a dependency on llvm-config.h. This pointed out that we were not including the path to the generated header directory in the build output. Ensure that we have the corresponding -I.
…development environments This is just a work-around for the underlying importer failure tracked by <rdar://problem/26921178>
Cleaner version at #3107 |
Its a dependency for Foundation and already a dependency for the Swift
Compiler. Also part of Linux and POSIX.
Necessary for https://bugs.swift.org/browse/SR-1756 and SE-0069