Skip to content
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

Closed
wants to merge 26 commits into from
Closed

Conversation

colemancda
Copy link
Contributor

@colemancda colemancda commented Jun 21, 2016

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

# 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.
@hpux735
Copy link
Contributor

hpux735 commented Jun 21, 2016

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 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is 2 spaces.

@gribozavr
Copy link
Collaborator

uuid.h is a part of the uuid library, not glibc, so it would not be correct to put it into the glibc module.

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.

@colemancda
Copy link
Contributor Author

colemancda commented Jun 21, 2016

@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 struct UUID value type in Swift 3.0 Foundation requires this C library, as you can see with the version already released for Darwin in https://github.com/apple/swift/blob/d68c6dcd6b4be19cff9f6e82e2811884de56b6fa/stdlib/public/SDK/Foundation/UUID.swift

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"
Copy link
Contributor

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.

@gribozavr
Copy link
Collaborator

@colemancda Could you move the header into module CUUID [system] {?

@gribozavr
Copy link
Collaborator

@colemancda Could you also squash the history to remove the unimportant merges?

@colemancda
Copy link
Contributor Author

Sure, give me a min.

Coleman,

On Jun 21, 2016, at 11:20 AM, Dmitri Gribenko notifications@github.com wrote:

@colemancda https://github.com/colemancda Could you move the header into module CUUID [system] {?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3095 (comment), or mute the thread https://github.com/notifications/unsubscribe/ADQudpeTN9jvkdzhXXK5VmU4KIxHB0-hks5qOA9ZgaJpZM4I6S1L.

@colemancda
Copy link
Contributor Author

colemancda commented Jun 21, 2016

@colemancda Could you move the header into module CUUID [system] {?
@gribozavr Same file in Glibc? Or another module map?

@gribozavr
Copy link
Collaborator

Same file would be fine.

@colemancda
Copy link
Contributor Author

Gonna squash commits now. Please check that the module map is acceptable.

@gribozavr
Copy link
Collaborator

@colemancda Indentation should be 2 spaces.

Would you mind also adding a simple test to make sure the module map continues working going forward?

@colemancda
Copy link
Contributor Author

Ok, fixed the indentation, gonna add a test. Where would be ideal for me to put it in?

@gribozavr
Copy link
Collaborator

validation-test/stdlib/CUUID.swift I think would be fine.

@colemancda
Copy link
Contributor Author

@gribozavr Added the validation test, could you check it please. Once you think everything is good I'll squash the commits.

colemancda and others added 7 commits June 21, 2016 12:42
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}
briancroom and others added 12 commits June 21, 2016 12:43
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>
@colemancda colemancda closed this Jun 21, 2016
@colemancda colemancda deleted the master branch June 21, 2016 18:07
@colemancda
Copy link
Contributor Author

Cleaner version at #3107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet