Re: [swift-corelibs-dev] Query on bridgeable classes

[Alex Blewitt via swift-corelibs-dev]

Do you have a couple of examples that you're referring to?

Alex

> On 21 Feb 2017, at 09:25, Nethra Ravindran via swift-corelibs-dev 
>  wrote:
> 
> Hi everyone,
> 
> To be more precise, I would like to know why few classes are not CFBridgeable.
> 
> Thank you.
> 
> - Nethra Ravindran
> 
> On Tue, Feb 21, 2017 at 2:20 PM, Nethra Ravindran 
> > wrote:
> Hi,
> 
> I see that some classes are bridgeable and some are not. It would be great if 
> someone can explain why few classes are not bridgeable.
> 
> Thank you!
> 
> - Nethra Ravindran
> 
> ___
> 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] Building Foundation

[Alex Blewitt via swift-corelibs-dev]

> On 2 Mar 2017, at 01:51, Mohit Athwani via swift-corelibs-dev 
>  wrote:
> 
> I am trying to build Foundation on my Ubuntu 16.04 LTS version using:
> 
> swift/utils/build-script --xctest --foundation -t
> 
> And it fails with the following tests failing:

OK, what happened when you looked in the logs to find out why the tests were 
failing?

> Every thing has been freshly cloned and no code has been modifed yet...

Which version of the code were you working with? Are you on master, or a stable 
branch? What branch is your 'swift-llvm' subproject checked out as?

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

Re: [swift-corelibs-dev] Foundation and NSDecimal

[Alex Blewitt via swift-corelibs-dev]

I agree, but I'm not sure where that's coming from. It seems to be being 
imported from CoreFoundation on Darwin, and although it's defined this way in 
NSDecimal.h in the Foundation framework:

NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
  { return ((dcm->_length == 0) && dcm->_isNegative); }

I'm not sure why the @discardableResult attribute is being added here; perhaps 
it's to do with the fact that it's an NS_INLINE function. Should I raise a 
separate bug for that?

Alex

> On 28 Sep 2016, at 17:32, Kenny Leung via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> I would also say that this should not be marked as @discardableResult, since 
> its only purpose is to report back yes or no, it would be kind of suspicious 
> if the it wasn’t used.
> 
> -Kenny
> 
> 
>> On Sep 27, 2016, at 5:34 AM, Alex Blewitt via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> The Framework function 
>> 
>> NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)
>> 
>> has been imported into Swift on both Darwin and Linux as
>> 
>> :type lookup NSDecimalIsNotANumber
>> @discardableResult func NSDecimalIsNotANumber(_ dcm: 
>> Swift.UnsafePointer) -> Swift.Bool
>> :type lookup NSDecimalIsNotANumber
>> func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) 
>> -> Swift.Bool
>> 
>> However I think this should instead be imported as a member function on the 
>> Decimal type, instead of passing through a pointer.
>> 
>> extension Decimal {
>> public func isNotANumber() -> Bool
>> }
>> 
>> This may not have been picked up by the automatic renaming progress because 
>> it's a const pointer, and because it's an NS_INLINE defined in the header, 
>> instead of in an implementation file.
>> 
>> There are some other global constants NSDecimalMaxSize and NSDecimalNoScale, 
>> which should probably be implemented as constants in the Decimal type as 
>> well e.g.
>> 
>> extension Decimal {
>> public let maxSize = 8
>> public let noScale =  Int16.max
>> }
>> 
>> Since this would need to be fixed in both the Swift Linux foundation 
>> implementation and the Darwin overlay (and it would be a breaking change) 
>> what is the right process to be able to fix this?
>> 
>> Alex
>> ___
>> 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-corelibs-dev] [swift-users] Linux - Calendar date(byAdding:to:wrappingComponents:) returns nil when it shouldn't?

[Alex Blewitt via swift-corelibs-dev]

> On 5 Oct 2016, at 16:48, Alex Blewitt via swift-users  
> wrote:
> 
> 
>> On 4 Oct 2016, at 20:10, Jason Ji via swift-users > > wrote:
>> 
>> Hello,
>> 
>> I'm having an issue with (NS)Calendar on Linux which I think is a bug, but I 
>> just wanted to check first if it was just me or if this is indeed a bug. 
>> I've filed a bug report here, just in case: 
>> https://bugs.swift.org/browse/SR-2846 
>> 
>> In short, Calendar has a method date(byAdding:to:wrappingComponents:) which 
>> returns a new date which is the result of date arithmetic on the passed-in 
>> date. It works fine on El Capitan, but doesn't seem to work properly on 
>> Ubuntu 14.04. Below is some sample code:
>> 
>> import Foundation
>> 
>> let today = Date()
>> let diffComponents = DateComponents(day: -1)
>> let newDate = Calendar.current.date(byAdding: diffComponents, to: today) 
>> //returns nil
>> 
>> I've tried this in the swift REPL on Ubuntu 14.04 with both Swift 
>> 3.0-RELEASE, and the latest snapshot (October 2).
>> 
>> If anyone else could try this out as a sanity check for me, that would be 
>> great - I'd be happy to be embarrassed that I've done something wrong.
> 
> It's worth explicitly specifying a calendar (so that it rules out any 
> environmental setup) -- for example, Calendar(identifier:.gregorian). 
> However, I see 'nil' as well as the return result for this operation, so it 
> could be a bug.

I think the bug is here:

https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L464
 


_convert(comps.isLeapMonth, type: "L", vector: , compDesc: 
)


The leap month is defined with a capital letter here, but a lower-case letter 
when it's decoded:

https://github.com/apple/swift-corelibs-foundation/blob/338f4bf3a89c75a0420b49f5701466e106af02b5/CoreFoundation/Locale.subproj/CFCalendar.c#L423
 


case 'l': return UCAL_IS_LEAP_MONTH;


The lower-case l should be the correct version so this probably needs to be 
changed here. In addition, there are optional-of-bool issues here; the 
'comps.isLeapMonth' is a boolean value, which means it attempts to roll forward 
the leap month (which doesn't make sense). I think the error was introduced 
here, although it didn't help that the capitalisation was also wrong at the 
time:

https://github.com/apple/swift-corelibs-foundation/commit/d3300b7118924d6ad8ba411d317f33eade854bc5
 

 

Alex

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

[swift-corelibs-dev] Foundation and NSDecimal

[Alex Blewitt via swift-corelibs-dev]

The Framework function 

NS_INLINE BOOL NSDecimalIsNotANumber(const NSDecimal *dcm)

has been imported into Swift on both Darwin and Linux as

:type lookup NSDecimalIsNotANumber
@discardableResult func NSDecimalIsNotANumber(_ dcm: 
Swift.UnsafePointer) -> Swift.Bool
:type lookup NSDecimalIsNotANumber
func NSDecimalIsNotANumber(_ dcm: Swift.UnsafePointer) -> 
Swift.Bool

However I think this should instead be imported as a member function on the 
Decimal type, instead of passing through a pointer.

extension Decimal {
  public func isNotANumber() -> Bool
}

This may not have been picked up by the automatic renaming progress because 
it's a const pointer, and because it's an NS_INLINE defined in the header, 
instead of in an implementation file.

There are some other global constants NSDecimalMaxSize and NSDecimalNoScale, 
which should probably be implemented as constants in the Decimal type as well 
e.g.

extension Decimal {
  public let maxSize = 8
  public let noScale =  Int16.max
}

Since this would need to be fixed in both the Swift Linux foundation 
implementation and the Darwin overlay (and it would be a breaking change) what 
is the right process to be able to fix this?

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

[swift-corelibs-dev] Failing test due to network XML validation

[Alex Blewitt via swift-corelibs-dev]

There's a test which attempts to download an XML DTD from an external file, 
which fails when there's an intermittent network connection:

  Test Case 'TestNSArray.test_writeToFile' started at 09:15:53.214
  I/O warning : failed to load external entity 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd;
  .../swift-corelibs-foundation/TestFoundation/TestNSArray.swift:492: error: 
TestNSArray.test_writeToFile : failed - XMLDocument   failes to read / validate 
contenets

It's probably not a good idea to have remote DTD parsing enabled, especially 
for testing a write to file method. Plus, there's a spelling error or two :)

This happens because the XML document has 'validate' called on it:

  let plistDoc = try XMLDocument(contentsOf: URL(fileURLWithPath: 
testFilePath!, isDirectory: false), options: [])
  try plistDoc.validate()

https://github.com/apple/swift-corelibs-foundation/blob/e05884bd835f6ee22e7c0b0484326d63c31d554a/TestFoundation/TestNSArray.swift#L485-L486
 


I don't think the validate call is adding anything here, because if it's 
invalid then the subsequent assert will fail, and we're just testing whether or 
not we can read the contents from file.

Should we remove the try/validate statement here?

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

[swift-corelibs-dev] Outstanding pull request for NSDecimal?

[Alex Blewitt via swift-corelibs-dev]

I raised https://github.com/apple/swift-corelibs-foundation/pull/687 about a 
week ago for the final push implementing NSDecimal. It's still stuck in limbo - 
can someone add a @swift-ci please test to it, so that it can at least have the 
tests run and possibly committed?

I'm concerned that it may need a rebase after 
https://github.com/apple/swift-corelibs-foundation/pull/694 which fixed a 
warning that I'd introduced inadvertently and would like to ensure that it can 
be merged.

Thanks,

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

[swift-corelibs-dev] Cleaning up old branches

[Alex Blewitt via swift-corelibs-dev]

> On 12 Oct 2016, at 18:25, Tony Parker <anthony.par...@apple.com> wrote:
> 
> Hi Alex,
> 
>> On Oct 12, 2016, at 9:52 AM, Alex Blewitt via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>> 
>>  There are several remote branches that have the 'swift-3' moniker including 
>> several 'preview' ones:
>> 
>>   origin/swift-3
>>   origin/swift-3.0-branch
>>   origin/swift-3.0-preview-1-branch
>>   origin/swift-3.0-preview-2-branch
>>   origin/swift-3.0-preview-3-branch
>>   origin/swift-3.0-preview-4-branch
>>   origin/swift-3.0-preview-5-branch
>>   origin/swift-3.0-preview-5-speculative
>>   origin/swift-3.0.1-preview-2-branch
>> 
>> Why are we representing previews as branches, instead of tags? If I wanted 
>> to submit a pull request for one of these previews, it's not clear which 
>> one(s) I should target.
> 
> I agree this is a bit confusing.
> 
> Right now, swift-3.0-branch is the one that is used as the “development” 
> branch for any updates to swift 3.0.
> 
>> 
>> There are also a number of branches that are old (in many cases, over a 
>> month):
>> 
>>   origin/dabrahams-patch-1
>>   origin/dabrahams-patch-2
>>   origin/data-associated-type-fixes-3.0
>>   origin/more_value_types
>>   origin/nscoding
>>   origin/revert-540-SR-2151
>>   origin/revert-567-pr-grabbag
>> 
>> Can we get these cleaned up if they are no longer necessary?
>> 
>> Alex
> 
> Yes, I think we should delete these. I’ll do that for a bunch of these.
> 
> - Tony

Thanks for cleaning up the old branches, Tony. 

I wonder if we need to keep the -preview- branches? It seems they are all 
replaced by equivalent tags, except for -preview-5-speculative (which is 
contained in both swift-3.0 branch and in the swift-3.0-PREVIEW-6 tag, as shown 
below):

$ git ls-remote --heads | grep preview
From https://github.com/apple/swift-corelibs-foundation
3d10cf76b1faa86bae48a5e7d9876ee7ad3af422
refs/heads/swift-3.0-preview-1-branch
c8c1ff0f8b274567f9018297269258290238be73
refs/heads/swift-3.0-preview-2-branch
0ff9f494a66fe7130536c70f23ef5f30b1d2aa9f
refs/heads/swift-3.0-preview-3-branch
686d9b6db204a330f8bacf792e552dbd2f5f82df
refs/heads/swift-3.0-preview-4-branch
686d9b6db204a330f8bacf792e552dbd2f5f82df
refs/heads/swift-3.0-preview-5-branch
958a93ee647dc8aa66f2fc31de5000681d42604f
refs/heads/swift-3.0-preview-5-speculative

$ git ls-remote --tags | grep PREVIEW
From https://github.com/apple/swift-corelibs-foundation
29480f5e877fec0b1c430d9605d0fb1a97c24c9brefs/tags/swift-3.0-PREVIEW-1
3d10cf76b1faa86bae48a5e7d9876ee7ad3af422refs/tags/swift-3.0-PREVIEW-1^{}
c8c1ff0f8b274567f9018297269258290238be73refs/tags/swift-3.0-PREVIEW-2
0ff9f494a66fe7130536c70f23ef5f30b1d2aa9frefs/tags/swift-3.0-PREVIEW-3
686d9b6db204a330f8bacf792e552dbd2f5f82dfrefs/tags/swift-3.0-PREVIEW-4
686d9b6db204a330f8bacf792e552dbd2f5f82dfrefs/tags/swift-3.0-PREVIEW-5
cf473150c9bc1ede5a53b451d32cbe30c231b63drefs/tags/swift-3.0-PREVIEW-6
2eccd197f2c41fe05a7a557c7eff382b3303f030refs/tags/swift-3.0.1-PREVIEW-1
b6898c75e42fe73552b22a32361fb440cc9fdefcrefs/tags/swift-3.0.1-PREVIEW-2
b6898c75e42fe73552b22a32361fb440cc9fdefcrefs/tags/swift-3.0.1-PREVIEW-3

$ git log --oneline --decorate 
refs/remotes/origin/swift-3.0-preview-5-speculative^...refs/tags/swift-3.0-PREVIEW-6
 | grep swift- 
cf47315 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-08-07-a, tag: 
swift-DEVELOPMENT-SNAPSHOT-2016-08-04-a, tag: swift-3.0-PREVIEW-6) Merge branch 
'filemanager-default' of https://github.com/jpsim/swift-corelibs-foundation
3b9a917 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-07-29-a) Revert "Revert 
"UnsafePointer conversion fixes.""
541f035 (tag: swift-DEVELOPMENT-SNAPSHOT-2016-07-28-a) Merge pull request #477 
from swiftix/SE-130
958a93e (origin/swift-3.0-preview-5-speculative) Update for SE-0025 ('private' 
and 'fileprivate') (#445)

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

[swift-corelibs-dev] Cherry-picking changes for the next Swift release?

[Alex Blewitt via swift-corelibs-dev]

I have a couple of Calendar related fixes into swift-corelibs-foundation master:

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

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


How do I go about cherry-picking these to be in the next release? There are 
several remote branches that have the 'swift-3' moniker including several 
'preview' ones:

  origin/swift-3
  origin/swift-3.0-branch
  origin/swift-3.0-preview-1-branch
  origin/swift-3.0-preview-2-branch
  origin/swift-3.0-preview-3-branch
  origin/swift-3.0-preview-4-branch
  origin/swift-3.0-preview-5-branch
  origin/swift-3.0-preview-5-speculative
  origin/swift-3.0.1-preview-2-branch

Why are we representing previews as branches, instead of tags? If I wanted to 
submit a pull request for one of these previews, it's not clear which one(s) I 
should target.

There are also a number of branches that are old (in many cases, over a month):

  origin/dabrahams-patch-1
  origin/dabrahams-patch-2
  origin/data-associated-type-fixes-3.0
  origin/more_value_types
  origin/nscoding
  origin/revert-540-SR-2151
  origin/revert-567-pr-grabbag

Can we get these cleaned up if they are no longer necessary?

Alex

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

[swift-corelibs-dev] Broken master-next?

[Alex Blewitt via swift-corelibs-dev]

My pull request failed to build:

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


The build failure is entirely unrelated to my changes; it looks like whatever 
point the branch was taken from/built from, the underlying swift implementation 
is broken:

https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/455/ 
 

In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILFunction.h:20:
In file included from 
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILBasicBlock.h:21:
 
<>/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/swift/include/swift/SIL/SILInstruction.h:80:16:
 error: no template named 'ilist_sentinel_traits' in namespace 'llvm'; did you 
mean 'ilist_sentinel_tracking'?
  friend llvm::ilist_sentinel_traits;
 ~~^
   ilist_sentinel_tracking
/home/buildnode/jenkins/workspace/swift-corelibs-foundation-PR-Linux@2/llvm/include/llvm/ADT/ilist_node_options.h:25:47:
 note: 'ilist_sentinel_tracking' declared here
template  struct ilist_sentinel_tracking {};
  ^

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

[swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

[Alex Blewitt via swift-corelibs-dev]

I've pushed a change which will add an unavailability warning for a method 
which was deprecated at the point of being added to Swift, has never worked, 
and likely never will:

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


There are some other types in Foundation which aren't likely to ever be 
implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage, copy(with 
zone) etc. The majority of these methods use NSUnimplemented(), which means 
there are often unannounced runtime errors that you can get from something that 
compiled correctly.

I'd like to suggest that we attempt to resolve this problem, either by removing 
the features whihc are never going to be implemented (e.g. by commenting out 
the calls) or by marking them as @available(*,unavailable, message:"Not 
available on the Linux platform"). That way, calls that are known cannot work 
can be identified at compile time instead of at run-time.

I hope we'll then be able to remove the NSUnimplemented calls on the types that 
can never be implemented, so that we can focus on those types and functions 
that we can. Alternatively we can define a different macro, say 
NSUnavailableOnLinux, to indicate that this functionality cannot be present (as 
opposed to just leaving it blank).

What do you think?

$ git grep -c NSUnimplemented | sort -n -r -k2 -t:
Foundation/NSExpression.swift:37
Foundation/NSURLCache.swift:22
Foundation/FileManager.swift:22
Foundation/NSPort.swift:21
Foundation/NSOrderedSet.swift:20
Foundation/NSSortDescriptor.swift:19
...
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Unavailability macros for APIs that aren't going to be implemented on Linux?

[Alex Blewitt via swift-corelibs-dev]

> On 28 Jul 2017, at 20:30, Alex Blewitt via swift-corelibs-dev 
> <swift-corelibs-dev@swift.org> wrote:
> 
> In the meantime I'll take a stab next week at proposing some unavailability 
> annotations for some of the stuff which almost certainly doesn't make sense, 
> to do with Mach ports and NSZone. 

I've created a pull request which adds NSUnsupported, and uses that to wrap 
NSPort and NSMessagePort:

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

What do you think? Should we use 'deprecated' (so that it's a warning) or 
'unavailable' (so that it's a compile time error)?

+@available(*,deprecated,message:"Not available on non-Darwin platforms")

+@available(*,unavailable,message:"Not available on non-Darwin platforms")


Alex

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

Re: [swift-corelibs-dev] Informal Chat Medium

[Alex Blewitt via swift-corelibs-dev]

> On 2 Aug 2017, at 20:34, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello Corelibs dev,

Hi David, welcome!

> A few months back, I wanted to start contributing more seriously to Swift 
> Open Source. I ended up helping out on the Swift Package Manager project and 
> had a very positive experience. It’s not easy to jump into a big project and 
> it would not have been such a success for me without their official Slack 
> channel where I was grateful to often find a helping hand when I had doubts, 
> questions, or wanted to discuss and understand the process or direction of 
> the project. That medium really helped me to ask the kind of questions I was 
> afraid to ask on the mailing-list, which feels like a more formal medium.
> 
> Now that I’m looking into what I can do on corelibs-foundation, I really wish 
> an equivalent channel existed. Is this an idea the corelibs team would be 
> interested in entertaining?

Yes, and indeed something that's been discussed for a while now is the 
possibility of moving the mailing lists to a forum:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038452.html

Although Ted initially started the discussion with 'for swift-evolution' he 
later clarified he thought all should move:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038454.html

While it's not a Slack channel, I wonder if this would suit your needs if it 
were to happen?

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

Re: [swift-corelibs-dev] TimeZone database

[Alex Blewitt via swift-corelibs-dev]

It looks like it's /usr/share/zoneinfo on all Ubuntu versions:

alblue.local[~]$ docker run -it --rm ubuntu:14.04 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab
alblue.local[~]$ docker run -it --rm ubuntu:16.04 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab
alblue.local[~]$ docker run -it --rm ubuntu:16.10 find /usr -name zone.tab
/usr/share/zoneinfo/zone.tab

This is the same that's coming from CFTimeZone.c:

https://github.com/apple/swift-corelibs-foundation/blob/2611dcd0d9b91fecace537838294bd85f0220503/CoreFoundation/NumberDate.subproj/CFTimeZone.c#L36-L39

Is it possible that the MacOS header is being included and defining TZDIR 
before the CFTimeZone.c file is compiled?

Alex

> On 6 Jul 2017, at 19:22, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Is the path to zoneinfo different on the Ubuntu docker image?
> 
> - Tony
> 
>> On Jul 6, 2017, at 9:36 AM, Youming Lin > > wrote:
>> 
>> We were seeing this on Travis too. Specifically, on a Travis matrix build 
>> using Swift 3.1.1 on a Ubuntu 16.04 docker image running inside a Travis 
>> 14.04 VM.
>> 
>> The issue was specific to the Ubuntu 16.04 docker image; when I tested in 
>> Ubuntu 16.04 OS as a guest VM, the issue went away.
>> 
>> Thanks,
>> 
>> Youming Lin
>> IBM Cloud, Swift@IBM, Kitura developer
>> Austin, TX
>> GitHub: @youming-lin
>> 
>> Tony Parker via swift-corelibs-dev ---07/06/2017 10:31:15 
>> AM---Yes, we’re discussing this one internally too and trying to figure out 
>> what the right answer is. May
>> 
>> From: Tony Parker via swift-corelibs-dev > >
>> To: Ian Partridge >
>> Cc: swift-corelibs-dev > >
>> Date: 07/06/2017 10:31 AM
>> Subject: Re: [swift-corelibs-dev] TimeZone database
>> Sent by: swift-corelibs-dev-boun...@swift.org 
>> 
>> 
>> 
>> 
>> Yes, we’re discussing this one internally too and trying to figure out what 
>> the right answer is. Maybe the best solution for now is to find a good 
>> mechanism to check the underlying version of the OS and split it out into a 
>> function as you suggest.
>> 
>> - Tony
>> On Jul 6, 2017, at 7:37 AM, Ian Partridge via swift-corelibs-dev 
>> > wrote:
>> 
>> Good shout Simon, you are right. I'm on Sierra. Compare and contrast:
>> 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>> #define TZDIR "/usr/share/zoneinfo"
>> 
>> /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tzfile.h
>> #define TZDIR "/var/db/timezone/zoneinfo"
>> 
>> so I guess if I installed the High Sierra beta it would work OK.
>> 
>> I hacked CF to force it to use /usr/share/zoneinfo and TestFoundation
>> is much happier, but that's not a solution.
>> 
>> On 6 July 2017 at 15:20, Simon Evans > 
>> wrote:
>> Ian
>> 
>> I also saw this error, I think its because the TZDIR is different in the 
>> headers shipped with Xcode 9. Maybe the location of the timezone directory 
>> was moved between Sierra and High Sierra. What version of macOS are you 
>> testing on?
>> 
>> If it has indeed moved between 10.12 and 10.13 it may require a runtime 
>> version check to dynamically return TZDIR.
>> 
>> Simon
>> 
>> On 6 Jul 2017, at 15:09, Ian Partridge via swift-corelibs-dev 
>> > wrote:
>> 
>> Hi,
>> 
>> I'm seeing quite a lot of tests failing when running the
>> TestFoundation target in Xcode. The failures are timezone related.
>> Most simply, the code
>> 
>> let timeZone = TimeZone(abbreviation: "GMT")
>> 
>> is returning nil.
>> 
>> Walking through the CF code which sets things up, it seems to be
>> trying to read the timezone database from
>> /var/db/timezone/zoneinfo/zone.tab which doesn't exist on my macOS
>> system.
>> 
>> /usr/share/zoneinfo/zone.tab is there and seems to be the right
>> location (?), but CF is picking up TZDIR from tzfile.h which says:
>> 
>> #define TZDIR "/var/db/timezone/zoneinfo"
>> 
>> Any thoughts? I feel like I'm missing something obvious and have gone
>> too far down the rabbit hole.
>> 
>> --
>> Ian Partridge
>> ___
>> 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 
>> 

Re: [swift-corelibs-dev] XCTest Build is failing for Dev environment

[Alex Blewitt via swift-corelibs-dev]

I'd suggest trying to run the command that failed manually and see if there's 
any additional error messages that get printed out:

> xcodebuild -workspace 
> /Users/tapan/swift-source/swift-corelibs-xctest/XCTest.xcworkspace -scheme 
> SwiftXCTest -configuration Release 
> SWIFT_EXEC="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc"
>  SWIFT_LINK_OBJC_RUNTIME=YES 
> SYMROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"
>  
> OBJROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"


It looks like it may be trying to link in SwiftFoundation, and failing. I'm not 
sure if there's any additional steps that need to be built beforehand in order 
to build XCTest.

Alex

> On 23 Apr 2017, at 14:56, Tapan Prakasht via swift-corelibs-dev 
>  wrote:
> 
> Hi,
> 
> I am new to this mailing list.
> 
> I am trying to build XCtest project. I followed every step mentioned
> in the documentation.  I have executed the following command. But
> build got failed.
> 
> ../swift/utils/build-script --preset corelibs-xctest
> 
> Error:
> 
> ** BUILD FAILED **
> 
> 
> The following build commands failed:
>   Ld 
> /Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64/Release/SwiftFoundation.framework/Versions/A/SwiftFoundation
>  normal x86_64
> (1 failure)
> Traceback (most recent call last):
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 526, in 
> main()
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 522, in main
> parsed_args.func(parsed_args)
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 98, in build
> source_dir=SOURCE_DIR))
>   File "/Users/tapan/swift-source/swift-corelibs-xctest/build_script.py", 
> line 31, in run
> subprocess.check_call(command, shell=True)
>   File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
>  line 540, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command 'xcodebuild -workspace 
> /Users/tapan/swift-source/swift-corelibs-xctest/XCTest.xcworkspace -scheme 
> SwiftXCTest -configuration Release 
> SWIFT_EXEC="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/bin/swiftc"
>  SWIFT_LINK_OBJC_RUNTIME=YES 
> SYMROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"
>  
> OBJROOT="/Users/tapan/swift-source/build/Ninja-ReleaseAssert/xctest-macosx-x86_64"'
>  returned non-zero exit status 65
> ../swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> ../swift/utils/build-script: fatal error: command terminated with a non-zero 
> exit status 1, aborting
> 
> 
> My dev environment is MacOS Sierra 10.12.4 (16E195)
> Xcode 8.3.2
> 
> Can somebody help here?
> 
> Thanks,
> Tapan
> ___
> 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] Unavailability macros for APIs that aren't going to be implemented on Linux?

[Alex Blewitt via swift-corelibs-dev]

On 28 Jul 2017, at 19:44, Tony Parker <anthony.par...@apple.com> wrote:
> 
> This sounds like a good plan to me. We’ll have to discuss the specifics of 
> what is marked unavailable this way, probably best via code review.
> 
> I think we had more hope for some of the more-dynamic methods (e.g. 
> NSSortDescriptor, NSExpression), but it does seem clear at this point that 
> the current API is unsuitable for Swift in various ways.

Perhaps if more dynamic introspection lands in a future version of Swift they 
might make sense. It's also possible that some of the new keypath stuff being 
added in Swift might make a good potential API in future, so maybe those aren't 
quite as cut and dry.  

In the meantime I'll take a stab next week at proposing some unavailability 
annotations for some of the stuff which almost certainly doesn't make sense, to 
do with Mach ports and NSZone. 

Alex

> 
> - Tony
> 
>> On Jul 28, 2017, at 7:27 AM, Ian Partridge via swift-corelibs-dev 
>> <swift-corelibs-dev@swift.org> wrote:
>> 
>> Hi Al, thanks for bringing this up.
>> 
>> My view is that we shouldn't have API in the project which is never going to 
>> be implemented.  The contents of swift-corelibs-foundation should represent 
>> a baseline of fundamental types and functionality which is useful to all 
>> applications and can be implemented on a broad range of platforms and 
>> operating systems.
>> 
>> I think it is more useful to developers who are porting their Swift 
>> applications to other platforms if they are faced with a helpful message 
>> when their app attempts to use unavailable API, rather than just "ERROR: 
>> type 'NSWhatever' has no member 'foo'" - so I like your idea of using 
>> @available annotations to guide people.
>> 
>> Once Swift 4 is out of the door, I think we should do a review of the 
>> codebase and decide which of the remaining NSUnimplemented() are really 
>> NSProbablyNever().
>> 
>> This will also help new contributors to swift-corelibs-foundation as they 
>> will be able to be confident that every NSUnimplemented() is a genuine 
>> opportunity to contribute.
>> 
>> Regards,
>> Ian Partridge
>> 
>>> On 28 July 2017 at 15:07, Alex Blewitt via swift-corelibs-dev 
>>> <swift-corelibs-dev@swift.org> wrote:
>>> I've pushed a change which will add an unavailability warning for a method 
>>> which was deprecated at the point of being added to Swift, has never 
>>> worked, and likely never will:
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/pull/1140
>>> 
>>> There are some other types in Foundation which aren't likely to ever be 
>>> implementable in Swift on Linux; Bundle.unload, NSPort/PortMessage, 
>>> copy(with zone) etc. The majority of these methods use NSUnimplemented(), 
>>> which means there are often unannounced runtime errors that you can get 
>>> from something that compiled correctly.
>>> 
>>> I'd like to suggest that we attempt to resolve this problem, either by 
>>> removing the features whihc are never going to be implemented (e.g. by 
>>> commenting out the calls) or by marking them as @available(*,unavailable, 
>>> message:"Not available on the Linux platform"). That way, calls that are 
>>> known cannot work can be identified at compile time instead of at run-time.
>>> 
>>> I hope we'll then be able to remove the NSUnimplemented calls on the types 
>>> that can never be implemented, so that we can focus on those types and 
>>> functions that we can. Alternatively we can define a different macro, say 
>>> NSUnavailableOnLinux, to indicate that this functionality cannot be present 
>>> (as opposed to just leaving it blank).
>>> 
>>> What do you think?
>>> 
>>> $ git grep -c NSUnimplemented | sort -n -r -k2 -t:
>>> Foundation/NSExpression.swift:37
>>> Foundation/NSURLCache.swift:22
>>> Foundation/FileManager.swift:22
>>> Foundation/NSPort.swift:21
>>> Foundation/NSOrderedSet.swift:20
>>> Foundation/NSSortDescriptor.swift:19
>>> ...
>>> 
>>> ___
>>> 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] [swift-dev] Problems with dispatch?

[Alex Blewitt via swift-corelibs-dev]

> On 11 Oct 2017, at 22:03, Alex Blewitt via swift-dev  
> wrote:
> 
> On a recent test build there were compile errors with libdispatch, even after 
> a clean build:
> 
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_sub_4'
> src/libdispatch.so: error: undefined reference to '__atomic_load_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_add_4'
> src/libdispatch.so: error: undefined reference to 
> '__atomic_compare_exchange_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_or_4'
> src/libdispatch.so: error: undefined reference to '__atomic_fetch_and_4'
> src/libdispatch.so: error: undefined reference to '__atomic_store_4'
> src/libdispatch.so: error: undefined reference to '__atomic_exchange_4'
> clang-5.0: error: linker command failed with exit code 1 (use -v to see 
> invocation)

These problems have since been fixed, and foundation builds are going through 
as expected.

Alex

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

[swift-corelibs-dev] Problems with dispatch?

[Alex Blewitt via swift-corelibs-dev]

On a recent test build there were compile errors with libdispatch, even after a 
clean build:

src/libdispatch.so: error: undefined reference to '__atomic_fetch_sub_4'
src/libdispatch.so: error: undefined reference to '__atomic_load_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_add_4'
src/libdispatch.so: error: undefined reference to '__atomic_compare_exchange_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_or_4'
src/libdispatch.so: error: undefined reference to '__atomic_fetch_and_4'
src/libdispatch.so: error: undefined reference to '__atomic_store_4'
src/libdispatch.so: error: undefined reference to '__atomic_exchange_4'
clang-5.0: error: linker command failed with exit code 1 (use -v to see 
invocation)


https://ci.swift.org/job/swift-corelibs-foundation-PR-Linux/245/consoleFull#-12390007823122a513-f36a-4c87-8ed7-cbc36a1ec144
 


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


The changes aren't to do with libdispatch and shouldn't have caused these 
issues (they were related to test code only). 

Could this be due to recent build toolchain updates on the build servers?

Alex
___
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"

[Alex Blewitt via swift-corelibs-dev]

Can you file a bug at bugs.swift.org  with a minimal 
test case? It certainly sounds like a bug, and from the looks of the docker 
files, you're using the swift 4.0.2 release on Ubuntu 16.04.

If you can run the test under LLDB and put a breakpoint in that function, and 
get a backtrace (with 'bt') then it might be interesting to see where the 
deinit is being triggered, and give some kind of clue as to what is happening.

Alex

> On 16 Nov 2017, at 22:46, Brandon Williams via swift-corelibs-dev 
>  wrote:
> 
> 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 
>> > 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 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"

[Alex Blewitt via swift-corelibs-dev]

Thanks!

Alex

> On 17 Nov 2017, at 17:27, Brandon Williams  wrote:
> 
> I haven’t been able to find a minimal test case, but at least the test case I 
> linked to reproduces every time.
> 
> I’m not sure I’ll have time to search for a minimal case today, and I leave 
> for vacation tomorrow :/ perhaps when I get back.
> 
> I did at least file the bug report: https://bugs.swift.org/browse/SR-6422 
> 
> On Fri, Nov 17, 2017 at 4:48 AM Alex Blewitt  > wrote:
> Can you file a bug at bugs.swift.org  with a minimal 
> test case? It certainly sounds like a bug, and from the looks of the docker 
> files, you're using the swift 4.0.2 release on Ubuntu 16.04.
> 
> If you can run the test under LLDB and put a breakpoint in that function, and 
> get a backtrace (with 'bt') then it might be interesting to see where the 
> deinit is being triggered, and give some kind of clue as to what is happening.
> 
> Alex
> 
> 
>> On 16 Nov 2017, at 22:46, Brandon Williams via swift-corelibs-dev 
>> > wrote:
>> 
>> 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 
>>> > 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 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

[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