Merge apple/swift master (at 1302539a) #11
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When we encode a string into an APInt the size of the APInt needs to be large enough for the string (we got this part right), but also large enough for arithmetic with the value of character length.
This reverts commit f4ccef2.
…ing strings. The bug is that zext expects the bitwidth to be different, which is incorrect since the bitwidth does not change most of the times.
[SILOptimizer]Refactor ObjC dependencies in CSE tests
[Stdlib] Optimize CollectionType.first
…ation of the dyld callbacks. This more cleanly groups together the initialization steps needed to warm up the conformance cache, so redundant work doesn't need to be done by other interested parties (such as the type-by-name lookup @lhoward's working on).
…egers. Previously we were manipulating APInts every time we went down a level on the huffman tree. This commit changes the search to use uint64_t. We copy the last few bits of the APInt into the uint64_t and manipulate that value, which is much much faster because we don't need to copy the APInt (which is typically a few hundred bits long). The uint64_t can't overflow because it is not possible to encode ascii in a huffman tree and use sequences that are 64bits long.
This commit optimizes the code that inserts bits into a bitstream (APInt). Instead of adding the bits one by one we calculate the size we need, shift the APInt and add the numeric value representing the bitstream.
Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented as Pattern's (of a particular sort), stemming from an early design direction that was abandoned. Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns have to have varargs and default parameters) and make working on parameter lists complicated and error prone. This might have been ok in 2015, but there is no way we can live like this in 2016. Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the parameter specific stuff. This simplifies many things and allows a lot of simplifications. Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good news is that it erases a ton of code, and the technical debt that went with it. Ignoring test suite changes, we have: 77 files changed, 2359 insertions(+), 3221 deletions(-) This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on patches. Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75. Fixes an overloading bug involving default arguments and curried functions (see the diff to Constraints/diagnostics.swift, which we now correctly accept). Fixes cases where problems with parameters would get emitted multiple times, e.g. in the test/Parse/subscripting.swift testcase. The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests (for the better, I think). Eliminates the bogus "type annotation missing in pattern" error message when a type isn't specified for a parameter (see test/decl/func/functions.swift). This now consistently parenthesizes argument lists in function types, which leads to many diffs in the SILGen tests among others. This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and I haven't been able to figure it out. Given that this is experimental functionality anyway, I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
…60101 [Python] Remove unused imports and unused local variables
Update copyright date
the Pattern::clone interface now that the complexity isn't needed. This also removes support for serializing this state.
This is important for scriptability of this script.
It is always null, NFC.
…ys false now, NFC.
it is dead now. NFC.
We used to build the type for a parameter types and then relabeling them from the DeclName. Now we build the ParameterList and use that to construct the DeclName. Since we get the parameter list type from the same ParameterList, it is always properly labeled. NFC.
… 'StripOuterSliceType' parameter.
… null, saving a word. NFC. We should also eliminate the isOldSyntax as well, and just do the error recovery in the parser (there is no need to retain the sugar here anymore), but I'll do that as a separate change since it could be behavior changing.
1. Array type parsing for postfix array types Int[]. We now handle this in the parser, but remove the AST representation of this old form. We also stop making vague promises about the future by saying that "fixed size arrays aren't supported... yet". Removal of this fixes a compiler crasher too. 2. Remove the special case support for migrating @autoclosure from types to parameters, which was Swift 1.0/1.1 syntax. The world has moved or we don't care anymore. 3. Remove upgrade support for # arguments (nee "backtick" arguments), which was a Swift 1.x'ism abolished in an effort to simplify method naming rules. NFC on valid code.
These are no longer needed by the corelibs.
This is useful when building LLDB configurations from Xcode that require the Swift sources to be inside the LLDB tree. While we still recommend checking out LLDB as a peer of llvm, clang, and swift, and using build-script to automate the overall build, this allows LLDB to be built from Xcode in the same way that it is in llvm.org.
A protocol conformance needs to know what declarations satisfy requirements; these are called "witnesses". For a value (non-type) witness, this takes the form of a ConcreteDeclRef, i.e. a ValueDecl plus any generic specialization. (Think Array<Int> rather than Array<T>, but for a function.) This information is necessary to compile the conformance, but it causes problems when the conformance is used from other modules. In particular, the type used in a specialization might itself be a generic type in the form of an ArchetypeType. ArchetypeTypes can't be meaningfully used outside their original context, however, so this is a weird thing to have to deal with. (I'm not going to go into when a generic parameter is represented by an ArchetypeType vs. a GenericTypeParamType, partially because I don't think I can explain it well myself.) The above issue becomes a problem when we go to use the conformance from another module. If module C uses a conformance from module B that has a generic witness from module A, it'll think that the archetypes in the specialization for the witness belong in module B. Which is just wrong. It turns out, however, that no code is using the full specializations for witnesses except for when the conformance is being compiled and emitted. So this commit sidesteps the problem by just not serializing the specializations that go with the ConcreteDeclRef for a value witness. This doesn't fix the underlying issue, so we should probably still see if we can either get archetypes from other contexts out of value witness ConcreteDeclRefs, or come up with reasonable rules for when they're okay to use. rdar://problem/23892955
Implement support for @objc(name) on enum cases. Changelog update coming next.
Add CHANGELOG.md entry about @objc(Name) on enums and enum cases.
Fills in Chris's placeholder in feace85. I'm not quite sure why a private subscript doesn't produce a non-cascading dependency right now, but this is at least conservatively correct. (For more infomation on dependencies, check out "Dependency Analysis.rst".)
…cies. Noticed by inspection (!). This logic could use some before/after fuzzing.
No functionality change.
…mments. This should make it less confusing to figure out what this preset is for, and what configuration it requires.
Having a separate address and container value returned from alloc_stack is not really needed in SIL. Even if they differ we have both addresses available during IRGen, because a dealloc_stack is always dominated by the corresponding alloc_stack in the same function. Although this commit quite large, most changes are trivial. The largest non-trivial change is in IRGenSIL. This commit is a NFC regarding the generated code. Even the generated SIL is the same (except removed #0, #1 and @local_storage).
Reflecting the change that alloc_stack now returns a single value. NFC.
They are not used anymore as alloc_stack now returns a single value.
severe problems with the implementation thereof.
The big differences here are that:
1. We no longer use the 4096 trick.
2. Now we store all indices inline so no mallocing is required and the
value is trivially copyable. We allow for much larger indices to be
stored inline which makes having an unrepresentable index a much smaller
issue. For instance on a 32 bit platform, in NewProjection, we are able
to represent an index of up to (1 << 26) - 1, which should be more than
enough to handle any interesting case.
3. We can now have up to 7 ptr cases and many more index cases (with each extra
bit needed to represent the index cases lowering the representable range of
indices).
The whole data structure is much simpler and easier to understand as a
bonus. A high level description of the ADT is as follows:
1. A PointerIntEnum for which bits [0, (num_tagged_bits(T*)-1)] are not all
set to 1 represent an enum with a pointer case. This means that one can have
at most ((1 << num_tagged_bits(T*)) - 2) enum cases associated with
pointers.
2. A PointerIntEnum for which bits [0, (num_tagged_bits(T*)-1)] are all set
is either an invalid PointerIntEnum or an index.
3. A PointerIntEnum with all bits set is an invalid PointerIntEnum.
4. A PointerIntEnum for which bits [0, (num_tagged_bits(T*)-1)] are all set
but for which the upper bits are not all set is an index enum. The case bits
for the index PointerIntEnum are stored in bits [num_tagged_bits(T*),
num_tagged_bits(T*) + num_index_case_bits]. Then the actual index is stored
in the remaining top bits. For the case in which this is used in swift
currently, we use 3 index bits meaning that on a 32 bit system we have 26
bits for representing indices meaning we can represent indices up to
67_108_862. Any index larger than that will result in an invalid
PointerIntEnum. On 64 bit we have many more bits than that.
By using this representation, we can make PointerIntEnum a true value type
that is trivially constructable and destructable without needing to malloc
memory.
In order for all of this to work, the user of this needs to construct an
enum with the appropriate case structure that allows the data structure to
determine what cases are pointer and which are indices. For instance the one
used by Projection in swift is:
enum class NewProjectionKind : unsigned {
// PointerProjectionKinds
Upcast = 0,
RefCast = 1,
BitwiseCast = 2,
FirstPointerKind = Upcast,
LastPointerKind = BitwiseCast,
// This needs to be set to ((1 << num_tagged_bits(T*)) - 1). It
// represents the first NonPointerKind.
FirstIndexKind = 7,
// Index Projection Kinds
Struct = PointerIntEnumIndexKindValue<0, EnumTy>::value,
Tuple = PointerIntEnumIndexKindValue<1, EnumTy>::value,
Index = PointerIntEnumIndexKindValue<2, EnumTy>::value,
Class = PointerIntEnumIndexKindValue<3, EnumTy>::value,
Enum = PointerIntEnumIndexKindValue<4, EnumTy>::value,
LastIndexKind = Enum,
};
[gardening] Consistently use normal quotes ("…") instead of curly quotes (“…”)
[gardening] Fix recently introduced typos
Looks like subclassing classes with resiliently-sized properties works, as long as the subclass is @_fixed_layout, so let's ensure that's tested. We don't want @_fixed_layout classes to be a thing though, and we still can't handle changes to the number of stored properties in a base class, so a couple of tests are disabled until I land some more patches.
Many of the conflicts stemmed from FreeBSD support, added in swiftlang#203. Conflicts: - CMakeLists.txt - cmake/modules/AddSwift.cmake - lib/Basic/LangOptions.cpp - lib/Driver/ToolChains.cpp - stdlib/public/Glibc/CMakeLists.txt - stdlib/public/core/CMakeLists.txt - stdlib/public/runtime/CMakeLists.txt - stdlib/public/runtime/Casting.cpp - stdlib/public/stubs/CMakeLists.txt - stdlib/public/stubs/LibcShims.cpp - stdlib/public/stubs/Stubs.cpp - test/CMakeLists.txt - utils/build-script-impl
…ebase-swiftandroid-onto-trunk-20160107
|
Thanks! I'm probably going to do a rebase instead of a merge though (keeps the revision history neater). I'm going to add you to the GitHub organization if you want to do the rebase/git push --force yourself. |
|
@zhuowei That would be great!! I'd love to contribute--I want upstream Swift to support cross-compilation and I think this fork is the most efficient way to work towards that goal. I'd also like to add the following instructions to the wiki, if you don't mind: BuildingYou must have all the build prerequisites for Swift installed.
The icu-related steps are necessary because Android doesn't ship with libicu, which is used by Swift. |
|
@modocache I sent you an invitation. Swift already supports cross compilation from OS X->iOS . This just takes advantage of that support. For more interesting cross compilation I think we need to wait for the Swift Package Manager to mature. Right now we cross-compile the stdlib through CMake in the toolchain build, through a shim for packages, and with patches to the driver for manual command line builds. With the package manager everything could be cross compiled with the same tool. I think I set the Wiki to be editable for anyone, so go ahead! For building, I always needed an extra step: create a symlink from arm-linux-androideabi-ld.bfd to /usr/bin/armv7-none-linux-androideabi-ld. I'm not sure if that's still needed in the current source though. |
|
Closed in favor of #12. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pulls in apple/swift as of swiftlang@1302539a. Many of the conflicts stemmed from FreeBSD support, added in swiftlang#203.
Conflicts:
I have tested and confirmed that
swiftc-android hello.swift && swift-android-push hellowork, but have not tested the swiftpm/Gradle integration.