Re: [swift-dev] Starter project: Remove old mirrors

[Jean-Pierre Simard via swift-dev]

> Note that I'm already working on this part. The Swift runtime needs to
provide low-level reflection interfaces that allow the standard library to
implement Mirror without depending on private runtime ABI.

That's great to hear! Is there any chance that this work could introduce
type-level reflection APIs that would allow reflecting uninstantiated
types? Or should I make a formal proposal for this functionality in
swift-evolution?

On Mon, Dec 7, 2015 at 9:01 AM, Joe Groff via swift-dev  wrote:

>
> > On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev <
> swift-dev@swift.org> wrote:
> >
> > We need new runtime entry points that make sense for the new mirror
> > implementation.  The current entry points (the _reflect() function and
> > all its implementation details) directly depend on the old mirrors.
> > This step is slightly harder, but not doesn't require extraordinary
> > skills.  This part requires writing a proposal, because the runtime
> > API is going to be stable.
>
>
> Note that I'm already working on this part. The Swift runtime needs to
> provide low-level reflection interfaces that allow the standard library to
> implement Mirror without depending on private runtime ABI.
>
> -Joe
> ___
> 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] Starter project: Remove old mirrors

[Jean-Pierre Simard via swift-dev]

Thanks for sharing that, Slava! Reading that really helped me gain a better
understanding of how the current reflection model works and how it could be
extended.

Although my intended use cases are more for in-process type-level
reflection akin to objc_copyClassList and class_copyPropertyList.

In any case, swift-dev isn't the best place to discuss this, so I'll
synthesize my thoughts into a swift-evolution proposal shortly.

On Mon, Dec 7, 2015 at 11:51 PM, Slava Pestov  wrote:

> Hi Jean-Pierre,
>
>
> On Dec 7, 2015, at 12:21 PM, Jean-Pierre Simard via swift-dev <
> swift-dev@swift.org> wrote:
>
> > Note that I'm already working on this part. The Swift runtime needs to
> provide low-level reflection interfaces that allow the standard library to
> implement Mirror without depending on private runtime ABI.
>
> That's great to hear! Is there any chance that this work could introduce
> type-level reflection APIs that would allow reflecting uninstantiated
> types? Or should I make a formal proposal for this functionality in
> swift-evolution?
>
>
> There is a proposal for uninstantiated type metadata reflection in the
> GitHub repo in docs/proposals/RemoteMirrors.rst, but it might not cover
> your specific use-case. As Joe hinted, starting from concrete requirements
> is the best way forward here.
>
> Slava
>
>
> On Mon, Dec 7, 2015 at 9:01 AM, Joe Groff via swift-dev <
> swift-dev@swift.org> wrote:
>
>>
>> > On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev <
>> swift-dev@swift.org> wrote:
>> >
>> > We need new runtime entry points that make sense for the new mirror
>> > implementation.  The current entry points (the _reflect() function and
>> > all its implementation details) directly depend on the old mirrors.
>> > This step is slightly harder, but not doesn't require extraordinary
>> > skills.  This part requires writing a proposal, because the runtime
>> > API is going to be stable.
>>
>>
>> Note that I'm already working on this part. The Swift runtime needs to
>> provide low-level reflection interfaces that allow the standard library to
>> implement Mirror without depending on private runtime ABI.
>>
>> -Joe
>> ___
>> 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
>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-dev] MemoryError in SIL/parse_stdlib_X.sil tests when building toolchain on Ubuntu 15.10

[Jean-Pierre Simard via swift-dev]

Apologies if this is being tracked elsewhere, but I started getting these
failures when building the toolchain on Linux.

I triggered this by running utils/update-checkout --clone &&
utils/build-toolchain local.swift on a fresh machine. All other tests pass (
8457/8459).

Any thoughts as to why this may have started happening? Should I file a
ticket a JIRA about this?

On an unrelated note: is there a preset, or extra commands, to skip running
the tests when building the toolchain?

Thanks.

===

UNRESOLVED: Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil (8443 of 8459)
 TEST 'Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil'
FAILED 
Exception during script execution:
Traceback (most recent call last):
  File "/swift-development/llvm/utils/lit/lit/run.py", line 166, in
execute_test
result = test.config.test_format.execute(test, self.lit_config)
  File "/swift-development/swift/test/lit.cfg", line 175, in execute
result = super(SwiftTest, self).execute(test, litConfig)
  File "/swift-development/llvm/utils/lit/lit/formats/shtest.py", line 12,
in execute
self.execute_external)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 734, in
executeShTest
res = _runShTest(test, litConfig, useExternalSh, script, tmpBase)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 680, in
_runShTest
res = executeScript(test, litConfig, tmpBase, script, execdir)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 470, in
executeScript
timeout=litConfig.maxIndividualTestTime)
  File "/swift-development/llvm/utils/lit/lit/util.py", line 216, in
executeCommand
out,err = p.communicate(input=input)
  File "/usr/lib/python2.7/subprocess.py", line 799, in communicate
return self._communicate(input)
  File "/usr/lib/python2.7/subprocess.py", line 1417, in _communicate
stderr = ''.join(stderr)
MemoryError



UNRESOLVED: Swift(linux-x86_64) :: SIL/parse_stdlib_7.sil (8444 of 8459)
 TEST 'Swift(linux-x86_64) :: SIL/parse_stdlib_7.sil'
FAILED 
Exception during script execution:
Traceback (most recent call last):
  File "/swift-development/llvm/utils/lit/lit/run.py", line 166, in
execute_test
result = test.config.test_format.execute(test, self.lit_config)
  File "/swift-development/swift/test/lit.cfg", line 175, in execute
result = super(SwiftTest, self).execute(test, litConfig)
  File "/swift-development/llvm/utils/lit/lit/formats/shtest.py", line 12,
in execute
self.execute_external)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 734, in
executeShTest
res = _runShTest(test, litConfig, useExternalSh, script, tmpBase)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 680, in
_runShTest
res = executeScript(test, litConfig, tmpBase, script, execdir)
  File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 470, in
executeScript
timeout=litConfig.maxIndividualTestTime)
  File "/swift-development/llvm/utils/lit/lit/util.py", line 224, in
executeCommand
err = convert_string(err)
  File "/swift-development/llvm/utils/lit/lit/util.py", line 22, in
convert_string
return to_string(bytes.decode('utf-8'))
  File "/swift-development/llvm/utils/lit/lit/util.py", line 18, in
to_string
return to_bytes(bytes)
  File "/swift-development/llvm/utils/lit/lit/util.py", line 13, in to_bytes
return str.encode('utf-8')
MemoryError
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] MemoryError in SIL/parse_stdlib_X.sil tests when building toolchain on Ubuntu 15.10

[Jean-Pierre Simard via swift-dev]

Thanks Jordan, that fixed it! Sorry for the noise here, will go straight to
file a bug next time.

On Thu, 11 Aug 2016 at 10:26 Jordan Rose  wrote:

> I think this is the spew of deprecation warnings thing I was investigating
> yesterday. I just merged the fix for that, so try updating to the latest
> master and try again.
>
> Jordan
>
>
> On Aug 11, 2016, at 10:21, Mishal Shah via swift-dev 
> wrote:
>
> Hi,
>
> Can you please file a bug on bugs.swift.org? Can you please include the
> commit(sha) you started seeing this?
>
> Thanks,
> Mishal Shah
>
> On Aug 11, 2016, at 10:10 AM, Jean-Pierre Simard via swift-dev <
> swift-dev@swift.org> wrote:
>
> Apologies if this is being tracked elsewhere, but I started getting these
> failures when building the toolchain on Linux.
>
> I triggered this by running utils/update-checkout --clone &&
> utils/build-toolchain local.swift on a fresh machine. All other tests
> pass (8457/8459).
>
> Any thoughts as to why this may have started happening? Should I file a
> ticket a JIRA about this?
>
> On an unrelated note: is there a preset, or extra commands, to skip
> running the tests when building the toolchain?
>
> Thanks.
>
> ===
>
> UNRESOLVED: Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil (8443 of 8459)
>  TEST 'Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil'
> FAILED 
> Exception during script execution:
> Traceback (most recent call last):
>   File "/swift-development/llvm/utils/lit/lit/run.py", line 166, in
> execute_test
> result = test.config.test_format.execute(test, self.lit_config)
>   File "/swift-development/swift/test/lit.cfg", line 175, in execute
> result = super(SwiftTest, self).execute(test, litConfig)
>   File "/swift-development/llvm/utils/lit/lit/formats/shtest.py", line 12,
> in execute
> self.execute_external)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 734, in
> executeShTest
> res = _runShTest(test, litConfig, useExternalSh, script, tmpBase)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 680, in
> _runShTest
> res = executeScript(test, litConfig, tmpBase, script, execdir)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 470, in
> executeScript
> timeout=litConfig.maxIndividualTestTime)
>   File "/swift-development/llvm/utils/lit/lit/util.py", line 216, in
> executeCommand
> out,err = p.communicate(input=input)
>   File "/usr/lib/python2.7/subprocess.py", line 799, in communicate
> return self._communicate(input)
>   File "/usr/lib/python2.7/subprocess.py", line 1417, in _communicate
> stderr = ''.join(stderr)
> MemoryError
>
>
> 
> UNRESOLVED: Swift(linux-x86_64) :: SIL/parse_stdlib_7.sil (8444 of 8459)
>  TEST 'Swift(linux-x86_64) :: SIL/parse_stdlib_7.sil'
> FAILED 
> Exception during script execution:
> Traceback (most recent call last):
>   File "/swift-development/llvm/utils/lit/lit/run.py", line 166, in
> execute_test
> result = test.config.test_format.execute(test, self.lit_config)
>   File "/swift-development/swift/test/lit.cfg", line 175, in execute
> result = super(SwiftTest, self).execute(test, litConfig)
>   File "/swift-development/llvm/utils/lit/lit/formats/shtest.py", line 12,
> in execute
> self.execute_external)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 734, in
> executeShTest
> res = _runShTest(test, litConfig, useExternalSh, script, tmpBase)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 680, in
> _runShTest
> res = executeScript(test, litConfig, tmpBase, script, execdir)
>   File "/swift-development/llvm/utils/lit/lit/TestRunner.py", line 470, in
> executeScript
> timeout=litConfig.maxIndividualTestTime)
>   File "/swift-development/llvm/utils/lit/lit/util.py", line 224, in
> executeCommand
> err = convert_string(err)
>   File "/swift-development/llvm/utils/lit/lit/util.py", line 22, in
> convert_string
> return to_string(bytes.decode('utf-8'))
>   File "/swift-development/llvm/utils/lit/lit/util.py", line 18, in
> to_string
> return to_bytes(bytes)
>   File "/swift-development/llvm/utils/lit/lit/util.py", line 13, in
> to_bytes
> return str.encode('utf-8')
> MemoryError
>
> ___
> 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
>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7280

[Jean-Pierre Simard via swift-dev]

Made a PR to update the SwiftPM side of things:
https://github.com/apple/swift-package-manager/pull/601

On Fri, 12 Aug 2016 at 18:33  wrote:

> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7280]
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7280/
> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build: Fri, 12 Aug 2016 18:31:45 -0700
> Build duration: 1 min 42 sec Identified problems:
>
>- Compile Error: This build failed because of a compile error. Below
>is a list of all errors in the build log:
>   - Indication 1
>   
> 
>
> Tests:
> Name: *Swift(linux-x86_64)*
> Failed: 0 test(s), Passed: 8231 test(s), Total: 8231 test(s)
> Name: *Swift-Unit*
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>
> Changes
>
>- Commit *ef6a425819a659915137f9bec726f1d966e3586a* by *jp:*
>
>change ProcessInfo.processinfo() to processinfo
>- *edit*: Sources/XCTest/Private/WallClockTimeMetric.swift
>
>- Commit *c0794f0a26405c29e7042f624f67634d8272582b* by *mamabusi:*
>
>Modify NSCharacterSet api defined in NSURL file to align with that of
>- *edit*: Foundation/NSURL.swift
>   - *edit*: TestFoundation/TestNSURL.swift
>
>- Commit *188d257b10f5294a4361569df760e508bd30669a* by *github:*
>
>Attempt to address test resilience issue
>- *edit*: TestFoundation/TestNSTask.swift
>
>- Commit *59549c9f519e230a3b61a9126582260dbe0ec659* by
>*anthony.parker:*
>
>change ProcessInfo.processinfo() class func to processinfo static let
>- *edit*: Foundation/NSPathUtilities.swift
>   - *edit*: Foundation/NSProcessInfo.swift
>   - *edit*: TestFoundation/TestNSProcessInfo.swift
>   - *edit*: TestFoundation/TestNSURL.swift
>   - *edit*: Tools/plutil/main.swift
>
>
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Shipping sourcekitd-test/repl with Swift

[Jean-Pierre Simard via swift-dev]

Before SourceKit-related functionality can be considered for inclusion in
release packages for Linux, it needs to be able to be built during "normal"
invocation of the build script. I say normal because it's possible to build
SourceKit with two (simple) invocations of the build script at the moment:
https://github.com/apple/swift/pull/3594#issuecomment-234169759

The reason SourceKit can't currently be built in a single pass is that it
depends on libdispatch, which has a dependency on Swift for its overlay and
so is built _after_ Swift, but SourceKit is part of the Swift project. This
is only a problem on Linux because SourceKit can use the system's
libdispatch rather than the corelibs one when building on OS X.

Here are different ideas for addressing this circular dependency:

1. Break SourceKit out into a different CMake "project". This way, the
build script would build Swift -> libdispatch -> SourceKit. This is
probably the most elegant solution.
2. Build libdispatch twice: once before building Swift (without its
overlay) and again with its overlay. This is probably the easiest and most
naive way to solve this, but is potentially wasteful since we're building
it twice. Actually probably not, assuming the build cache is reused
effectively. But it's certainly not pretty.
3. Remove SourceKit's dependency on libdispatch. I dislike this option
because rewriting the libdispatch parts of SK with libpthread or C++14
builtins would be a sizable undertaking and the codebase would suffer for
it.

I'm sure there are other approaches that could work but I'm not aware of
them.

This is being tracked as SR-1676, which is currently unassigned:
https://bugs.swift.org/browse/SR-1676

On Mon, 29 Aug 2016 at 20:25 Keith Smiley via swift-dev 
wrote:

> Sorry to bump this thread, just wondering if anyone has any thoughts on
> this now that (some) of the Swift 3.0 craziness is done.
>
> --
> Keith Smiley
>
> On Sun, Jul 31, 2016, at 21:46, Keith Smiley via swift-dev wrote:
> > Hey everyone,
> >
> > Recently I've been working on making Swift autocomplete outside of Xcode
> > (specifically vim). Of course to do this, I've been using
> > [SourceKitten][0],
> > which is a great bridge for interacting with `sourcekitd`.
> >
> > While working on this, I also ran across `sourcekitd-test` and
> > `sourcekitd-repl`
> > from the Swift repo. These tools are also awesome for working with
> > `sourcekitd`.
> > `sourcekitd-test` even has practically the same command line interface as
> > SourceKitten's complete command.
> >
> > With `sourcekitd-test`:
> >
> > ```
> > $ sourcekitd-test -req=complete -offset=x file.swift -- [compiler args]
> > ```
> >
> > With SourceKitten:
> >
> > ```
> > $ sourcekitten complete --offset x --file file.swift -- [compiler args]
> > ```
> >
> > These 2 commands of course call through to `sourcekitd` in the same way,
> > so this
> > ends up with the same output as well.
> >
> > All of this is just to show that I think these tools would be extremely
> > valuable
> > to have shipped with whichever Swift toolchains are bundled with Xcode,
> > so users
> > would automatically have tools for completion installed.
> >
> > I'd love to hear some thoughts on this, and also if it's even a feasible
> > thing
> > to ask for. Also let me know if this post would be better suited for
> > another
> > list. I didn't feel like this was particularly appropriate for
> > swift-evolution
> > since there aren't really any implementation details in question here.
> >
> >
> > [0]: https://github.com/jpsim/SourceKitten
> >
> >
> > Thanks for reading!
> >
> > --
> > Keith Smiley
> >
> > ___
> > 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
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [SourceKit] NSRange, Swift.String, and NSString

[Jean-Pierre Simard via swift-dev]

I ended up writing some convenience APIs to perform these conversions along
with many other useful SourceKit<->Cocoa conversions like line+column,
UTF-8, UTF-16 and String.Index in SourceKitten. It's MIT-licensed so feel
free to grab the String extensions from the project yourself:
https://github.com/jpsim/SourceKitten/blob/master/Source/SourceKittenFramework/String+SourceKitten.swift

That being said, you might have an easier time working with SourceKitten
than with with SourceKit directly, since it does a whole lot more, like
dynamically resolving+loading which SourceKit to use, caching expensive
operations, easier multi-threaded access, generating documentation, etc.

On Fri, 24 Mar 2017 at 10:59 Tyler Stromberg via swift-dev <
swift-dev@swift.org> wrote:

> I'm currently working on integrating SourceKit with a macOS application.
> AppKit APIs (e.g. NSAttributedString, NSLayoutManager, etc) deal in terms
> of NSRange (UTF-16 code units?). SourceKit, however, deals in terms of
> integer offsets and lengths (UTF-8 code units?). Is there a more efficient
> or easier way to convert back and forth between the two other than doing
> the index(_:offsetBy:) -> samePosition(in:) dance?
> ___
> 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] Nested multi-line string literals

[Jean-Pierre Simard via swift-dev]

Looks like both those cases are supported based on similar tests here:
https://github.com/apple/swift/blob/master/test/Parse/multiline_string.swift

Should be available in snapshots
`swift-4.0-DEVELOPMENT-SNAPSHOT-2017-05-09-a` onwards.

On Wed, 31 May 2017 at 13:59 Nathan Hawes via swift-dev 
wrote:

> Hey all,
>
> I’ve been playing with multi-line string literals recently and was
> wondering, are the below cases supported intentionally or did they just
> fall out of the implementation?
>
> 1) Nested multi-line strings:
>
> let x = """
> outer multi-line
> \(
>   """
> inner multiline
>   """
> )
> outer multi-line
> """
> print(x)
>
>
> 2) Multi-line strings nested in "single-line" strings:
>
> let x = "outer string \( """
> inner multiline
>   """) outer string"
> print(x)
>
> I’ve been looking at still syntax highlighting strings in the invalid
> states they pass through while writing or editing them, and trying to keep
> any changes to the file’s highlighted ranges as localized as possible. At
> the moment when you open an interpolation in an otherwise terminated
> multi-line string literal you get one giant  unknown token – an
> unterminated string – from the opening triple quotes, past the ‘closing’
> triple quotes (that we treat as nested opening quotes), to the end of the
> file.
>
> It’d be great to be able to bound the unknown token to what were more
> likely intended to be closing quotes, so we still produce tokens for (and
> syntax highlight) the rest of the file. Of course with nesting you can’t be
> sure they’re closing quotes though, so I wanted to check if the nesting
> support was intentional.
>
> Thanks!
> Nathan
> ___
> 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