Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

[Michael Gottesman via swift-dev]

> On Oct 4, 2016, at 1:04 PM, John McCall  wrote:
> 
>> 
>> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev 
>> > wrote:
>> 
>> The document attached below contains the first "Semantic ARC" mini proposal: 
>> the High Level ARC Memory Operations Proposal.
>> 
>> An html rendered version of this markdown document is available at the 
>> following URL:
>> 
>> https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html 
>> 
>> 
>> 
>> 
>> # Summary
>> 
>> This document proposes:
>> 
>> 1. adding the `load_strong`, `store_strong` instructions to SIL. These can 
>> only
>>be used with memory locations of `non-trivial` type.
> 
> I would really like to avoid using the word "strong" here.  Under the current 
> proposal, these instructions will be usable with arbitrary non-trivial types, 
> not just primitive class references.  Even if you think of an aggregate that 
> happens to contain one or more strong references as some sort of aggregate 
> strong reference (which is questionable but not completely absurd), we 
> already have loadable non-strong class references that this operation would 
> be usable with, like native unowned references.  "load_strong %0 : 
> $*@sil_unowned T" as an operation yielding a scalar "@sil_unowned T" is 
> ridiculous, and it will only get more ridiculous when we eventually allow 
> this operation to work with types that are currently address-only, like weak 
> references.
> 
> Brainstorming:
> 
> Something like load_copy and store_copy would be a bit unfortunate, since 
> store_copy doesn't actually copy the source operand and we want to have a 
> load_copy [take].
> 
> load_value and store_value seem excessively generic.  It's not like 
> non-trivial types aren't values.
> 
> One question that comes to mind: do we actually need new instructions here 
> other than for staging purposes?  We don't actually need new instructions for 
> pseudo-linear SIL to work; we just need to say that we only enforce 
> pseudo-linearity for non-trivial types.
> 
> If we just want the instruction to be explicit about ownership so that we can 
> easily distinguish these cases, we can make the rule always explicit, e.g.:
>   load [take] %0 : $*MyClass
>   load [copy] %0 : $*MyClass
>   load [trivial] %0 : $*Int
> 
>   store %0 to [initialization] %1 : $*MyClass
>   store %0 to [assignment] %1 : $*MyClass
>   store %0 to [trivial] %1 : $*Int
> 
> John.

The reason why I originally suggested to go the load_strong route is that we 
already have load_weak, load_unowned instructions. If I could add a load_strong 
instruction, then it would make sense to assign an engineer to do a pass over 
all 3 of these instructions and combine them into 1 load instruction. That is, 
first transform into a form amenable for canonicalization and then canonicalize 
all at once.

As you pointed out, both load_unowned and load_weak involve representation 
changes in type (for instance the change of weak pointers to Optional). Such 
a change would be against the "spirit" of a load instruction to perform such 
representation changes versus ownership changes.

In terms of the properties that we actually want here, what is important is 
that we can verify that no non-trivially typed values are loaded in an unsafe 
unowned manner. That can be done also with ownership flags on load/store.

Does this sound reasonable:

1. We introduce two enums that define memory ownership changes, one for load 
and one for store. Both of these enums will contain a [trivial] ownership.
2. We enforce in the verifier that non-trivial types must have a non-trivial 
ownership modifier on any memory operations that they are involved in.

Michael

> 
>> 2. banning the use of `load`, `store` on values of `non-trivial` type.
>> 
>> This will allow for:
>> 
>> 1. eliminating optimizer miscompiles that occur due to releases being moved 
>> into
>>the region in between a `load`/`retain`, `load`/`release`,
>>`store`/`release`. (For a specific example, see the appendix).
>> 2. modeling `load`/`store` as having `unsafe unowned` ownership semantics. 
>> This
>>will be enforced via the verifier.
>> 3. more aggressive ARC code motion.
>> 
>> # Definitions
>> 
>> ## load_strong
>> 
>> We propose three different forms of load_strong differentiated via flags. 
>> First
>> define `load_strong` as follows:
>> 
>> %x = load_strong %x_ptr : $*C
>> 
>>   =>
>> 
>> %x = load %x_ptr : $*C
>> retain_value %x : $C
>> 
>> Then define `load_strong [take]` as:
>> 
>> %x = load_strong [take] %x_ptr : $*Builtin.NativeObject
>> 
>>   =>
>> 
>> %x = load %x_ptr : $*Builtin.NativeObject
>> 
>> **NOTE** `load_strong [take]` implies that the loaded from memory location no
>> longer owns the result object (i.e. a take is a move). Loading from the 
>> memory
>> location 

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

[Mark Lacey via swift-dev]

> On Oct 5, 2016, at 3:37 PM, Ben Asher  wrote:
> 
> I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe 
> 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's 
> some improvement, but I'm not exactly sure what kind of improvement was 
> expected.

The kind of benefit you might expect really depends on the specific code you’ve 
written. The changes I have in mind attempt to speed up the expression type 
checker (the thing that does the work of inferring types for a given 
expression, and the case where there is an explicit type the expression needs 
to type-check to, ensuring that it does). These expressions include things like 
array literals and dictionary literals, where we sometimes take a long time to 
type check.

> Is there any profiling/tracing you all would recommend to help find problem 
> areas?

If you’re looking for problem areas in your particular build, I have a couple 
suggestions:

1. Take a look at the output of -debug-time-function-bodies to see if the same 
function is getting type checked multiple times, and determine what the 
cumulative time for those functions is.

For example below is the output I see for a simple test case. Note that the 
getter/setter that are generated from a property on line 2 of two.swift are 
type checked twice. Although in this case we type check the individual 
functions very quickly, if you have enough of this kind of redundant type 
checking happening, it can add up. This *particular* case is a known bug that 
we hope to address - the synthesized getters/setters for properties are type 
checked in each file they are referenced in.

There may be other cases like this that we’re not already aware of, so it’s 
always good to open a bug if you find something like this.

swiftc -c main.swift two.swift -module-name test -Xfrontend 
-debug-time-function-bodies
0.2ms   main.swift:2:7  get {}
0.2ms   main.swift:2:7  set {}
0.0ms   main.swift:1:7  @objc deinit
0.3ms   main.swift:1:13 override init()
0.2ms   two.swift:2:14  get {}
0.2ms   two.swift:2:14  set {}
0.2ms   two.swift:2:14  get {}
0.2ms   two.swift:2:14  set {}
0.0ms   two.swift:1:14  @objc deinit
0.0ms   two.swift:1:14  init()

2. Add a timer for expression type checking and see if that helps narrow down 
whether there is time being spent type checking expressions that isn’t 
accounted for in -debug-time-function-bodies. There are a few places that might 
make sense for this, but I suspect ConstraintSystem::solve() might be the best. 
This is ultimately called from a variety of places, and would provide the most 
insight into where time is being spent in the expression type checking. It’s 
possible something higher up the stack, like TypeChecker::solveForExpression or 
TypeChecker::typeCheckExpression() might make more sense as well. You can model 
this on how -debug-time-function-bodies is currently implemented, e.g. look at 
swift::performTypeChecking for some help on getting started. I’ll probably try 
to add this timer myself in the next few weeks if you don’t manage to beat me 
to it.

Mark


> I don't mind building from Swift master, using someone's preferred profiling 
> tools, etc. I'm not really sure where to start.
> 
> Ben
> 
> On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher  > wrote:
> Apologies for not starting off with system info: macOS Sierra (10.12.0), 
> Xcode 8.0 (from the App Store).
> 
> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open a 
> ticket for improving -debug-time-function-bodies if I can confirm anything.
> 
> Thanks!
> 
> Ben
> 
> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey  > wrote:
> 
>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev > > wrote:
>> 
>> Hello! I work with a large project (~900 .swift files and more .m files). We 
>> have a nightly job that compiles the app and calls out function bodies 
>> (using -debug-time-function-bodies) that are slower than 100ms to compile. 
>> Since upgrading to Swift 3, the number of trouble function bodies has one 
>> from > 150 to < 20, so we're really happy about that! The only issue though 
>> is that build time overall increased by ~1 min (amount of time to build all 
>> targets before automatically merging to master in our integration build).
> 
> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or with 
> one of the toolchain builds from swift.org ?
> 
> Xcode 8.1 beta 2 includes some type checker performance improvements which 
> might have an impact here.
> 
>> 
>> To dig into this further, we've started a new nightly job that builds the 
>> app using the -debug-time-compilation flag, and using that we've found that 
>> some files take as long as 2-3 seconds to compile. But, there's no targeted 
>> output to help us get this down via the 

Re: [swift-dev] [swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

[Todd Fiala via swift-dev]

> On Oct 5, 2016, at 3:20 PM, Rex Fenley via swift-lldb-dev 
>  wrote:
> 
> I'm using the most recent cmake. I also blew away the lldb directory and 
> tried to rebuild but still ended up with "error: unknown setting: 
> cmark-cmake-options" when building desktop :(
> 

Okay.  I think you want to take that up with the swift-dev group.

Swift-dev folks - any of you know anything about the build-script error that 
Rex has reported?  He’s getting this on a clean build tree: "error: unknown 
setting: cmark-cmake-options”.

Rex, can you file a radar on bugs.swift.org ?

Thanks!

-Todd

> On Wed, Oct 5, 2016 at 2:48 PM, Todd Fiala  > wrote:
> 
>> On Oct 5, 2016, at 2:36 PM, Rex Fenley > > wrote:
>> 
>> Hey Todd, thanks for the info!
>> 
>> I was attempting to build from the LLDM scheme. The only errors were the two 
>> I provided, I'll post more information at the bottom. When trying the 
>> "desktop" scheme I get the following:
> 
> Okay - switch to the desktop scheme; otherwise, you’ll be missing some 
> components.  (That is not particularly well documented - the LLDB scheme is 
> literally for the LLDB.framework, but not everything).
>> "debugserver" isn't code signed but requires entitlements. It is not 
>> possible to add entitlements to a binary without signing it.
>> 
>> 
> 
> You have a couple options there.
> 
> 1. If you follow the docs in lldb/docs/code-signing.txt, your debugserver 
> will be usable regardless of that message.
> 
> 2. [Preferred] Alternatively, you can set the Xcode build variable 
> DEBUGSERVER_USE_FROM_SYSTEM=1, either via an xcodebuild command line, or by 
> setting it directly in your Xcode settings.  It’s not enough for it to be an 
> environment variable set.  If you go with this, the debugserver will be 
> copied from your Xcode into the built LLDB, which will then be an official 
> Apple-signed debugserver.  Unless you are changing debugserver, that is 
> generally the way to go.  A fair amount of the Swift CI runs in this 
> configuration.  (Although not everything, as we really do change debugserver 
> and want to test those changes.)
> 
> The xcodebuild line with that set would be:
> $ cd your/lldb/source/root
> $ xcodebuild -scheme desktop DEBUGSERVER_USE_FROM_SYSTEM=1
> 
> Let me know if that gets you further.
> 
>> 
>> I don't know if syncing is the issue, I simply git cloned swift-lldb from 
>> github and went to the tag "swift-3.0-RELEASE" and built.
>> 
>> more info from LLDB scheme errors:
>> bootstrapping ninja...
>> 
>> warning: A compatible version of re2c (>= 0.11.3) was not found; changes to 
>> src/*.in.cc  will not affect your build.
>> 
>> wrote build.ninja.
>> 
>> bootstrap complete.  rebuilding...
>> 
>> + popd
>> 
>> + env 
>> HOST_VARIABLE_macosx_x86_64__SWIFT_BENCHMARK_TARGETS=swift-benchmark-macosx-x86_64
>>  
>> HOST_VARIABLE_macosx_x86_64__SWIFT_RUN_BENCHMARK_TARGETS=check-swift-benchmark-macosx-x86_64
>>  'HOST_VARIABLE_macosx_x86_64__SWIFT_SDKS=IOS IOS_SIMULATOR OSX TVOS 
>> TVOS_SIMULATOR WATCHOS WATCHOS_SIMULATOR' 
>> HOST_VARIABLE_macosx_x86_64__SWIFT_STDLIB_TARGETS=swift-test-stdlib-macosx-x86_64
>>  HOST_VARIABLE_macosx_x86_64__SWIFT_TEST_TARGETS= caffeinate 
>> /Users/Rex/Documents/projects/swift-lldb/swift/utils/build-script-impl 
>> --workspace /Users/Rex/Documents/projects/swift-lldb --build-dir 
>> /Users/Rex/Documents/projects/swift-lldb/llvm-build/Ninja-RelWithDebInfoAssert
>>  --install-prefix 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr
>>  --host-target macosx-x86_64 --stdlib-deployment-targets 'macosx-x86_64 
>> iphonesimulator-i386 iphonesimulator-x86_64 appletvsimulator-x86_64 
>> watchsimulator-i386 iphoneos-armv7 iphoneos-armv7s iphoneos-arm64 
>> appletvos-arm64 watchos-armv7k' --host-cc 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  --host-cxx 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>>  --darwin-xcrun-toolchain default --darwin-deployment-version-osx=10.9 
>> --darwin-deployment-version-ios=7.0 --darwin-deployment-version-tvos=9.0 
>> --darwin-deployment-version-watchos=2.0 --cmake /usr/local/bin/cmake 
>> --cmark-build-type RelWithDebInfo --llvm-build-type RelWithDebInfo 
>> --swift-build-type RelWithDebInfo --swift-stdlib-build-type RelWithDebInfo 
>> --lldb-build-type RelWithDebInfo --foundation-build-type RelWithDebInfo 
>> --libdispatch-build-type RelWithDebInfo --xctest-build-type RelWithDebInfo 
>> --swift-enable-assertions true --swift-stdlib-enable-assertions true 
>> --swift-analyze-code-coverage false --cmake-generator Ninja --build-jobs 8 
>> '--common-cmake-options=-G Ninja 
>> -DCMAKE_C_COMPILER:PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  
>> 

Re: [swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

[Todd Fiala via swift-lldb-dev]

> On Oct 5, 2016, at 3:20 PM, Rex Fenley via swift-lldb-dev 
>  wrote:
> 
> I'm using the most recent cmake. I also blew away the lldb directory and 
> tried to rebuild but still ended up with "error: unknown setting: 
> cmark-cmake-options" when building desktop :(
> 

Okay.  I think you want to take that up with the swift-dev group.

Swift-dev folks - any of you know anything about the build-script error that 
Rex has reported?  He’s getting this on a clean build tree: "error: unknown 
setting: cmark-cmake-options”.

Rex, can you file a radar on bugs.swift.org ?

Thanks!

-Todd

> On Wed, Oct 5, 2016 at 2:48 PM, Todd Fiala  > wrote:
> 
>> On Oct 5, 2016, at 2:36 PM, Rex Fenley > > wrote:
>> 
>> Hey Todd, thanks for the info!
>> 
>> I was attempting to build from the LLDM scheme. The only errors were the two 
>> I provided, I'll post more information at the bottom. When trying the 
>> "desktop" scheme I get the following:
> 
> Okay - switch to the desktop scheme; otherwise, you’ll be missing some 
> components.  (That is not particularly well documented - the LLDB scheme is 
> literally for the LLDB.framework, but not everything).
>> "debugserver" isn't code signed but requires entitlements. It is not 
>> possible to add entitlements to a binary without signing it.
>> 
>> 
> 
> You have a couple options there.
> 
> 1. If you follow the docs in lldb/docs/code-signing.txt, your debugserver 
> will be usable regardless of that message.
> 
> 2. [Preferred] Alternatively, you can set the Xcode build variable 
> DEBUGSERVER_USE_FROM_SYSTEM=1, either via an xcodebuild command line, or by 
> setting it directly in your Xcode settings.  It’s not enough for it to be an 
> environment variable set.  If you go with this, the debugserver will be 
> copied from your Xcode into the built LLDB, which will then be an official 
> Apple-signed debugserver.  Unless you are changing debugserver, that is 
> generally the way to go.  A fair amount of the Swift CI runs in this 
> configuration.  (Although not everything, as we really do change debugserver 
> and want to test those changes.)
> 
> The xcodebuild line with that set would be:
> $ cd your/lldb/source/root
> $ xcodebuild -scheme desktop DEBUGSERVER_USE_FROM_SYSTEM=1
> 
> Let me know if that gets you further.
> 
>> 
>> I don't know if syncing is the issue, I simply git cloned swift-lldb from 
>> github and went to the tag "swift-3.0-RELEASE" and built.
>> 
>> more info from LLDB scheme errors:
>> bootstrapping ninja...
>> 
>> warning: A compatible version of re2c (>= 0.11.3) was not found; changes to 
>> src/*.in.cc  will not affect your build.
>> 
>> wrote build.ninja.
>> 
>> bootstrap complete.  rebuilding...
>> 
>> + popd
>> 
>> + env 
>> HOST_VARIABLE_macosx_x86_64__SWIFT_BENCHMARK_TARGETS=swift-benchmark-macosx-x86_64
>>  
>> HOST_VARIABLE_macosx_x86_64__SWIFT_RUN_BENCHMARK_TARGETS=check-swift-benchmark-macosx-x86_64
>>  'HOST_VARIABLE_macosx_x86_64__SWIFT_SDKS=IOS IOS_SIMULATOR OSX TVOS 
>> TVOS_SIMULATOR WATCHOS WATCHOS_SIMULATOR' 
>> HOST_VARIABLE_macosx_x86_64__SWIFT_STDLIB_TARGETS=swift-test-stdlib-macosx-x86_64
>>  HOST_VARIABLE_macosx_x86_64__SWIFT_TEST_TARGETS= caffeinate 
>> /Users/Rex/Documents/projects/swift-lldb/swift/utils/build-script-impl 
>> --workspace /Users/Rex/Documents/projects/swift-lldb --build-dir 
>> /Users/Rex/Documents/projects/swift-lldb/llvm-build/Ninja-RelWithDebInfoAssert
>>  --install-prefix 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr
>>  --host-target macosx-x86_64 --stdlib-deployment-targets 'macosx-x86_64 
>> iphonesimulator-i386 iphonesimulator-x86_64 appletvsimulator-x86_64 
>> watchsimulator-i386 iphoneos-armv7 iphoneos-armv7s iphoneos-arm64 
>> appletvos-arm64 watchos-armv7k' --host-cc 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  --host-cxx 
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>>  --darwin-xcrun-toolchain default --darwin-deployment-version-osx=10.9 
>> --darwin-deployment-version-ios=7.0 --darwin-deployment-version-tvos=9.0 
>> --darwin-deployment-version-watchos=2.0 --cmake /usr/local/bin/cmake 
>> --cmark-build-type RelWithDebInfo --llvm-build-type RelWithDebInfo 
>> --swift-build-type RelWithDebInfo --swift-stdlib-build-type RelWithDebInfo 
>> --lldb-build-type RelWithDebInfo --foundation-build-type RelWithDebInfo 
>> --libdispatch-build-type RelWithDebInfo --xctest-build-type RelWithDebInfo 
>> --swift-enable-assertions true --swift-stdlib-enable-assertions true 
>> --swift-analyze-code-coverage false --cmake-generator Ninja --build-jobs 8 
>> '--common-cmake-options=-G Ninja 
>> -DCMAKE_C_COMPILER:PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
>>  
>> 

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

[Ben Asher via swift-dev]

I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems
maybe 15s faster (to build our main huge target): 7m28s compared to 7m43s.
It's some improvement, but I'm not exactly sure what kind of improvement
was expected.

Is there any profiling/tracing you all would recommend to help find problem
areas? I don't mind building from Swift master, using someone's preferred
profiling tools, etc. I'm not really sure where to start.

Ben

On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher  wrote:

> Apologies for not starting off with system info: macOS Sierra (10.12.0),
> Xcode 8.0 (from the App Store).
>
> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open
> a ticket for improving -debug-time-function-bodies if I can confirm
> anything.
>
> Thanks!
>
> Ben
>
> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey  wrote:
>
>>
>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev 
>> wrote:
>>
>> Hello! I work with a large project (~900 .swift files and more .m files).
>> We have a nightly job that compiles the app and calls out function bodies
>> (using -debug-time-function-bodies) that are slower than 100ms to
>> compile. Since upgrading to Swift 3, the number of trouble function bodies
>> has one from > 150 to < 20, so we're really happy about that! The only
>> issue though is that build time overall increased by ~1 min (amount of time
>> to build all targets before automatically merging to master in our
>> integration build).
>>
>>
>> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or
>> with one of the toolchain builds from swift.org?
>>
>> Xcode 8.1 beta 2 includes some type checker performance improvements
>> which might have an impact here.
>>
>>
>> To dig into this further, we've started a new nightly job that builds the
>> app using the -debug-time-compilation flag, and using that we've found that
>> some files take as long as 2-3 seconds to compile. But, there's no targeted
>> output to help us get this down via the -debug-time-function-bodies flag
>> (i.e. no function bodies that we can refactor to get compile times much
>> faster).
>>
>>
>> One thing to look out for here is that I believe there are some cases
>> where -debug-time-function-bodies isn’t reporting type checking time. From
>> my (potentially faulty) recollection, things like let bindings with
>> literals or closures on the right hand side do not show up in the
>> -debug-time-function-bodies output, and depending on the specifics of the
>> expression these can sometimes take a long time to type check. When these
>> appear within the body of another type declaration they can end up getting
>> type checked multiple times during a full project build, and that time can
>> add up.
>>
>> I don’t believe there is a bug open for improving
>> -debug-time-function-bodies to help diagnose this, but opening a bug would
>> be appreciated if you can confirm that this is the case, and of course
>> patches to fix it are definitely welcome as well.
>>
>> Mark
>>
>> We can see that most of the time is spent in "Type checking / Semantic
>> analysis" for these problem files, but we don't currently have any way of
>> knowing what that means. It feels like we've exhausted the available
>> options at this point (unless there are other flags I'm missing) in terms
>> of existing actionable debugging/profiling/reporting, so now our question
>> is this: what kind of reports would Swift maintainers be interested in
>> seeing in terms of output from profiling tools, etc. to help debug/diagnose
>> these slow compile issues? We're willing to devote time to tooling to help
>> generate such reports and file bugs.
>>
>> Thanks!
>>
>> Ben
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>>
>
>
> --
> -Ben
>



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

[swift-lldb-dev] Building and running swift-lldb from Xcode not working :(

[Rex Fenley via swift-lldb-dev]

Hey swift lldb team!

I tried building the LLDB target from within Xcode. However, I get the
following error during compilation:

subprocess.CalledProcessError: Command '['python', '/Users/Rex/Documents/
projects/swift-lldb/llvm/tools/swift/utils/build-script',
'--preset=LLDB_Swift_ReleaseAssert', 'swift_install_destdir=/Users/
Rex/Documents/projects/swift-lldb/llvm-build/ReleaseAssert/swift-macosx-x86_64']'
returned non-zero exit status 1

And much further up I see

warning: A compatible version of re2c (>= 0.11.3) was not found; changes to
src/*.in.cc will not affect your build.

and

error: unknown setting: cmark-cmake-options

How may I fix this/these issues to build and run lldb from Xcode?

Thanks :)

-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 
 |  FOLLOW
US   |  LIKE US

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

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

[Ben Asher via swift-dev]

I didn't know about that warning, so thanks for sharing that! Having this
enabled will help somewhat, at least in terms of keeping specific
slow-to-compile functions out of our master branch.

That said, I understand Jordan's response (in SR-2741) of being "leery of
'productizing'" these flags. Developing with Swift shouldn't involve
fighting the compiler to get the best compile time, so making this more
than a debug flag does seem odd/worrisome.

I'm more interested in the best way to get a feedback loop to understand
what the known issues are and see them addressed. This has already worked
well with fixes for big slowdown issues like SR-1277 and this well known
patch:
https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03
.

On Wed, Oct 5, 2016 at 11:47 AM, Brian Gesiak  wrote:

> Hi Ben,
>
> I'd really like to see improvements here as well. I don't know what
> reports would be useful to the Swift team, but allow me to point out
> https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea
> 75bc09cbd5, which adds a -warn-long-function-bodies option that you may
> be able to use.
>
> However, as stated in the commit message I linked to above, both
> -debug-time-function-bodies and -warn-long-function-bodies are frontend
> options. They are not officially supported, and may be removed at any time
> without warning.
>
> Personally, I think the Swift compiler should provide users with more
> information about compilation times. In https://bugs.swift.org/
> browse/SR-2741, Brian Michel (cc'ed) describes a feature he'd like to
> see: structured output from the Swift compiler driver, as an official,
> supported option. Your team's use case sounds very similar to his, so I'd
> encourage you to chime in on that issue with your thoughts.
>
> - Brian Gesiak
>
>
> On Tue, Oct 4, 2016 at 5:38 PM, Ben Asher via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Hello! I work with a large project (~900 .swift files and more .m files).
>> We have a nightly job that compiles the app and calls out function bodies
>> (using -debug-time-function-bodies) that are slower than 100ms to
>> compile. Since upgrading to Swift 3, the number of trouble function bodies
>> has one from > 150 to < 20, so we're really happy about that! The only
>> issue though is that build time overall increased by ~1 min (amount of time
>> to build all targets before automatically merging to master in our
>> integration build).
>>
>> To dig into this further, we've started a new nightly job that builds the
>> app using the -debug-time-compilation flag, and using that we've found that
>> some files take as long as 2-3 seconds to compile. But, there's no targeted
>> output to help us get this down via the -debug-time-function-bodies flag
>> (i.e. no function bodies that we can refactor to get compile times much
>> faster). We can see that most of the time is spent in "Type checking /
>> Semantic analysis" for these problem files, but we don't currently have any
>> way of knowing what that means. It feels like we've exhausted the available
>> options at this point (unless there are other flags I'm missing) in terms
>> of existing actionable debugging/profiling/reporting, so now our question
>> is this: what kind of reports would Swift maintainers be interested in
>> seeing in terms of output from profiling tools, etc. to help debug/diagnose
>> these slow compile issues? We're willing to devote time to tooling to help
>> generate such reports and file bugs.
>>
>> Thanks!
>>
>> Ben
>>
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>


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

Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time

[Mark Lacey via swift-dev]

> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev  
> wrote:
> 
> Hello! I work with a large project (~900 .swift files and more .m files). We 
> have a nightly job that compiles the app and calls out function bodies (using 
> -debug-time-function-bodies) that are slower than 100ms to compile. Since 
> upgrading to Swift 3, the number of trouble function bodies has one from > 
> 150 to < 20, so we're really happy about that! The only issue though is that 
> build time overall increased by ~1 min (amount of time to build all targets 
> before automatically merging to master in our integration build).

Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or with one 
of the toolchain builds from swift.org ?

Xcode 8.1 beta 2 includes some type checker performance improvements which 
might have an impact here.

> 
> To dig into this further, we've started a new nightly job that builds the app 
> using the -debug-time-compilation flag, and using that we've found that some 
> files take as long as 2-3 seconds to compile. But, there's no targeted output 
> to help us get this down via the -debug-time-function-bodies flag (i.e. no 
> function bodies that we can refactor to get compile times much faster).

One thing to look out for here is that I believe there are some cases where 
-debug-time-function-bodies isn’t reporting type checking time. From my 
(potentially faulty) recollection, things like let bindings with literals or 
closures on the right hand side do not show up in the 
-debug-time-function-bodies output, and depending on the specifics of the 
expression these can sometimes take a long time to type check. When these 
appear within the body of another type declaration they can end up getting type 
checked multiple times during a full project build, and that time can add up.

I don’t believe there is a bug open for improving -debug-time-function-bodies 
to help diagnose this, but opening a bug would be appreciated if you can 
confirm that this is the case, and of course patches to fix it are definitely 
welcome as well.

Mark

> We can see that most of the time is spent in "Type checking / Semantic 
> analysis" for these problem files, but we don't currently have any way of 
> knowing what that means. It feels like we've exhausted the available options 
> at this point (unless there are other flags I'm missing) in terms of existing 
> actionable debugging/profiling/reporting, so now our question is this: what 
> kind of reports would Swift maintainers be interested in seeing in terms of 
> output from profiling tools, etc. to help debug/diagnose these slow compile 
> issues? We're willing to devote time to tooling to help generate such reports 
> and file bugs.
> 
> Thanks!
> 
> Ben
> ___
> 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] Reporting/Debugging Slow Swift Compile Time

[Brian Gesiak via swift-dev]

Hi Ben,

I'd really like to see improvements here as well. I don't know what reports
would be useful to the Swift team, but allow me to point out
https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea75bc09cbd5,
which adds a -warn-long-function-bodies option that you may be able to use.

However, as stated in the commit message I linked to above, both
-debug-time-function-bodies and -warn-long-function-bodies are frontend
options. They are not officially supported, and may be removed at any time
without warning.

Personally, I think the Swift compiler should provide users with more
information about compilation times. In
https://bugs.swift.org/browse/SR-2741, Brian Michel (cc'ed) describes a
feature he'd like to see: structured output from the Swift compiler driver,
as an official, supported option. Your team's use case sounds very similar
to his, so I'd encourage you to chime in on that issue with your thoughts.

- Brian Gesiak


On Tue, Oct 4, 2016 at 5:38 PM, Ben Asher via swift-dev  wrote:

> Hello! I work with a large project (~900 .swift files and more .m files).
> We have a nightly job that compiles the app and calls out function bodies
> (using -debug-time-function-bodies) that are slower than 100ms to
> compile. Since upgrading to Swift 3, the number of trouble function bodies
> has one from > 150 to < 20, so we're really happy about that! The only
> issue though is that build time overall increased by ~1 min (amount of time
> to build all targets before automatically merging to master in our
> integration build).
>
> To dig into this further, we've started a new nightly job that builds the
> app using the -debug-time-compilation flag, and using that we've found that
> some files take as long as 2-3 seconds to compile. But, there's no targeted
> output to help us get this down via the -debug-time-function-bodies flag
> (i.e. no function bodies that we can refactor to get compile times much
> faster). We can see that most of the time is spent in "Type checking /
> Semantic analysis" for these problem files, but we don't currently have any
> way of knowing what that means. It feels like we've exhausted the available
> options at this point (unless there are other flags I'm missing) in terms
> of existing actionable debugging/profiling/reporting, so now our question
> is this: what kind of reports would Swift maintainers be interested in
> seeing in terms of output from profiling tools, etc. to help debug/diagnose
> these slow compile issues? We're willing to devote time to tooling to help
> generate such reports and file bugs.
>
> Thanks!
>
> Ben
>
> ___
> 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] Differences between Xcode official toolchains and tagged releases from repository

[Jordan Rose via swift-dev]

Aha, so the second bug is because home-built toolchains have assertions on by 
default and Xcode GM toolchains generally have them off. (Not a promise, but 
true of the last few Xcodes.) Of course, if you hit an assertion failure, 
there’s no telling what the no-asserts build is actually doing.

I’m not so sure the first bug falls into the same category yet, but it might as 
well.

Jordan


> On Oct 4, 2016, at 14:05, Jordan Rose via swift-dev  
> wrote:
> 
> Thanks, Xavi. Hopefully these aren't blocking you in Xcode 8 either (in 
> either Swift 2.3 or Swift 3).
> 
>> On Oct 4, 2016, at 8:03, Xavier Jurado via swift-dev  
>> wrote:
>> 
>> Hello Jordan,
>> 
>> We have filled two bugs against bugs.swift.org to document two crashes
>> that are only reproducible with our toolchain built from the
>> swift-2.2.1-RELEASE tag, but that appear fixed in the official
>> toolchain bundled with Xcode 7.3.1 (7D1014).
>> 
>> Crashers:
>> 
>> https://bugs.swift.org/browse/SR-2844
>> https://bugs.swift.org/browse/SR-2845
>> 
>> Since using the official toolchain somehow fixes the issues we realize
>> they are far from critical, but we have reported them in hope of
>> finding the discrepancies between the official toolchain and the the
>> tagged releases.
>> 
>> Thanks,
>> Xavi
>> ___
>> 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-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-dev] Reporting/Debugging Slow Swift Compile Time

[Ben Asher via swift-dev]

Hello! I work with a large project (~900 .swift files and more .m files).
We have a nightly job that compiles the app and calls out function bodies
(using -debug-time-function-bodies) that are slower than 100ms to compile.
Since upgrading to Swift 3, the number of trouble function bodies has one
from > 150 to < 20, so we're really happy about that! The only issue though
is that build time overall increased by ~1 min (amount of time to build all
targets before automatically merging to master in our integration build).

To dig into this further, we've started a new nightly job that builds the
app using the -debug-time-compilation flag, and using that we've found that
some files take as long as 2-3 seconds to compile. But, there's no targeted
output to help us get this down via the -debug-time-function-bodies flag
(i.e. no function bodies that we can refactor to get compile times much
faster). We can see that most of the time is spent in "Type checking /
Semantic analysis" for these problem files, but we don't currently have any
way of knowing what that means. It feels like we've exhausted the available
options at this point (unless there are other flags I'm missing) in terms
of existing actionable debugging/profiling/reporting, so now our question
is this: what kind of reports would Swift maintainers be interested in
seeing in terms of output from profiling tools, etc. to help debug/diagnose
these slow compile issues? We're willing to devote time to tooling to help
generate such reports and file bugs.

Thanks!

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