[swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #477

[no-reply--- via swift-dev]

Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#477] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/477/
  Project:oss-swift-package-osx
  Date of build:Thu, 12 Oct 2017 02:58:17 -0500
  Build duration:2 hr 13 min


Identified problems:Regression test failed: This build failed because a regression test in the test suite FAILed. Below is a list of all errors:Indication 1




  





  Changes
  

  Commit 6e6b6b9837170b08eb90920e0d7f0bb298164015 by dgregor: [Mangler] Only mangle new requirements for constrained extensions.


  edit: test/SILGen/foreach.swift

  edit: lib/AST/ASTMangler.cpp

  edit: test/IRGen/same_type_constraints.swift

  edit: test/SILGen/mangling_generic_extensions.swift

  edit: test/SourceKit/DocSupport/doc_clang_module.swift.response

  edit: test/SILGen/newtype.swift

  edit: lib/Demangling/Demangler.cpp

  edit: test/SourceKit/InterfaceGen/gen_swift_module.swift

  edit: test/SILGen/same_type_abstraction.swift

  edit: test/SourceKit/DocSupport/doc_swift_module.swift.response

  edit: test/SILGen/constrained_extensions.swift

  edit: test/SILGen/objc_bridged_using_protocol_extension_impl.swift

  edit: test/SILOptimizer/prespecialize.swift

  edit: test/SILGen/generic_tuples.swift

  edit: test/SourceKit/DocSupport/doc_swift_module1.swift.response


  
 

  Commit affbd5e4eaf9a603313c53ae97d2ebcdbe0e42f2 by pyaskevich: [AST] Fix function signature mangler to aways respect parens


  edit: lib/AST/ASTMangler.cpp

  edit: test/SILGen/arguments_as_tuple_overloads.swift

  edit: include/swift/AST/ASTMangler.h

  edit: include/swift/AST/Types.h

  edit: docs/ABI/Mangling.rst


  
 

  Commit 24154254b5997c32bc59444352a37a315fec22af by devteam.codafi: Change a literal block to a colon


  edit: docs/DebuggingTheCompiler.rst


  
 

  


 ___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Debugger (lldb or gdb) does not show variable value in swift code

[Sam Ding via swift-dev]

Hi Alex,

Tested the master branch, which has the same behavior as V4.0 branch.
Just wonder how to debug the compiler swift code if the debugger is not
able to show the values.


Thanks,

Sam Ding,
Linux on z Systems  Open Source Ecosystem
IBM Toronto Lab,
email: samd...@ca.ibm.com
phone: (905)413-2947



From:   Alex Blewitt 
To: Sam Ding 
Cc: swift-dev 
Date:   10/07/2017 11:33 AM
Subject:Re: [swift-dev] Debugger (lldb or gdb) does not show variable
value in swift code
Sent by:alb...@apple.com



Do you see the same issue if you build from master?

Alex

  On 7 Oct 2017, at 00:30, Sam Ding via swift-dev 
  wrote:



  Hi,

  I build swift compiler (v4.0) with debug mode ("-d"), however when
  debugging compiler swift code, it can not
  show the variable value. Here is an example:


  frame #0: 0x7761d50c
  libswiftCore.so`_allocateUninitializedArray
  (builtinCount=1) at Arrays.swift:3347
  3344 func _allocateUninitializedArray(_
  builtinCount: Builtin.Word)
  3345 -> (Array, Builtin.RawPointer) {
  3346 let count = Int(builtinCount)
  -> 3347 if count > 0 {
  3348 // Doing the actual buffer allocation outside of the
  array.uninitialized
  3349 // semantics function enables stack propagation of
  the buffer.
  3350 let bufferObject = Builtin.allocWithTailElems_1(
  Target 0: (ww) stopped.
  (lldb) p count
  error: in auto-import:
  failed to get module 'Builtin' from AST context
  (lldb)

  This happens on both x86_64 and s390x platforms.
  Is there any way to make the debugger show the variable values?

  Thanks,

  Sam Ding,
  Linux on z Systems Open Source Ecosystem
  IBM Toronto Lab,
  email: samd...@ca.ibm.com
  phone: (905)413-2947
  ___
  swift-dev mailing list
  swift-dev@swift.org
  https://lists.swift.org/mailman/listinfo/swift-dev


___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Adding a field to StrongRefCount class

[Jiho Choi via swift-dev]

Now I am finally able to build the Swift runtime with an extended object
header and run some benchmarks.  For future reference, in addition to
making changes similar to the commits which Greg pointed to, I needed to
change the Foundation library's CFRuntimeBase class which mirrors the
Swift's object header layout.

On Thu, Sep 28, 2017 at 11:52 PM Greg Parker  wrote:

>
> On Sep 27, 2017, at 10:39 AM, John McCall via swift-dev <
> swift-dev@swift.org> wrote:
>
> On Sep 27, 2017, at 1:24 PM, Jiho Choi  wrote:
>
> Thanks for the explanation.  I modified those two locations you mentioned
> but the build failed during tests.  I've been browsing the source code to
> figure out other dependences but didn't succeed yet.  Could you please give
> me some pointers on where to look at?
>
>
> You'll have to look at the test failures individually.  If they're just
> IRGen tests failing because the IR no longer matches the current output,
> then you need to either fix the tests or just ignore them for the purposes
> of your experiment.  If they're IRGen tests failing because the compiler is
> crashing, or execution tests failing because the running code is crashing,
> it's likely that I just forgot something that depends on the output.  We're
> not going to be able to debug this problem for you in the abstract, though.
>
>
> You should look at pull requests #7837 and #9214:
> https://github.com/apple/swift/pull/7837
> https://github.com/apple/swift/pull/9214
>
> #7837 the object header size on 32-bit architectures. The PR is not
> currently up-to-date, but should give you an idea of the scope of changes
> that would be necessary for your experiment. #9214 is an addition after
> #7837 that would also be affected by a header size change.
>
>
> Another approach for experimental purposes is to modify StrongRefCount
> without changing its size. That struct is designed to store some data
> inline, and if necessary can transform into an out-of-line form that stores
> data of any size.
>
> You could change the arrangement of bits in the StrongRefCount inline form
> if you only need a few bits for your storage.
>
> Or you could force StrongRefCount to always use the out-of-line form and
> store whatever data you want there. This would be slower but probably fine
> for experimentation.
>
>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Jordan Rose via swift-dev]

So, an update! This came up while I was talking to members of the core team, 
and ChrisL felt very strongly that restricting reordering of enum elements was 
a no-go, since it would be the only part of the language that worked this way 
(even if it only mattered for binary frameworks). Ted also rightly pointed out 
that any such language-level restriction would have to be reviewed by the core 
team.

So where does that leave us?

- The naive implementation is to turn a switch into an if-else chain, 
unfortunately requiring one function call per case to match.

- A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' entry 
point (see original email), but exposes symbols for every tag. The values of 
the symbols would be kept in alphabetical order, which allows the generated 
code to do a binary search over the cases they care about. This still means N 
symbols, but a switch that involves several of them doesn't necessarily have to 
take linear time.

- Joe Groff came up with this idea that also involves sorted symbols:

switch indexForMyOpaqueEnumTag(&myOpaqueEnum, [MyOpaqueEnum.intCase, 
MyOpaqueEnum.stringCase]) {
case 0:
  var payload: Int
  getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.intCase, &payload)
  doSomething(payload)
case 1:
  var payload: String
  getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.stringCase, &payload)
  doSomethingElse(payload)
default:
  print("unknown case")
}

In this example, the actual tag values for 'intCase' and 'stringCase' might not 
be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to find out 
which enum we're asking for. Like the previous solution, you only have to check 
the cases you care about, but this time the binary search is in the callee, 
rather than the client.

- Use availability ordering, plus some kind of explicit annotation for when 
multiple cases are added within the same release. (In this thread people have 
suggested dates, ad-hoc sub-version numbers, and plain integer values.)

I appreciate everyone's creativity with solving the availability ordering 
problem, but I don't want to tie us to a checker that will tell you if you 
screw up or a history scraper that will implicitly add the right annotations. 
(I don't think those are bad ideas, but they're a whole extra pile of work on 
top of the main implementation!) That leaves explicit annotations of some kind, 
and that leaves us in a worse place than Objective-C. Which is permitted, but 
not desirable.

 At this point in time I think the second option is the best one we have: it's 
relatively simple to implement, it supports everything Objective-C does, and it 
doesn't make the availability model even more complicated. It is going to be 
less efficient than actually knowing the case numbers at compile time, though. 
Still, as Slava's pointed out, we can still change this after we go ABI-stable; 
doing something more efficient will just be limited based on deployment target.

Jordan

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Greg Titus via swift-dev]

I like Joe’s idea here, with the extension that the client should have just one 
of these arrays that contains all the symbols that it knows about at the time 
it was compiled:

I.e. in the client:

static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, MyOpaqueEnum.middleCase, 
MyOpaqueEnum.stringCase];

switch indexForMyOpaqueEnumTag(&myOpaqueEnum, myKnownOpaqueEnumCases) {
case 0: //…
case 2: //…
default: //...
}

This optimizes for space in the client, because you have one array instead of 
one per potentially-different-sets-of-cases switch, but more importantly this 
allows for an optimization inside indexForMyOpaqueEnumTag(). If the count of 
the array passed in from the client is equal to the count of all known cases in 
the callee, then you can immediately return the internal enum tag value instead 
of performing a binary search.

(If the client expects cases that the callee doesn’t have, the link would have 
failed for a missing symbol, if the callee has more cases the count won’t 
match, so if the count is equal the cases in both object files have to be 
identical.) This returns the common runtime case (when the client is up to date 
with the callee) to being O(1).

The cost being, if you don’t take that fast path, maybe you have a few more 
entries in the cases array to binary search over than that particular switch 
statement needed.

- Greg

> On Oct 12, 2017, at 2:25 PM, Jordan Rose  wrote:
> 
> So, an update! This came up while I was talking to members of the core team, 
> and ChrisL felt very strongly that restricting reordering of enum elements 
> was a no-go, since it would be the only part of the language that worked this 
> way (even if it only mattered for binary frameworks). Ted also rightly 
> pointed out that any such language-level restriction would have to be 
> reviewed by the core team.
> 
> So where does that leave us?
> 
> - The naive implementation is to turn a switch into an if-else chain, 
> unfortunately requiring one function call per case to match.
> 
> - A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' entry 
> point (see original email), but exposes symbols for every tag. The values of 
> the symbols would be kept in alphabetical order, which allows the generated 
> code to do a binary search over the cases they care about. This still means N 
> symbols, but a switch that involves several of them doesn't necessarily have 
> to take linear time.
> 
> - Joe Groff came up with this idea that also involves sorted symbols:
> 
> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, [MyOpaqueEnum.intCase, 
> MyOpaqueEnum.stringCase]) {
> case 0:
>   var payload: Int
>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.intCase, &payload)
>   doSomething(payload)
> case 1:
>   var payload: String
>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.stringCase, &payload)
>   doSomethingElse(payload)
> default:
>   print("unknown case")
> }
> 
> In this example, the actual tag values for 'intCase' and 'stringCase' might 
> not be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to 
> find out which enum we're asking for. Like the previous solution, you only 
> have to check the cases you care about, but this time the binary search is in 
> the callee, rather than the client.
> 
> - Use availability ordering, plus some kind of explicit annotation for when 
> multiple cases are added within the same release. (In this thread people have 
> suggested dates, ad-hoc sub-version numbers, and plain integer values.)
> 
> I appreciate everyone's creativity with solving the availability ordering 
> problem, but I don't want to tie us to a checker that will tell you if you 
> screw up or a history scraper that will implicitly add the right annotations. 
> (I don't think those are bad ideas, but they're a whole extra pile of work on 
> top of the main implementation!) That leaves explicit annotations of some 
> kind, and that leaves us in a worse place than Objective-C. Which is 
> permitted, but not desirable.
> 
>  At this point in time I think the second option is the best one we have: 
> it's relatively simple to implement, it supports everything Objective-C does, 
> and it doesn't make the availability model even more complicated. It is going 
> to be less efficient than actually knowing the case numbers at compile time, 
> though. Still, as Slava's pointed out, we can still change this after we go 
> ABI-stable; doing something more efficient will just be limited based on 
> deployment target.
> 
> Jordan
> 

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (swift 4.0) #438

[no-reply--- via swift-dev]

Title: Report


  
  
 
 

 [FAILURE] oss-swift-4.0-package-osx [#438] 


  Build URL:https://ci.swift.org/job/oss-swift-4.0-package-osx/438/
  Project:oss-swift-4.0-package-osx
  Date of build:Thu, 12 Oct 2017 14:09:41 -0500
  Build duration:3 hr 25 min







  





  Changes
  
	
  No Changes

  


 ___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Jordan Rose via swift-dev]

Our worry when discussing it was that someone might have an autogenerated 
1000-case enum, and passing an entire page worth of resolved symbols might not 
be worth it.

(It is of course questionable for someone to have an autogenerated 1000-case 
enum as part of their binary interface, and then for someone to try to switch 
over it. But matching against one or two of the cases shouldn't be as expensive 
as matching against all 1000 known cases.)

Jordan

> On Oct 12, 2017, at 15:20, Greg Titus  wrote:
> 
> I like Joe’s idea here, with the extension that the client should have just 
> one of these arrays that contains all the symbols that it knows about at the 
> time it was compiled:
> 
> I.e. in the client:
> 
> static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, 
> MyOpaqueEnum.middleCase, MyOpaqueEnum.stringCase];
> 
> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, myKnownOpaqueEnumCases) {
> case 0: //…
> case 2: //…
> default: //...
> }
> 
> This optimizes for space in the client, because you have one array instead of 
> one per potentially-different-sets-of-cases switch, but more importantly this 
> allows for an optimization inside indexForMyOpaqueEnumTag(). If the count of 
> the array passed in from the client is equal to the count of all known cases 
> in the callee, then you can immediately return the internal enum tag value 
> instead of performing a binary search.
> 
> (If the client expects cases that the callee doesn’t have, the link would 
> have failed for a missing symbol, if the callee has more cases the count 
> won’t match, so if the count is equal the cases in both object files have to 
> be identical.) This returns the common runtime case (when the client is up to 
> date with the callee) to being O(1).
> 
> The cost being, if you don’t take that fast path, maybe you have a few more 
> entries in the cases array to binary search over than that particular switch 
> statement needed.
> 
> - Greg
> 
>> On Oct 12, 2017, at 2:25 PM, Jordan Rose > > wrote:
>> 
>> So, an update! This came up while I was talking to members of the core team, 
>> and ChrisL felt very strongly that restricting reordering of enum elements 
>> was a no-go, since it would be the only part of the language that worked 
>> this way (even if it only mattered for binary frameworks). Ted also rightly 
>> pointed out that any such language-level restriction would have to be 
>> reviewed by the core team.
>> 
>> So where does that leave us?
>> 
>> - The naive implementation is to turn a switch into an if-else chain, 
>> unfortunately requiring one function call per case to match.
>> 
>> - A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' entry 
>> point (see original email), but exposes symbols for every tag. The values of 
>> the symbols would be kept in alphabetical order, which allows the generated 
>> code to do a binary search over the cases they care about. This still means 
>> N symbols, but a switch that involves several of them doesn't necessarily 
>> have to take linear time.
>> 
>> - Joe Groff came up with this idea that also involves sorted symbols:
>> 
>> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, [MyOpaqueEnum.intCase, 
>> MyOpaqueEnum.stringCase]) {
>> case 0:
>>   var payload: Int
>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.intCase, &payload)
>>   doSomething(payload)
>> case 1:
>>   var payload: String
>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.stringCase, &payload)
>>   doSomethingElse(payload)
>> default:
>>   print("unknown case")
>> }
>> 
>> In this example, the actual tag values for 'intCase' and 'stringCase' might 
>> not be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to 
>> find out which enum we're asking for. Like the previous solution, you only 
>> have to check the cases you care about, but this time the binary search is 
>> in the callee, rather than the client.
>> 
>> - Use availability ordering, plus some kind of explicit annotation for when 
>> multiple cases are added within the same release. (In this thread people 
>> have suggested dates, ad-hoc sub-version numbers, and plain integer values.)
>> 
>> I appreciate everyone's creativity with solving the availability ordering 
>> problem, but I don't want to tie us to a checker that will tell you if you 
>> screw up or a history scraper that will implicitly add the right 
>> annotations. (I don't think those are bad ideas, but they're a whole extra 
>> pile of work on top of the main implementation!) That leaves explicit 
>> annotations of some kind, and that leaves us in a worse place than 
>> Objective-C. Which is permitted, but not desirable.
>> 
>>  At this point in time I think the second option is the best one we have: 
>> it's relatively simple to implement, it supports everything Objective-C 
>> does, and it doesn't make the availability model even more complicated. It 
>> is going to be less efficient than actually knowing the case num

Re: [swift-dev] What can you change in a non-exhaustive enum?

[David Zarzycki via swift-dev]

Hi Jordan,

Bertrand (ex-Apple) would sometimes say during API design that “easy things 
things should be easy, and hard things should be possible”.

I don’t think you guys need to go out of your way to make the autogenerated 
1000-case enum scenario “easy". If people are clever enough to do that, then 
they can surely handle the fallout of this change. :-)

Dave


> On Oct 12, 2017, at 18:38, Jordan Rose via swift-dev  
> wrote:
> 
> Our worry when discussing it was that someone might have an autogenerated 
> 1000-case enum, and passing an entire page worth of resolved symbols might 
> not be worth it.
> 
> (It is of course questionable for someone to have an autogenerated 1000-case 
> enum as part of their binary interface, and then for someone to try to switch 
> over it. But matching against one or two of the cases shouldn't be as 
> expensive as matching against all 1000 known cases.)
> 
> Jordan
> 
>> On Oct 12, 2017, at 15:20, Greg Titus > > wrote:
>> 
>> I like Joe’s idea here, with the extension that the client should have just 
>> one of these arrays that contains all the symbols that it knows about at the 
>> time it was compiled:
>> 
>> I.e. in the client:
>> 
>> static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, 
>> MyOpaqueEnum.middleCase, MyOpaqueEnum.stringCase];
>> 
>> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, myKnownOpaqueEnumCases) {
>> case 0: //…
>> case 2: //…
>> default: //...
>> }
>> 
>> This optimizes for space in the client, because you have one array instead 
>> of one per potentially-different-sets-of-cases switch, but more importantly 
>> this allows for an optimization inside indexForMyOpaqueEnumTag(). If the 
>> count of the array passed in from the client is equal to the count of all 
>> known cases in the callee, then you can immediately return the internal enum 
>> tag value instead of performing a binary search.
>> 
>> (If the client expects cases that the callee doesn’t have, the link would 
>> have failed for a missing symbol, if the callee has more cases the count 
>> won’t match, so if the count is equal the cases in both object files have to 
>> be identical.) This returns the common runtime case (when the client is up 
>> to date with the callee) to being O(1).
>> 
>> The cost being, if you don’t take that fast path, maybe you have a few more 
>> entries in the cases array to binary search over than that particular switch 
>> statement needed.
>> 
>> - Greg
>> 
>>> On Oct 12, 2017, at 2:25 PM, Jordan Rose >> > wrote:
>>> 
>>> So, an update! This came up while I was talking to members of the core 
>>> team, and ChrisL felt very strongly that restricting reordering of enum 
>>> elements was a no-go, since it would be the only part of the language that 
>>> worked this way (even if it only mattered for binary frameworks). Ted also 
>>> rightly pointed out that any such language-level restriction would have to 
>>> be reviewed by the core team.
>>> 
>>> So where does that leave us?
>>> 
>>> - The naive implementation is to turn a switch into an if-else chain, 
>>> unfortunately requiring one function call per case to match.
>>> 
>>> - A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' 
>>> entry point (see original email), but exposes symbols for every tag. The 
>>> values of the symbols would be kept in alphabetical order, which allows the 
>>> generated code to do a binary search over the cases they care about. This 
>>> still means N symbols, but a switch that involves several of them doesn't 
>>> necessarily have to take linear time.
>>> 
>>> - Joe Groff came up with this idea that also involves sorted symbols:
>>> 
>>> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, [MyOpaqueEnum.intCase, 
>>> MyOpaqueEnum.stringCase]) {
>>> case 0:
>>>   var payload: Int
>>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.intCase, &payload)
>>>   doSomething(payload)
>>> case 1:
>>>   var payload: String
>>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.stringCase, &payload)
>>>   doSomethingElse(payload)
>>> default:
>>>   print("unknown case")
>>> }
>>> 
>>> In this example, the actual tag values for 'intCase' and 'stringCase' might 
>>> not be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to 
>>> find out which enum we're asking for. Like the previous solution, you only 
>>> have to check the cases you care about, but this time the binary search is 
>>> in the callee, rather than the client.
>>> 
>>> - Use availability ordering, plus some kind of explicit annotation for when 
>>> multiple cases are added within the same release. (In this thread people 
>>> have suggested dates, ad-hoc sub-version numbers, and plain integer values.)
>>> 
>>> I appreciate everyone's creativity with solving the availability ordering 
>>> problem, but I don't want to tie us to a checker that will tell you if you 
>>> screw up or a history scraper that will implicitly add the right 
>>> ann

Re: [swift-dev] What can you change in a non-exhaustive enum?

[Greg Titus via swift-dev]

The nice thing about this setup is that it degrades nicely for the 1000-case 
enum. You have a static check in the compiler for if theNumberOfKnownEnumCases 
>= SOME_REASONABLE_MAX (or — in the future — as complicated a decision as you 
want given the number of total cases and the number of cases you care about in 
that particular switch) then you pass in an array of just the switched against 
cases instead, and the implementation of indexForMyOpaqueEnumTag() remains 
exactly the same in the callee (the early out matching count fails, and you 
binary search).

- Greg

> On Oct 12, 2017, at 3:38 PM, Jordan Rose  wrote:
> 
> Our worry when discussing it was that someone might have an autogenerated 
> 1000-case enum, and passing an entire page worth of resolved symbols might 
> not be worth it.
> 
> (It is of course questionable for someone to have an autogenerated 1000-case 
> enum as part of their binary interface, and then for someone to try to switch 
> over it. But matching against one or two of the cases shouldn't be as 
> expensive as matching against all 1000 known cases.)
> 
> Jordan
> 
>> On Oct 12, 2017, at 15:20, Greg Titus > > wrote:
>> 
>> I like Joe’s idea here, with the extension that the client should have just 
>> one of these arrays that contains all the symbols that it knows about at the 
>> time it was compiled:
>> 
>> I.e. in the client:
>> 
>> static myKnownOpaqueEnumCases = [MyOpaqueEnum.intCase, 
>> MyOpaqueEnum.middleCase, MyOpaqueEnum.stringCase];
>> 
>> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, myKnownOpaqueEnumCases) {
>> case 0: //…
>> case 2: //…
>> default: //...
>> }
>> 
>> This optimizes for space in the client, because you have one array instead 
>> of one per potentially-different-sets-of-cases switch, but more importantly 
>> this allows for an optimization inside indexForMyOpaqueEnumTag(). If the 
>> count of the array passed in from the client is equal to the count of all 
>> known cases in the callee, then you can immediately return the internal enum 
>> tag value instead of performing a binary search.
>> 
>> (If the client expects cases that the callee doesn’t have, the link would 
>> have failed for a missing symbol, if the callee has more cases the count 
>> won’t match, so if the count is equal the cases in both object files have to 
>> be identical.) This returns the common runtime case (when the client is up 
>> to date with the callee) to being O(1).
>> 
>> The cost being, if you don’t take that fast path, maybe you have a few more 
>> entries in the cases array to binary search over than that particular switch 
>> statement needed.
>> 
>> - Greg
>> 
>>> On Oct 12, 2017, at 2:25 PM, Jordan Rose >> > wrote:
>>> 
>>> So, an update! This came up while I was talking to members of the core 
>>> team, and ChrisL felt very strongly that restricting reordering of enum 
>>> elements was a no-go, since it would be the only part of the language that 
>>> worked this way (even if it only mattered for binary frameworks). Ted also 
>>> rightly pointed out that any such language-level restriction would have to 
>>> be reviewed by the core team.
>>> 
>>> So where does that leave us?
>>> 
>>> - The naive implementation is to turn a switch into an if-else chain, 
>>> unfortunately requiring one function call per case to match.
>>> 
>>> - A slightly more complex solution keeps a single 'getMyOpaqueEnumTag' 
>>> entry point (see original email), but exposes symbols for every tag. The 
>>> values of the symbols would be kept in alphabetical order, which allows the 
>>> generated code to do a binary search over the cases they care about. This 
>>> still means N symbols, but a switch that involves several of them doesn't 
>>> necessarily have to take linear time.
>>> 
>>> - Joe Groff came up with this idea that also involves sorted symbols:
>>> 
>>> switch indexForMyOpaqueEnumTag(&myOpaqueEnum, [MyOpaqueEnum.intCase, 
>>> MyOpaqueEnum.stringCase]) {
>>> case 0:
>>>   var payload: Int
>>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.intCase, &payload)
>>>   doSomething(payload)
>>> case 1:
>>>   var payload: String
>>>   getMyOpaqueEnumPayload(&myOpaqueEnum, MyOpaqueEnum.stringCase, &payload)
>>>   doSomethingElse(payload)
>>> default:
>>>   print("unknown case")
>>> }
>>> 
>>> In this example, the actual tag values for 'intCase' and 'stringCase' might 
>>> not be 0 and 1, but 'indexForMyOpaqueEnumTag' can do the binary search to 
>>> find out which enum we're asking for. Like the previous solution, you only 
>>> have to check the cases you care about, but this time the binary search is 
>>> in the callee, rather than the client.
>>> 
>>> - Use availability ordering, plus some kind of explicit annotation for when 
>>> multiple cases are added within the same release. (In this thread people 
>>> have suggested dates, ad-hoc sub-version numbers, and plain integer values.)
>>> 
>>> I appreciate everyone's creativity with 

[swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #482

[no-reply--- via swift-dev]

Title: Report


  
  
 
 

 [FAILURE] oss-swift-package-osx [#482] 


  Build URL:https://ci.swift.org/job/oss-swift-package-osx/482/
  Project:oss-swift-package-osx
  Date of build:Thu, 12 Oct 2017 20:14:50 -0500
  Build duration:55 min


Identified problems:Compile Error: This build failed because of a compile error. Below is a list of all errors in the build log:Indication 1




  





  Changes
  

  Commit b5492518ae3ccee9abf75bb8f3b2439435d67247 by moiseev: [benchmark] Add LazilyFilteredArrayContains benchmark


  edit: benchmark/single-source/LazyFilter.swift


  
 

  Commit b5ca50619f807d8270c33c6aa797ff918e8cd07b by practicalswift: [swiftc (67 vs. 5600)] Add crasher in


  add: validation-test/compiler_crashers/28861-gpdecl-getdepth-generictypeparamdecl-invaliddepth-parameter-hasnt-been-validated.swift


  
 

  Commit cd3c63cbfd06338bbe3241297cb32e1594928ec9 by dgregor: [AST] Stop including GenericSignature.h in other headers.


  edit: lib/AST/GenericEnvironment.cpp

  edit: lib/SILOptimizer/Utils/Local.cpp

  edit: lib/Sema/CSRanking.cpp

  edit: include/swift/SIL/AbstractionPattern.h

  edit: lib/Serialization/DeserializeSIL.cpp

  edit: lib/SILOptimizer/SILCombiner/SILCombinerApplyVisitors.cpp

  edit: lib/AST/SILLayout.cpp

  edit: lib/SILGen/SILGenGlobalVariable.cpp

  edit: include/swift/AST/SILLayout.h

  edit: lib/AST/Decl.cpp

  edit: lib/RemoteAST/RemoteAST.cpp

  edit: lib/SILGen/SILGenBuilder.cpp

  edit: tools/swift-ide-test/ModuleAPIDiff.cpp

  edit: lib/SILOptimizer/Transforms/ReleaseDevirtualizer.cpp

  edit: include/swift/AST/ASTMangler.h

  edit: tools/SourceKit/lib/SwiftLang/SwiftDocSupport.cpp

  edit: lib/SILGen/SILGenApply.cpp

  edit: include/swift/AST/NameLookup.h

  edit: lib/Serialization/SerializeSIL.cpp

  edit: lib/Sema/CSApply.cpp

  edit: include/swift/AST/GenericEnvironment.h

  edit: include/swift/AST/Decl.h

  edit: lib/IDE/CodeCompletion.cpp

  edit: lib/IRGen/GenDecl.cpp

  edit: lib/IDE/IDETypeChecking.cpp

  edit: lib/SIL/AbstractionPattern.cpp

  edit: lib/SILOptimizer/Utils/Devirtualize.cpp

  edit: lib/SILOptimizer/Utils/SpecializationMangler.cpp

  edit: lib/AST/ConcreteDeclRef.cpp

  edit: lib/SILGen/SILGenDestructor.cpp


  
 

  Commit 6db9cc8c544327933e2bfcb7ff2cd9c80221f390 by dgregor: [AST] Consolidate the generic signature "diff" algorithm used in two


  edit: lib/AST/ASTMangler.cpp

  edit: include/swift/AST/GenericSignature.h

  edit: lib/AST/GenericSignature.cpp

  edit: lib/AST/ProtocolConformance.cpp


  
 

  Commit c6ff6b0142f7254b36125ecb396d8574c142fc36 by moiseev: Extract setup and teardown stages for a benchmnark


  edit: benchmark/single-source/LazyFilter.swift


  
 

  Commit b5f20334ab45e9f3943ca10ac93075e83665f955 by github: [docs] LibraryEvolution: Tweak for Swift 4.0. (#11742)


  edit: docs/LibraryEvolution.rst


  
 

  Commit c5cff769c72e9a723f4a60068c8ba792b203e914 by pyaskevich: [IRGen] Update Function Metadata to use AnyFunctionType::Param


  edit: lib/IRGen/GenMeta.cpp

  edit: test/IRGen/objc_block.sil

  edit: lib/RemoteAST/RemoteAST.cpp

  edit: stdlib/public/runtime/Metadata.cpp

  edit: docs/ABI/TypeMetadata.rst

  edit: test/Interpreter/function_metatypes.swift

  edit: test/IRGen/function_metadata.swift

  add: test/IRGen/dynamic_cast_functions.swift

  edit: stdlib/public/runtime/Demangle.cpp

  edit: test/IRGen/c_function_pointer.sil


  
 

  Commit bdafb354bdcefcc68f3725ea575980a5184e0d1d by shajrawi: SILCombiner: fix an infinite loop corner-case


  edit: test/SILOptimizer/sil_combine_apply.sil

  edit: lib/SILOptimizer/SILCombiner/SILCombinerApplyVisitors.cpp


  
 

  


 ___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev