Re: [swift-dev] Potential contributions to compilation time reporting?

[Graydon Hoare via swift-dev]

> On Nov 12, 2017, at 8:30 AM, Brian Gesiak via swift-dev  
> wrote:
> 
> Hello all!
> 
> I'm looking for a body of work to do on the Swift compiler for an upcoming 
> programmer retreat I'm attending in January [1]. I've read a lot of blog 
> posts with tips for diagnosing slow Swift compile times [2], and I was 
> wondering if I could contribute to tooling in this area.

Hey, this is great! Sorry I didn't get back to you earlier. Happy to talk this 
over.

> (Just to make it clear: I'm talking about improving and expanding the set of 
> tools developers have to figure out why their projects take a long time to 
> compile. I'm *not* talking about working on speeding Swift compile times -- 
> although the tools may indirectly help with that.)

This seems plausible to me; though like others, I'm a bit hesitant too. There 
are often _many_ things going on in a given compilation, and one needs to be 
careful surfacing any particular signal as a putative "singular cause" of a 
slow compilation, since the user may see that signal and respond by making 
significant adjustments to their code, only to find the overall time isn't 
helped much. But I totally get the motive.

> Using these options, developers can find function bodies and expressions that 
> took longer to compile than others.

Sadly, there's not always a 1:1 mapping between source entities and time like 
that. Certainly _some_ cases can be so egregious (say, typechecking time on an 
expression that's triggering an exponential-time inference) that they dominate 
compile time, and can be identified-and-fixed in isolation; but often the total 
amount of work attributable to a given source entity is spread around the 
compilation, occurs in multiple phases, emerges out of interaction between 
entities, overlaps with others, etc.

That's not to say that one couldn't build machinery to do a better job 
attributing costs to source entities than what we have now; just that it'll be 
a bit of work to get there from here. Maybe fun work! I'd be happy to discuss 
more :)

> However, it should be noted that, of these options, only the first is a 
> user-facing "supported" option. The others are `swift -frontend` options, and 
> as such the Swift team has been clear that this means the options may be 
> changed or removed at any point in the future [3].

Yeah, there are a few good reasons for being careful which options get 
surfaced; but I generally agree with you that _some_ at least partly-supported 
ones would be nice. IMO it's easiest and most flexible to aim to _export_ 
information out of the compiler in a machine-readable form, so you can 
post-process with other tools. I've mostly been using json and csv in recent 
efforts (eg. see -stats-output-dir or -trace-stats-events). But I don't have an 
especially strong feeling about the degree-of-support / stability of such 
features; I'm going to have to leave that part of your question to others.

> What's more, several contributors have noted the behavior of the options 
> themselves could also be improved. Here's what I gathered from reading 
> several JIRA bugs, commit messages, and mailing list discussions:
> 
> - SR-2910  points out that 
> `-debug-time-function-bodies` prints just `get {}` and `set {}` for struct 
> getters and setters, and that this could be improved by printing the variable 
> name as well.
> - The commit that added `-warn-long-function-message=` notes in its commit 
> message 
> 
>  that the option only measures some aspects of type-checking, that it doesn't 
> provide any information on how checking a function for the first time will 
> take longer, doesn't report on other phases of compilation, and doesn't catch 
> anything being type-checked multiple times.

Yes, this latter comment is the part I'm most concerned about. I think if 
you're going to go this way -- providing a diagnostic mode that assigns costs 
to source-entities rather than compiler subsystems -- the difficult/interesting 
parts will be (a) making sure you capture enough of the costs of compilation to 
approximate "total time" meaningfully and (b) making sure you attribute 
"causes" meaningfully. The latter is really quite tricky since a lot of the 
compiler's work is lazy / demand-driven: the first time some (lazy and 
memoized) work is demanded, it's tempting to attribute the cost of the work to 
the entity first requesting it. But if a dozen other entities also demand that 
work gets done (reusing it, whichever requests it first) then the attribution 
will be ... unhelpful to the user trying to change their code to avoid the cost.

> I'd like to solicit ideas for future work here:
> 
> - At the very least, I could fix SR-2910 
> .
> - I'd also like to address some of the issues mentioned in this commit 
> message 
> 

Re: [swift-dev] Highlighting other platforms for Swift?

[Atul Sowani via swift-dev]

Hi,
 
I have kind of ported swift to ppc64le (a few minor issues to straighten out) and would like to help in this initiative. I can help maintain swift on ppc64le, setting up CI for ppc64le etc. Please let me know if there is anything I can help with regarding ppc64le.
 
Thanks,
Atul.
 
- Original message -From: Ian Partridge via swift-dev Sent by: swift-dev-boun...@swift.orgTo: Ted Kremenek Cc: swift-dev Subject: Re: [swift-dev] Highlighting other platforms for Swift?Date: Thu, Nov 16, 2017 4:11 PM 
On 15 November 2017 at 19:35, Ted Kremenek via swift-dev wrote:> We’re actively setting up support to wire in up externally hosted CI bots to our CI infrastructure so that the community can help support the bringup and testing of Swift on other platforms beyond the officially supported platforms.  The tentative rollout for that was December.  We’ll announce more details once we get closer to rollout.This sounds great. IBM has ported Swift to platforms including IBMSystem z (mainframe) and it would be good to get CI integration sothat we can run "@swift-ci please test s390" when wanted.Linking to releases and nightly builds from swift.org would also begood, where they are available.> That said, do you have specific ideas on how such efforts should be highlighted on swift.org, and what should be the optics?Python has a main https://urldefense.proofpoint.com/v2/url?u=https-3A__www.python.org_downloads_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=C93T4wpRFh1gzYCb57TLiUY8G4s-x4fx8sAByOU1AVQ=2LCMaX4K5RQtNBLpL0QqBgSXNksQ0YIewgCM7UlAZDs=5lKrFYs6SoXZC7wnLVq6a9PQRVxlxc9xirybqvmiyis= page and aseparate https://urldefense.proofpoint.com/v2/url?u=https-3A__www.python.org_download_other_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=C93T4wpRFh1gzYCb57TLiUY8G4s-x4fx8sAByOU1AVQ=2LCMaX4K5RQtNBLpL0QqBgSXNksQ0YIewgCM7UlAZDs=uLcXKHSpjWX9PyNQGq7QUTLrxcYWK56Qv37TZjCXOa8= page to point users atnon-official ports. That model could work well for Swift too.--Ian Partridge___swift-dev mailing listswift-dev@swift.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=C93T4wpRFh1gzYCb57TLiUY8G4s-x4fx8sAByOU1AVQ=2LCMaX4K5RQtNBLpL0QqBgSXNksQ0YIewgCM7UlAZDs=MnlrPVF7Zw0AF1ZxuDr3Wbs8BpceeaYVjFRXGMdRwnU= 
 

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

[swift-dev] Ongoing work related to compilation performance

[Graydon Hoare via swift-dev]

Hi,

This is just an update on some work that's been ongoing in the past several 
months related to tracking and improving Swift compilation performance. I've 
been helping coordinate some of that work: documenting what's known about 
compilation performance patterns and diagnostic machinery, increasing 
visibility and process controls around compilation performance, and also 
helping making some changes directly to the compiler.

I wanted to post here to make sure everyone's aware of what's currently going 
on, as well as solicit feedback on priorities and ways to help others 
interested in the topic.

Here's a bit of an overview of recent activities:


Compilation-performance documentation
=

There's a somewhat lengthy document I wrote up during the summer that explains 
what's currently known about how compilation performance varies in the Swift 
compiler, what the causes of that variation (and existing cost centers) are, 
how things are known to sometimes go wrong, which compiler options exist to 
help understand the compiler's behaviour, and which auxiliary tools, scripts 
and processes can help diagnose and improve compilation performance.

It's stored in the repository 
(https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md) and 
I'll be trying to keep it up to date as things change, but it's a good initial 
orientation read when approaching the topic.


Pull request (PR) compilation-performance testing
=

More interactively: a new form of PR testing (documented in 
https://github.com/apple/swift/blob/master/docs/ContinuousIntegration.md#testing-compiler-performance)
 has been added in recent months that committers can trigger with:

  @swift-ci please smoke test compiler performance

or

  @swift-ci please test compiler performance

The latter takes quite a long time, and if you are just curious to see if a 
change helps or hurts compilation performance, the former is usually totally 
adequate.

Output from these commands looks like this:

  https://github.com/apple/swift/pull/12843#issuecomment-345042338

And it displays a summary of output binary-size and compile-time changes 
between your pull request and the branch you're committing to, as well as 
changes to a set of compiler statistics tracking interesting causes of work.

These CI-level reports are based on compiling and measuring the source 
compatibility testsuite (kept at 
https://github.com/apple/swift-source-compat-suite). The "smoke" CI test, which 
is usually sufficiently representative to catch regressions, measures counters 
and timers for 3 projects in the source compatibility suite (currently 
Alamofire, Kingfisher and ReactiveCocoa); the "full" test measures the whole 
suite.


Measurements in general
===

The measurements taken by the CI tests above are emitted by the compiler using 
a mode introduced earlier in the year: -stats-output-dir. Briefly: this mode 
emits a collection of .json files summarizing all available statistics and 
timers in a given compiler (the exact set changes depending on whether the 
compiler is built with asserts). One .json file is written per frontend or 
driver process in a compilation, so this permits post-execution analysis by a 
variety of tools. One such tool (swift/utils/process-stats-dir.py, see 
https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md#post-processing-tools-for-diagnostics)
 is usable both for batch analysis (the CI job uses it) or manually for 
interpreting the performance impact of a change on a developer's workstation. 
It is also, of course, usable in regression tests; a handful of tests now 
directly measure performance counters using it.


Scale testing
=

In addition to testing the absolute values of counters in the compiler, there's 
a bit of test infrastructure that uses those counters in a more abstract way, 
called "scale tests" (driven by utils/scale-test.py). This approach measures 
the relationship between linear changes to the scale of a synthetic input (say: 
increases to the number of classes in a project) and changes to the amount of 
work different counters in the compiler do. This is explained in more detail in 
https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md#scale-test,
 but briefly: this allows writing tests that are insensitive to the exact 
values of counters, but that check that counters have certain desirable 
relationships (eg. linear or sub-linear) to the scale of inputs, rather than 
undesirable relationships (quadratic or worse).


Reducing quadratic costs


One area of work that the scale-tests have highlighted are those parts of early 
semantic-analysis that work on "all declarations in a module", and that thereby 
risk doing work that's quadratic in the number of files, when running a debug 
build. The compiler was designed to avoid this sort of 

[swift-corelibs-dev] Better integration with UNIX tools

[Abhi Beckert via swift-corelibs-dev]

Swift is a great shell scripting language except for it's lack of any
API to execute UNIX commands. Compare these two shell scripts:
> #!/usr/bin/php
>  
> $files = `find ~/Desktop -name *.png`;
> 
> foreach (explode("\n", $files) as $file) {
>   // do something with $file
> }

-

> #!/usr/bin/swift
> 
> import Foundation
> 
> let process = Process()
> process.launchPath = "/usr/bin/find"
> process.arguments = [
>   NSString(string:"~/Desktop").expandingTildeInPath,
>   "-name",
>   "*.png"
> ]
> 
> let output = Pipe()
> process.standardOutput = output
> 
> process.launch()
> 
> let files: String
> if let filesUtf8 = NSString(data:
> output.fileHandleForReading.readDataToEndOfFile(), encoding:
> String.Encoding.utf8.rawValue) {>   files = filesUtf8 as String
> } else {
>   files = NSString(data:
>   output.fileHandleForReading.readDataToEndOfFile(), encoding:
>   String.Encoding.isoLatin1.rawValue) as NSString! as String> }
> 
> files.enumerateLines { file, _ in
>   // do something with file
> }

It's a contrived example, I could have used NSFileManager, but I
run into this all the time integrating with more complex tools
such as rsync.
Adding my own high level wrapper around the Process command isn't an
option since there is no good way to import code from another file when
executing swift asa shell script. All your code needs to be in one file.
- Abhi
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

[Brandon Williams via swift-corelibs-dev]

Oops, sorry, hit send too early!

The docker file Im using can be seen here:

https://github.com/pointfreeco/swift-web/blob/bb-travis/Dockerfile

Which is this template:

https://github.com/swiftdocker/docker-swift/blob/5c83628d4696bca62aec3136a4ee9b854e8d548e/4.0/Dockerfile

So not using any of the betas...

On Thu, Nov 16, 2017 at 5:45 PM Brandon Williams  wrote:

> Ah, sorry for now providing more info!
>
> So the docker file that I am using to run the tests can be see here:
>
>
>
> On Thu, Nov 16, 2017 at 5:43 PM Philippe Hausler 
> wrote:
>
>> Is this with a recent build? Do you know what commit the
>> swift-corelibs-foundation is from? That might help nail down what is going
>> on here.
>>
>> On Nov 16, 2017, at 2:41 PM, Brandon Williams via swift-corelibs-dev <
>> swift-corelibs-dev@swift.org> wrote:
>>
>> Hello! I have a test case that when run on Linux somehow encounters
>> the "Constant strings cannot be deallocated” fatal error thrown in
>> NSCFString.swift, as seen here:
>>
>>
>> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118
>>
>> The test that does it is here:
>>
>>
>> https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93
>>
>> Now there’s a lot to unravel here and I haven’t been able to quite
>> isolate it, but I thought perhaps someone here might know how that could
>> path could even be executed.
>>
>> Thanks for any help!
>>
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>
>>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

[Brandon Williams via swift-corelibs-dev]

Ah, sorry for now providing more info!

So the docker file that I am using to run the tests can be see here:



On Thu, Nov 16, 2017 at 5:43 PM Philippe Hausler  wrote:

> Is this with a recent build? Do you know what commit the
> swift-corelibs-foundation is from? That might help nail down what is going
> on here.
>
> On Nov 16, 2017, at 2:41 PM, Brandon Williams via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Hello! I have a test case that when run on Linux somehow encounters
> the "Constant strings cannot be deallocated” fatal error thrown in
> NSCFString.swift, as seen here:
>
>
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118
>
> The test that does it is here:
>
>
> https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93
>
> Now there’s a lot to unravel here and I haven’t been able to quite isolate
> it, but I thought perhaps someone here might know how that could path could
> even be executed.
>
> Thanks for any help!
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

[Philippe Hausler via swift-corelibs-dev]

Is this with a recent build? Do you know what commit the 
swift-corelibs-foundation is from? That might help nail down what is going on 
here.

> On Nov 16, 2017, at 2:41 PM, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> Hello! I have a test case that when run on Linux somehow encounters the 
> "Constant strings cannot be deallocated” fatal error thrown in 
> NSCFString.swift, as seen here:
> 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118
>  
> 
> 
> The test that does it is here:
> 
> https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93
>  
> 
> 
> Now there’s a lot to unravel here and I haven’t been able to quite isolate 
> it, but I thought perhaps someone here might know how that could path could 
> even be executed.
> 
> Thanks for any help!
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

[swift-corelibs-dev] Encountering "Constant strings cannot be deallocated"

[Brandon Williams via swift-corelibs-dev]

Hello! I have a test case that when run on Linux somehow encounters
the "Constant strings cannot be deallocated” fatal error thrown in
NSCFString.swift, as seen here:

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118

The test that does it is here:

https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93

Now there’s a lot to unravel here and I haven’t been able to quite isolate
it, but I thought perhaps someone here might know how that could path could
even be executed.

Thanks for any help!
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] PropertyListDecoder/Encoder?

[Luke Howard via swift-corelibs-dev]

https://github.com/apple/swift-corelibs-foundation/pull/1237

May/may not be useful - unfortunately couldn’t get it working on Linux so had 
to close.

Sent from my iPhone

> On 16 Nov 2017, at 21:18, Kevin Lundberg via swift-corelibs-dev 
>  wrote:
> 
> Thank you! I found this shortly before your message, and I’m working on that 
> right now in my project (and it is definitely not a simple copy paste but so 
> far it seems manageable).
> --
> Kevin Lundberg
> 
> 
> 
>> On Nov 16, 2017, at 4:12 PM, Ian Partridge  wrote:
>> 
>> Hi Kevin,
>> 
>> It's unintentional, in the sense that noone has done the work yet to
>> implement the PropertyListDecoder in corelibs-foundation.
>> 
>> However, the Darwin implementation is actually open source - see
>> https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/PlistEncoder.swift
>> - so we should be able to reuse that code. It might not be a straight
>> copy and paste, but the bulk of the work is ready and done...
>> 
>> PRs welcome!
>> 
>> Thanks,
>> Ian
>> 
>> On 16 November 2017 at 20:54, Kevin Lundberg via swift-corelibs-dev
>>  wrote:
>>> I’m trying to port some mac/iOS swift code over to also compile and run on 
>>> linux. However one of the files I’m working with references 
>>> PropertyListDecoder in order to decode some propertylist data we have in 
>>> our library, and it’s failing to compile since PropertyListDecoder doesn’t 
>>> appear to be implemented in the corelibs-foundation project. Is this an 
>>> oversight, or intentional? Are there any workarounds I can do (short of 
>>> re-encoding our data in JSON which i’d prefer not to do) to get access to 
>>> property list decoding on linux?
>>> 
>>> Thanks!
>>> 
>>> --
>>> Kevin Lundberg
>>> 
>>> 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> 
>> 
>> -- 
>> Ian Partridge
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] PropertyListDecoder/Encoder?

[Kevin Lundberg via swift-corelibs-dev]

Thank you! I found this shortly before your message, and I’m working on that 
right now in my project (and it is definitely not a simple copy paste but so 
far it seems manageable).
--
Kevin Lundberg



> On Nov 16, 2017, at 4:12 PM, Ian Partridge  wrote:
> 
> Hi Kevin,
> 
> It's unintentional, in the sense that noone has done the work yet to
> implement the PropertyListDecoder in corelibs-foundation.
> 
> However, the Darwin implementation is actually open source - see
> https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/PlistEncoder.swift
> - so we should be able to reuse that code. It might not be a straight
> copy and paste, but the bulk of the work is ready and done...
> 
> PRs welcome!
> 
> Thanks,
> Ian
> 
> On 16 November 2017 at 20:54, Kevin Lundberg via swift-corelibs-dev
>  wrote:
>> I’m trying to port some mac/iOS swift code over to also compile and run on 
>> linux. However one of the files I’m working with references 
>> PropertyListDecoder in order to decode some propertylist data we have in our 
>> library, and it’s failing to compile since PropertyListDecoder doesn’t 
>> appear to be implemented in the corelibs-foundation project. Is this an 
>> oversight, or intentional? Are there any workarounds I can do (short of 
>> re-encoding our data in JSON which i’d prefer not to do) to get access to 
>> property list decoding on linux?
>> 
>> Thanks!
>> 
>> --
>> Kevin Lundberg
>> 
>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> 
> 
> -- 
> Ian Partridge

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

Re: [swift-corelibs-dev] PropertyListDecoder/Encoder?

[Ian Partridge via swift-corelibs-dev]

Hi Kevin,

It's unintentional, in the sense that noone has done the work yet to
implement the PropertyListDecoder in corelibs-foundation.

However, the Darwin implementation is actually open source - see
https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/PlistEncoder.swift
- so we should be able to reuse that code. It might not be a straight
copy and paste, but the bulk of the work is ready and done...

PRs welcome!

Thanks,
Ian

On 16 November 2017 at 20:54, Kevin Lundberg via swift-corelibs-dev
 wrote:
> I’m trying to port some mac/iOS swift code over to also compile and run on 
> linux. However one of the files I’m working with references 
> PropertyListDecoder in order to decode some propertylist data we have in our 
> library, and it’s failing to compile since PropertyListDecoder doesn’t appear 
> to be implemented in the corelibs-foundation project. Is this an oversight, 
> or intentional? Are there any workarounds I can do (short of re-encoding our 
> data in JSON which i’d prefer not to do) to get access to property list 
> decoding on linux?
>
> Thanks!
>
> --
> Kevin Lundberg
>
>
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev



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

[swift-corelibs-dev] PropertyListDecoder/Encoder?

[Kevin Lundberg via swift-corelibs-dev]

I’m trying to port some mac/iOS swift code over to also compile and run on 
linux. However one of the files I’m working with references PropertyListDecoder 
in order to decode some propertylist data we have in our library, and it’s 
failing to compile since PropertyListDecoder doesn’t appear to be implemented 
in the corelibs-foundation project. Is this an oversight, or intentional? Are 
there any workarounds I can do (short of re-encoding our data in JSON which i’d 
prefer not to do) to get access to property list decoding on linux?

Thanks!

--
Kevin Lundberg



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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 3:30 PM, Ian Partridge  wrote:
> 
>> Is the Foundation test suite run against both implementations to attempt to 
>> catch these kinds of things?
>> If not it would seem like a big win to do so.
> 
> Not yet, but there is work underway to do this.  See
> https://github.com/apple/swift-corelibs-foundation/pull/1286 which
> adds an Xcode project to enable just that.  The goal is to get this
> into CI so that we automatically run the SCLF testsuite against both
> implementations.

Fantastic! That’s the information I was looking for, thanks!

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Ian Partridge via swift-corelibs-dev]

On 16 November 2017 at 17:41, Stephen Celis  wrote:
> Brandon Williams and I have come across a lot of inconsistencies between 
> Foundations in our Swift web work. We’ve been trying to file bugs when we 
> remember to, but I’m curious if there’s a better way to catch these.

Please continue to file bugs!  Even better, open a PR with a fix and a
testcase :-)

> Is the Foundation test suite run against both implementations to attempt to 
> catch these kinds of things?
> If not it would seem like a big win to do so.

Not yet, but there is work underway to do this.  See
https://github.com/apple/swift-corelibs-foundation/pull/1286 which
adds an Xcode project to enable just that.  The goal is to get this
into CI so that we automatically run the SCLF testsuite against both
implementations.

> If so, I suppose we could help by beefing up the test coverage?

That would be fantastic, we always need more tests.  We cannot build
confidence in the SCLF implementation without a robust testsuite that
passes against both implementations (thinks Java TCK...)

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 2:57 PM, Alex Blewitt  wrote:
> 
> I understood your question, but I can only point to you as to what is 
> available and run on the swift-corelibs-foundation open source project.

Sorry to continue on this train (especially since it’s a big of a derailment). 
I’m really not trying to be obtuse, but I don’t understand your answer. I was 
asking what I thought were simple yes/no questions that didn’t require any 
private/confidential information about the closed source code. Do you or does 
anyone else know if the open-source project has a test target that runs its 
test suite against the closed-source implementation? If not, shouldn’t it?

I read your first response as: swift-corelibs-foundation has a test suite that 
runs against its own implementation. Am I missing something?

> Yes, being consistent between platforms is one of the purposes of the 
> swift-corelibs-foundation project. However, there are both run-time and 
> implementation differences between the two platforms; the existence (or not) 
> of the Objective-C runtime, whether or not comparisons are performed using 
> the rules based on the Darwin version of Foundation or the ICU rules on the 
> open-source version of Foundation, and so on.

I understand this, but I’m not talking about run-time/implementation 
differences, just testable input/output expectations on the functions and 
methods that swift-corelibs-foundation can implement. Assuming that the 
functions and methods swift-corelibs-foundation can implement should behave the 
same, its test suite should be able to run against Darwin Foundation.

> Some of the differences are just bugs, in which case we can try and resolve 
> the issues when they're filed at bugs.swift.org  or 
> via pull requests on the GitHub repository. Some of the issues are ones where 
> the implementation in the open source version is missing; either because the 
> functionally cannot be implemented (e.g. dynamic unloading of bundles) or 
> because it's not been prioritised yet (e.g. 
> https://github.com/apple/swift-corelibs-foundation/search?utf8=✓=nsunimplemented
>  
> ).
>  In particular the big items that are missing at the moment are 
> encoder/decoder implementations and those relating to nspredicate/expression, 
> which both can be implemented in runtimes that have dynamic introspection of 
> data structures but which therefore can't be implemented in Linux.
> 
> Having said that, if you do find consistency issues which are important to 
> you then please file bugs, and optionally provide pull requests for them. We 
> can help on the mailing list to try and resolve any issues or questions as 
> they arise.

I totally have been and will continue to! I was hopeful that we could discuss a 
system that automates some of this and can catch regressions and 
inconsistencies more quickly. Is there any reason not to discuss such a 
solution?

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Alex Blewitt via swift-corelibs-dev]

> On 16 Nov 2017, at 19:14, Stephen Celis  wrote:
> 
>> On Nov 16, 2017, at 2:02 PM, Alex Blewitt  wrote:
>> 
>> There is a TestFoundation target in the swift-corelibs-foundation project, 
>> which can allow the tests to be run against the open source codebase.
> 
> Sorry, maybe I wasn’t clear, I was wondering if there’s a test suite that 
> regularly runs against _both_ the open-source Foundation implementation _and_ 
> the closed-source Foundation implementation in order to catch inconsistencies 
> across code bases.

I understood your question, but I can only point to you as to what is available 
and run on the swift-corelibs-foundation open source project.

> I don’t have a strong enough opinion to argue for or against 
> auto-capitalizing the HTTP method, but I _do_ care for consistency across 
> platforms. We have a significant test suite in our code bases with a lot of 
> unit tests and snapshot tests that pass on our dev machines (Mac), but fail 
> on Linux.

Yes, being consistent between platforms is one of the purposes of the 
swift-corelibs-foundation project. However, there are both run-time and 
implementation differences between the two platforms; the existence (or not) of 
the Objective-C runtime, whether or not comparisons are performed using the 
rules based on the Darwin version of Foundation or the ICU rules on the 
open-source version of Foundation, and so on. 

Some of the differences are just bugs, in which case we can try and resolve the 
issues when they're filed at bugs.swift.org  or via 
pull requests on the GitHub repository. Some of the issues are ones where the 
implementation in the open source version is missing; either because the 
functionally cannot be implemented (e.g. dynamic unloading of bundles) or 
because it's not been prioritised yet (e.g. 
https://github.com/apple/swift-corelibs-foundation/search?utf8=✓=nsunimplemented
 
).
 In particular the big items that are missing at the moment are encoder/decoder 
implementations and those relating to nspredicate/expression, which both can be 
implemented in runtimes that have dynamic introspection of data structures but 
which therefore can't be implemented in Linux.

Having said that, if you do find consistency issues which are important to you 
then please file bugs, and optionally provide pull requests for them. We can 
help on the mailing list to try and resolve any issues or questions as they 
arise.

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis via swift-corelibs-dev]

> On Nov 16, 2017, at 2:02 PM, Alex Blewitt  wrote:
> 
> There is a TestFoundation target in the swift-corelibs-foundation project, 
> which can allow the tests to be run against the open source codebase.

Sorry, maybe I wasn’t clear, I was wondering if there’s a test suite that 
regularly runs against _both_ the open-source Foundation implementation _and_ 
the closed-source Foundation implementation in order to catch inconsistencies 
across code bases.

> Note that there's no requirement for the methods to be capitalised in 
> URLRequest. Chances are that the implementation is such that there are some 
> pre-defined values which can be used/replaced for keys, but other ones will 
> take the case of whatever you put in them.
> 
> I also don't think it makes sense to capitalise everything because in most 
> cases it will have no effect, but is wasted computation. So in other words, 
> don't pass lowercase values into the x.httpMethod if you don't want it.


I don’t have a strong enough opinion to argue for or against auto-capitalizing 
the HTTP method, but I _do_ care for consistency across platforms. We have a 
significant test suite in our code bases with a lot of unit tests and snapshot 
tests that pass on our dev machines (Mac), but fail on Linux.

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

Re: [swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Alex Blewitt via swift-corelibs-dev]

There is a TestFoundation target in the swift-corelibs-foundation project, 
which can allow the tests to be run against the open source codebase.

Note that there's no requirement for the methods to be capitalised in 
URLRequest. Chances are that the implementation is such that there are some 
pre-defined values which can be used/replaced for keys, but other ones will 
take the case of whatever you put in them.

I also don't think it makes sense to capitalise everything because in most 
cases it will have no effect, but is wasted computation. So in other words, 
don't pass lowercase values into the x.httpMethod if you don't want it.

Alex

> On 16 Nov 2017, at 17:41, Stephen Celis via swift-corelibs-dev 
>  wrote:
> 
> Brandon Williams and I have come across a lot of inconsistencies between 
> Foundations in our Swift web work. We’ve been trying to file bugs when we 
> remember to, but I’m curious if there’s a better way to catch these. Is the 
> Foundation test suite run against both implementations to attempt to catch 
> these kinds of things? If not it would seem like a big win to do so. If so, I 
> suppose we could help by beefing up the test coverage?
> 
> Stephen
> 
>> On Nov 16, 2017, at 12:18 PM, Ian Partridge via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi, it looks like Foundation on Darwin capitalises certain HTTP
>> methods but not others:
>> 
>> ```
>> let methods = ["get", "head", "post", "put", "delete", "connect",
>> "options", "trace", "patch"]
>> 
>> var x = URLRequest(url: URL(string: "/hello")!)
>> 
>> for m in methods {
>>   x.httpMethod = m
>>   print(x.httpMethod!)
>> }
>> ```
>> 
>> Output on Darwin:
>> GET
>> HEAD
>> POST
>> PUT
>> DELETE
>> CONNECT
>> options
>> trace
>> patch
>> 
>> Currently on Linux we don't do any capitalization so I'd like to fix this.
>> 
>> Is my list of 6 methods above the definitive list of which HTTP
>> methods should be capitalized?
>> 
>> Thanks,
>> 
>> -- 
>> Ian Partridge
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

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

Re: [swift-dev] Building a swift release

[Michael Gottesman via swift-dev]

> On Nov 16, 2017, at 7:09 AM, Alex Blewitt via swift-dev  
> wrote:
> 
>> On 16 Nov 2017, at 14:30, Geordie J via swift-dev > > wrote:
>> 
>> Hello,
>> 
>> I recently asked about building a particular Swift release and couldn’t find 
>> the correct tag. It turns out there are two issues with this:
>> 
>> 1. Somehow "git checkout swift-4.0.2-RELEASE” doesn’t work. In fact, the 
>> commit that tag references 
>> (https://github.com/apple/swift/commit/efb12f4d7a6aa7575333c13fbcdb7782426b130a
>>  
>> )
>>  doesn’t seem to exist locally even after running “git fetch”, so I can’t 
>> even check out that commit’s parent and cherry-pick the release commit.
>> 
>> This is spooky enough to make me think I’m doing something wrong: can 
>> someone confirm or deny that this release tag really exists outside of 
>> GitHub?
> 
> You almost certainly haven't fetched the tag from GitHub successfully. When 
> you run 'git fetch', you'll pull down the configured options as in the 
> .git/config file. For example, I have: 

Also, I think a PR landed in the past 2-3 months that changed update-checkout 
to use git fetch to always use --tags.

> 
> [remote "origin"]
>   url = https://github.com/apple/swift 
>   pushurl = no_push
>   fetch = +refs/heads/*:refs/remotes/origin/*
> 
> As a result, it won't explicitly fetch the tag for me. You can do fetch 
> --tags, in which case, it will pull all of them, or you can configure your 
> repository to fetch that specific tag as well (or specify it on the command 
> line, like git fetch origin 
> refs/tags/swift-4.0.2-RELEASE:refs/remotes/origin/swift-4.0.2-RELEASE).
> 
>> 2. The “stable” branch of llvm (which is automatically referenced when I run 
>> utils/update-checkout) isn’t compatible with that tag (its parent commit at 
>> least). Frustratingly, checking out "swift-4.0-branch” in both apple/swift 
>> and apple/swift-llvm does not build on linux either. This appears to be due 
>> to a rename/move of Dwarf.h somewhere along the line.
> 
> 
> If you are missing some of the required downstream projects, you can run:
> 
> ./swift/utils/update-checkout --clone
> 
> You can explicitly ask to check out a branch (aka 'scheme'):
> 
> ./swift/utils/update-checkout --scheme swift-4.0-branch
> 
> and you can checkout a specific tag:
> 
> ./swift/utils/update-checkout --tag swift-4.0.2-RELEASE
> 
> You can do a clean checkout by using --reset-to-remote, which might help 
> clean your repository state up a little.
> 
> I managed to use this to check out the repository, from a base clone of Swift:
> 
>  ./utils/update-checkout --clone --tag swift-4.0.2-RELEASE
> 
> What version are you at for the LLVM repository after using the above? Mine 
> resolves to:
> 
> 2dedb62a0bcb69354e15a54be89fb5dfa63275d2
> 
> 
> ___
> 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] Building a swift release

[Michael Gottesman via swift-dev]

> On Nov 16, 2017, at 7:09 AM, Alex Blewitt via swift-dev  
> wrote:
> 
>> On 16 Nov 2017, at 14:30, Geordie J via swift-dev > > wrote:
>> 
>> Hello,
>> 
>> I recently asked about building a particular Swift release and couldn’t find 
>> the correct tag. It turns out there are two issues with this:
>> 
>> 1. Somehow "git checkout swift-4.0.2-RELEASE” doesn’t work. In fact, the 
>> commit that tag references 
>> (https://github.com/apple/swift/commit/efb12f4d7a6aa7575333c13fbcdb7782426b130a
>>  
>> )
>>  doesn’t seem to exist locally even after running “git fetch”, so I can’t 
>> even check out that commit’s parent and cherry-pick the release commit.
>> 
>> This is spooky enough to make me think I’m doing something wrong: can 
>> someone confirm or deny that this release tag really exists outside of 
>> GitHub?
> 
> You almost certainly haven't fetched the tag from GitHub successfully. When 
> you run 'git fetch', you'll pull down the configured options as in the 
> .git/config file. For example, I have: 
> 
> [remote "origin"]
>   url = https://github.com/apple/swift 
>   pushurl = no_push
>   fetch = +refs/heads/*:refs/remotes/origin/*
> 
> As a result, it won't explicitly fetch the tag for me. You can do fetch 
> --tags, in which case, it will pull all of them, or you can configure your 
> repository to fetch that specific tag as well (or specify it on the command 
> line, like git fetch origin 
> refs/tags/swift-4.0.2-RELEASE:refs/remotes/origin/swift-4.0.2-RELEASE).
> 
>> 2. The “stable” branch of llvm (which is automatically referenced when I run 
>> utils/update-checkout) isn’t compatible with that tag (its parent commit at 
>> least). Frustratingly, checking out "swift-4.0-branch” in both apple/swift 
>> and apple/swift-llvm does not build on linux either. This appears to be due 
>> to a rename/move of Dwarf.h somewhere along the line.
> 
> 
> If you are missing some of the required downstream projects, you can run:
> 
> ./swift/utils/update-checkout --clone
> 
> You can explicitly ask to check out a branch (aka 'scheme'):
> 
> ./swift/utils/update-checkout --scheme swift-4.0-branch

A scheme is not a branch. A scheme is a list of (repo, branch). This allows for 
the underlying branch to vary per repo.

> 
> and you can checkout a specific tag:
> 
> ./swift/utils/update-checkout --tag swift-4.0.2-RELEASE
> 
> You can do a clean checkout by using --reset-to-remote, which might help 
> clean your repository state up a little.
> 
> I managed to use this to check out the repository, from a base clone of Swift:
> 
>  ./utils/update-checkout --clone --tag swift-4.0.2-RELEASE
> 
> What version are you at for the LLVM repository after using the above? Mine 
> resolves to:
> 
> 2dedb62a0bcb69354e15a54be89fb5dfa63275d2
> 
> 
> ___
> 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] Building a swift release

[Timothy Wood via swift-dev]

I had to go spelunking in the build scripts to find this, so no idea if it is 
the proper way, but it seems to work. In a fresh checkout of the swift repo:


./utils/update-checkout --clone --scheme swift-4.0-branch

This will clone all the needed repos and then check out the right branch.

-tim


> On Nov 16, 2017, at 6:30 AM, Geordie J via swift-dev  
> wrote:
> 
> Hello,
> 
> I recently asked about building a particular Swift release and couldn’t find 
> the correct tag. It turns out there are two issues with this:
> 
> 1. Somehow "git checkout swift-4.0.2-RELEASE” doesn’t work. In fact, the 
> commit that tag references 
> (https://github.com/apple/swift/commit/efb12f4d7a6aa7575333c13fbcdb7782426b130a
>  
> )
>  doesn’t seem to exist locally even after running “git fetch”, so I can’t 
> even check out that commit’s parent and cherry-pick the release commit.
> 
> This is spooky enough to make me think I’m doing something wrong: can someone 
> confirm or deny that this release tag really exists outside of GitHub?
> 
> 
> 2. The “stable” branch of llvm (which is automatically referenced when I run 
> utils/update-checkout) isn’t compatible with that tag (its parent commit at 
> least). Frustratingly, checking out "swift-4.0-branch” in both apple/swift 
> and apple/swift-llvm does not build on linux either. This appears to be due 
> to a rename/move of Dwarf.h somewhere along the line.
> 
> Any ideas?
> 
> 
> Thanks,
> Geordie
> 
> ___
> 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] Building a swift release

[Alex Blewitt via swift-dev]

> On 16 Nov 2017, at 14:30, Geordie J via swift-dev  wrote:
> 
> Hello,
> 
> I recently asked about building a particular Swift release and couldn’t find 
> the correct tag. It turns out there are two issues with this:
> 
> 1. Somehow "git checkout swift-4.0.2-RELEASE” doesn’t work. In fact, the 
> commit that tag references 
> (https://github.com/apple/swift/commit/efb12f4d7a6aa7575333c13fbcdb7782426b130a
>  
> )
>  doesn’t seem to exist locally even after running “git fetch”, so I can’t 
> even check out that commit’s parent and cherry-pick the release commit.
> 
> This is spooky enough to make me think I’m doing something wrong: can someone 
> confirm or deny that this release tag really exists outside of GitHub?

You almost certainly haven't fetched the tag from GitHub successfully. When you 
run 'git fetch', you'll pull down the configured options as in the .git/config 
file. For example, I have: 

[remote "origin"]
url = https://github.com/apple/swift
pushurl = no_push
fetch = +refs/heads/*:refs/remotes/origin/*

As a result, it won't explicitly fetch the tag for me. You can do fetch --tags, 
in which case, it will pull all of them, or you can configure your repository 
to fetch that specific tag as well (or specify it on the command line, like git 
fetch origin 
refs/tags/swift-4.0.2-RELEASE:refs/remotes/origin/swift-4.0.2-RELEASE).

> 2. The “stable” branch of llvm (which is automatically referenced when I run 
> utils/update-checkout) isn’t compatible with that tag (its parent commit at 
> least). Frustratingly, checking out "swift-4.0-branch” in both apple/swift 
> and apple/swift-llvm does not build on linux either. This appears to be due 
> to a rename/move of Dwarf.h somewhere along the line.


If you are missing some of the required downstream projects, you can run:

./swift/utils/update-checkout --clone

You can explicitly ask to check out a branch (aka 'scheme'):

./swift/utils/update-checkout --scheme swift-4.0-branch

and you can checkout a specific tag:

./swift/utils/update-checkout --tag swift-4.0.2-RELEASE

You can do a clean checkout by using --reset-to-remote, which might help clean 
your repository state up a little.

I managed to use this to check out the repository, from a base clone of Swift:

 ./utils/update-checkout --clone --tag swift-4.0.2-RELEASE

What version are you at for the LLVM repository after using the above? Mine 
resolves to:

2dedb62a0bcb69354e15a54be89fb5dfa63275d2


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

[swift-dev] Building a swift release

[Geordie J via swift-dev]

Hello,

I recently asked about building a particular Swift release and couldn’t find 
the correct tag. It turns out there are two issues with this:

1. Somehow "git checkout swift-4.0.2-RELEASE” doesn’t work. In fact, the commit 
that tag references 
(https://github.com/apple/swift/commit/efb12f4d7a6aa7575333c13fbcdb7782426b130a 
)
 doesn’t seem to exist locally even after running “git fetch”, so I can’t even 
check out that commit’s parent and cherry-pick the release commit.

This is spooky enough to make me think I’m doing something wrong: can someone 
confirm or deny that this release tag really exists outside of GitHub?


2. The “stable” branch of llvm (which is automatically referenced when I run 
utils/update-checkout) isn’t compatible with that tag (its parent commit at 
least). Frustratingly, checking out "swift-4.0-branch” in both apple/swift and 
apple/swift-llvm does not build on linux either. This appears to be due to a 
rename/move of Dwarf.h somewhere along the line.

Any ideas?


Thanks,
Geordie



signature.asc
Description: Message signed with OpenPGP
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Highlighting other platforms for Swift?

[Ian Partridge via swift-dev]

On 15 November 2017 at 19:35, Ted Kremenek via swift-dev
 wrote:
> We’re actively setting up support to wire in up externally hosted CI bots to 
> our CI infrastructure so that the community can help support the bringup and 
> testing of Swift on other platforms beyond the officially supported 
> platforms.  The tentative rollout for that was December.  We’ll announce more 
> details once we get closer to rollout.

This sounds great. IBM has ported Swift to platforms including IBM
System z (mainframe) and it would be good to get CI integration so
that we can run "@swift-ci please test s390" when wanted.

Linking to releases and nightly builds from swift.org would also be
good, where they are available.

> That said, do you have specific ideas on how such efforts should be 
> highlighted on swift.org, and what should be the optics?

Python has a main https://www.python.org/downloads/ page and a
separate https://www.python.org/download/other/ page to point users at
non-official ports. That model could work well for Swift too.

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

Re: [swift-dev] Generalizing nominal type descriptors into "context descriptors"; encoding generic requirements

[John McCall via swift-dev]

> On Nov 14, 2017, at 2:36 PM, Joe Groff via swift-dev  
> wrote:
> The type metadata that gets emitted for struct, enum, and class types 
> includes a reference to a nominal type descriptor. The descriptor carries 
> information that pertains to the nominal type declaration itself, independent 
> of specific instantiations of generic types, as well as information that’s of 
> a more “reflective” nature which isn’t on the fast path for 
> compiler-generated code but may be of interest to reflection APIs or one-time 
> initialization actions. The current nominal type descriptor format is lacking 
> in a number of ways that I’d like to improve:
> 
Great write-up.  Your plan sounds spot-on to me.

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