Re: [swift-users] Law of Exclusivity runtime false positive?

[Kyle Murray via swift-users]

Hi David,

Are padding or spacing computed properties that access either rectangle? They 
aren't defined in your stripped down code. For example:

var spacing: CGFloat {
return imageRect.maxX
}

Without doing something like that, I don't see the same access conflicts that 
you're seeing.

-Kyle

> On Jul 27, 2017, at 5:04 AM, David Hart via swift-users 
>  wrote:
> 
> Hello,
> 
> In Xcode 9 beta 4, Swift 4, I’m getting runtime errors popping up for 
> Simultaneous accesses and I think they may be false negatives. Here’s a 
> stripped down version of my code:
> 
> class MyButton: UIButton {
>   fileprivate var imageRect: CGRect = .zero
>   fileprivate var titleRect: CGRect = .zero
> 
> func updateRects() {
> if imageBeforeTitle {
> layoutHorizontally(leftRect: , rightRect: 
> )
> } else {
> layoutHorizontally(leftRect: , rightRect: 
> )
> }
> }
> 
> func layoutHorizontally(leftRect: inout CGRect, rightRect: inout 
> CGRect) {
> leftRect.origin.x = padding
> rightRect.origin.x = leftRect.maxX + spacing
> }
> }
> 
> While the layoutHorizontally method has two CGRect inout parameters, never in 
> my code do I pass the same CGRect. Any ideas if this is a bug I should post 
> on bugs.swift.org  or if I’m missing something?
> 
> David.
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

[swift-users] Law of Exclusivity runtime false positive?

[David Hart via swift-users]

Hello,

In Xcode 9 beta 4, Swift 4, I’m getting runtime errors popping up for 
Simultaneous accesses and I think they may be false negatives. Here’s a 
stripped down version of my code:

class MyButton: UIButton {
fileprivate var imageRect: CGRect = .zero
fileprivate var titleRect: CGRect = .zero

func updateRects() {
if imageBeforeTitle {
layoutHorizontally(leftRect: , rightRect: )
} else {
layoutHorizontally(leftRect: , rightRect: )
}
}

func layoutHorizontally(leftRect: inout CGRect, rightRect: inout 
CGRect) {
leftRect.origin.x = padding
rightRect.origin.x = leftRect.maxX + spacing
}
}

While the layoutHorizontally method has two CGRect inout parameters, never in 
my code do I pass the same CGRect. Any ideas if this is a bug I should post on 
bugs.swift.org or if I’m missing something?

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

Re: [swift-users] Swift linux repl can't import

[Alex Blewitt via swift-users]

For the mail (so it's easier to find than in a bug tracking system) the fix is 
to specify the clang include headers either with an -I on the swift invocation 
command line, or via the variables C_INCLUDE_PATH and CPLUS_INCLUDE_PATH

setting the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables to the 
Clang header include path did indeed work

$ export C_INCLUDE_PATH=/swift/usr/lib/swift/clang/include/
$ export CPLUS_INCLUDE_PATH=$C_INCLUDE_PATH
$
$ swift
Welcome to Swift version 4.0-dev (LLVM a15decabe3, Clang 14ff3d9712, Swift 
d574ed67d6). Type :help for assistance.
  1> import Foundation
  2> let status = "woohoo! 'import Foundation' works on Linux"
status: String = "woohoo! \'import Foundation\' works on Linux"

It really shouldn't be necessary to have to specify additional flags or 
variables to have Swift's REPL work out of the box on Linux, like it used to 
with Swift 3.0.

Alex

> On 26 Jul 2017, at 05:17, Mason Mark via swift-users  
> wrote:
> 
> Just to update the record, Matthias M. Schneider posted a workaround on 
> bugs.swift.org .
> 
> By setting the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH environment variables to 
> point to the Clang headers directory, it is possible to both import 
> Foundation in the REPL (without using -I to pass the header include path) and 
> also to debug a built executable with lldb.
> 
> Example is on the bug tracker:
> 
> https://bugs.swift.org/browse/SR-3648?focusedCommentId=27131=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27131
>  
> 
> 
> Cheers,
> 
> — Mason
> 
>> On Jul 12, 2017, at 13:16, Mason Mark via swift-users > > wrote:
>> 
>> I'm reviving this somewhat-old thread because it's still the most prominent 
>> search result when googling this issue to debug it (other than the 
>> below-referenced SR-3648).
>> 
>> The workaround of using -I to pass an include path to swift was working for 
>> me, because as noted by Will Stanton below, the issue was only coming up 
>> when trying to use the REPL on Linux (builds aren't affected).
>> 
>> However, the same issue comes up when debugging a swift executable on Linux 
>> using lldb, which I now need to do. So I'd love to know if anybody has found 
>> a workaround.
>> 
>> When you try to "po foo" in lldb, assuming foo is some object that uses 
>> Foundation, lldb errors out with a cascade of #include errors, ultimately 
>> ending with the same "error: 'stddef.h' file not found" (just like the REPL 
>> does).
>> 
>> I posted a comment to the official bug thread[1] which includes the full 
>> lldb output. 
>> 
>> My reason for posting to the list here is mainly to see if somebody has 
>> figured out a workaround, e.g.: 
>> 
>> - Does installing swift and all its stuff in /usr/lib help? 
>> 
>> - Is there some way to get lldb to do the equivalent of `swift -I 
>> ~/a-swift/usr/lib/swift/clang/include/`?
>> 
>> - Are there any versions of Linux where this issue does not occur? (Occurs 
>> for me with both Swift 3 and 4-dev, on Ubuntu 16.04.)
>> 
>> - etc.
>> 
>> Thanks for any pointers or tips. Unlike with the REPL case and its 
>> workaround, for trying to debug Swift executables on Linux this seems to be 
>> a show-stopper for me.
>> 
>> — Mason
>> 
>> 
>> [1]: https://bugs.swift.org/browse/SR-3648
>> 
>> 
>> 
>>> On Apr 5, 2017, at 11:53, Will Stanton via swift-users 
>>>  wrote:
>>> 
>>> From https://bugs.swift.org/browse/SR-3648, the work-around seems to be 
>>> passing -I /path/to/extracted/usr/lib/swift/clang/include when invoking 
>>> swift (credit Lukas and others, SR-3794 is more active)
>>> So, ex. `swift -I ~/a-swift/usr/lib/swift/clang/include/`
>>> 
>>> Fortunately, the issue has only come up for me in the REPL. `swift build` 
>>> works fine: I can build packages without an awkward -Xswiftc…
>>> 
>>> I wonder if the issue has anything to do with the clang-builtin-headers 
>>> install component? (Maybe swiftc/something gets hardcoded with a path 
>>> somewhere?)
>>> 
>>> Would be interested in learning more about install options, toolchains, and 
>>> the build! I’ve been wanting to track down for a while now, how does 
>>> --install-prefix affect the build? I’ve been relying on install_destdir to 
>>> get a swift...
>>> 
>>> Regards,
>>> Will Stanton
>>> 
 On Apr 4, 2017, at 9:17 PM, Rick Mann via swift-users 
  wrote:
 
 The installation instructions for Swift on Linux imply that the tarball 
 can be extracted anywhere, and the PATH set, and all should be well. But 
 unfortunately, while that's partly true, when I try to import packages, it 
 fails (Ubuntu 16.04 on Parallels on macOS 10.12.3):
 
 $ swift
 Welcome to Swift version 3.1