Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 16.10 (master) #321

[mishal_shah via swift-dev]

Testing Time: 625.72s

Failing Tests (17):
Swift(linux-x86_64) :: SIL/parse_stdlib_15.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_0.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_10.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_13.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_6.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_9.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_7.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_16.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_4.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_3.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_2.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_8.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_12.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_5.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_14.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_1.sil
Swift(linux-x86_64) :: SIL/parse_stdlib_11.sil

> On Jan 26, 2017, at 5:45 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-16_10 [#321]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-16_10/321/ 
> 
> Project:  oss-swift-package-linux-ubuntu-16_10
> Date of build:Thu, 26 Jan 2017 16:43:03 -0800
> Build duration:   1 hr 2 min
> 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 
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1 
> 
> Changes
> 
> Commit 8c6f7453521b40478e5af4c8aa5f307ba383 by nhawes:
> [indexer] Fix crash in initVarRefIndexSymbols by handling func/var
> 
> edit: test/SourceKit/Indexing/index_func_import.swift.response
> edit: lib/Index/Index.cpp
> edit: test/Index/roles.swift
> add: test/Index/Inputs/imported_swift_module.swift
> edit: lib/AST/SourceEntityWalker.cpp
> 
> Commit ede6bf7a807d11f7b4630dd351027a8bd5a0faed by dfarler:
> Lexer: Don't split an operator '.<' from '.<#placeholder#>'
> 
> edit: lib/Parse/Lexer.cpp
> edit: test/IDE/structure_object_literals.swift
> 
> Commit e0ffbfb91b834e901c9100b6bb869186350f5f9a by nhawes:
> [indexer] Rename initCallRefIndexSymbol -> initFuncRefIndexSymbol as its
> 
> edit: lib/Index/Index.cpp
> 
> Commit 92e9d2d84f956bcf0ac28d96ea04030d1d1caac1 by huon:
> [SIL] Extract reoccuring allocation patterns.
> 
> edit: lib/SIL/SILWitnessTable.cpp
> edit: lib/SIL/SILPrinter.cpp
> edit: lib/SIL/SILDefaultWitnessTable.cpp
> edit: lib/SIL/SILCoverageMap.cpp
> edit: include/swift/SIL/SILCoverageMap.h
> edit: include/swift/SIL/SILModule.h
> 
> Commit fab0371eba59114347746da9bde98b94fe7274fd by dgregor:
> [Type checker] Allow bridging followed by a conversion to existential.
> 
> edit: lib/Sema/CSSimplify.cpp
> edit: test/expr/cast/bridged.swift
> edit: lib/Sema/CSApply.cpp
> 
> Commit bf2dcbf25e1ff8f8ff078ab785a67a836414a0fe by rlevenstein:
> Use function signatures for SILDeclRefs in witness_tables, vtables and
> 
> edit: test/SILGen/witnesses.swift
> edit: test/SILOptimizer/devirt_access.sil
> edit: test/SILGen/dynamic_self.swift
> edit: test/SILOptimizer/definite_init_objc_factory_init.swift
> edit: test/SILGen/guaranteed_self.swift
> edit: test/SILGen/testable-multifile.swift
> edit: test/SILGen/complete_object_init.swift
> edit: test/SILGen/deinit_in_vtable.swift
> edit: test/SILGen/required_init.swift
> edit: test/SIL/Parser/protocol_getter.sil
> edit: test/SILOptimizer/cse.sil
> edit: test/SILGen/objc_imported_generic.swift
> edit: test/SILGen/vtables.swift
> edit: test/SILGen/dynamic_init.swift
> edit: test/SILOptimizer/latecodemotion.sil
> edit: test/SILOptimizer/inlinecaches_invalidate_failure.sil
> edit: test/SILOptimizer/inline_caches.sil
> edit: test/SILOptimizer/sil_combine_devirt.sil
> edit: test/SILOptimizer/constant_propagation_castopt_analysis_invalidation.sil
> edit: test/SILOptimizer/devirt_override.sil
> edit: test/SILOptimizer/devirt_speculate.swift
> add: test/SILGen/SILDeclRef.swift
> edit: test/SILGen/witness_tables.swift
> edit: test/SIL/Parser/witness_tables.sil
> edit: test/SILGen/unowned.swift
> edit: test/SILGen/vtable_thunks.swift
> edit: test/SIL/Parser/overloaded_member.sil
> edit: test/SILGen/lifetime.swift
> edit: test/SIL/Parser/generic_signature_with_depth.swift
> edit: test/SILGen/existential_erasure.swift
> edit: test/SILGen/init_ref_delegation.swift
> edit: test/SILGen/properties.swift
> edit: test/SILOptimizer/inlinecaches_arc.sil
> edit: test/SILOptimizer/sink.sil
> edit: test/SILOptimizer/sil_combine.sil
> edit: 

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 4:48 PM, Greg Parker  wrote:
> 
> 
>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>  wrote:
>> 
>> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
>> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
>> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
>> 
>> During the code review, I ran `git clang-format` as part of being a good 
>> citizen. There's only one problem with the tool. It rewraps long boolean 
>> expressions, hiding those unsightly operators at the end of lines (after all 
>> who wants to see those?).
>> 
>>   if (some_expression->with_calls() ||
>>   another_expression->with(nested_calls()) &&
>>   an_even_longer_expression->making_your_eyes->glaze_over())
>> 
>> I don't get involved in style wars, but this is not a style change, it's an 
>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>> do. It's hurt me too many times in the past, and I'm not happy using a 
>> formatting tool that injects future bugs and harms code comprehension.
> 
> Counterargument: It's not an objective code quality degradation, it's a style 
> choice that you don't like. 

It’s not about what I’m used to or what I find visually pleasing. It’s been a 
source of bugs in my experience. If my experience is unique, and people want to 
standardize on a different style, then I’ll just have to try to be more careful 
reading the code and write fewer complicated if-conditions.

> The first rule of code style is "do as the rest of the code does". 
> 
> Trailing binary operators are fine, as long as they are consistent. Mixing 
> leading and trailing operators in the same code base is a greater harm to 
> code comprehension than either one is on its own. Any difference between 
> consistently leading and consistently trailing is small, and not worth the 
> pain of a mass rewrite.

That’s why I haven’t brought this up with LLVM project. The style has already 
been standardized (although my old code still wraps operators the right way :). 
I’m not sure anyone thought about this and didn’t want to repeat the same 
mistake in Swift.

I’ve seen both styles in the Swift compiler, although looking around the code 
now my preferred convention seems pretty clearly out of style. I also spent 
time in the standard library code, which has very carefully thought out 
conventions and wraps operators the way I’m recommending. Moving toward that 
style seemed reasonable if most developers agreed.

If I am the only person that feels strongly about it, then we’re probably 
better of standardizing on LLVM’s defaults just because most of the code has 
already done that. So here’s the option I intentionally left out:

Option 4: Standardize Swift style based purely on LLVM.

  Let's standardize the Swift compiler using LLVM’s default style configuration.

> I consider this LLVM and Swift project style to be an objective code quality 
> degradation:
>if (condition)
>single_line_body();
> 
> But the first rule of code style is "do as the rest of the code does", so I 
> write my LLVM and Swift code like that.

I agree. If auto-indenting editors hadn’t solved that problem I’d be arguing 
about that too!

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Greg Parker via swift-dev]

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev  
> wrote:
> 
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good 
> citizen. There's only one problem with the tool. It rewraps long boolean 
> expressions, hiding those unsightly operators at the end of lines (after all 
> who wants to see those?).
> 
>if (some_expression->with_calls() ||
>another_expression->with(nested_calls()) &&
>an_even_longer_expression->making_your_eyes->glaze_over())
> 
> I don't get involved in style wars, but this is not a style change, it's an 
> objective code quality degradation. It's a demonstrably bug-prone thing to 
> do. It's hurt me too many times in the past, and I'm not happy using a 
> formatting tool that injects future bugs and harms code comprehension.

Counterargument: It's not an objective code quality degradation, it's a style 
choice that you don't like. 

The first rule of code style is "do as the rest of the code does". 

Trailing binary operators are fine, as long as they are consistent. Mixing 
leading and trailing operators in the same code base is a greater harm to code 
comprehension than either one is on its own. Any difference between 
consistently leading and consistently trailing is small, and not worth the pain 
of a mass rewrite.

I consider this LLVM and Swift project style to be an objective code quality 
degradation:
if (condition)
single_line_body();

But the first rule of code style is "do as the rest of the code does", so I 
write my LLVM and Swift code like that.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Jordan Rose via swift-dev]

> On Jan 26, 2017, at 12:55, Andrew Trick via swift-dev  
> wrote:
> 
>> 
>> On Jan 26, 2017, at 11:38 AM, Graydon Hoare  wrote:
>> 
>> 
>>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>>  wrote:
>>> 
>>> Before I pull in a large PR that "accidentally" reformats a bunch of code, 
>>> I want to get feedback on how Swift compiler devs plan to use 
>>> `clang-format`. (BTW, here's the PR 
>>> https://github.com/apple/swift/pull/6922).
>>> 
>>> During the code review, I ran `git clang-format` as part of being a good 
>>> citizen. There's only one problem with the tool. It rewraps long boolean 
>>> expressions, hiding those unsightly operators at the end of lines (after 
>>> all who wants to see those?).
>>> 
>>>  if (some_expression->with_calls() ||
>>>  another_expression->with(nested_calls()) &&
>>>  an_even_longer_expression->making_your_eyes->glaze_over())
>>> 
>>> I don't get involved in style wars, but this is not a style change, it's an 
>>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>>> do. It's hurt me too many times in the past, and I'm not happy using a 
>>> formatting tool that injects future bugs and harms code comprehension.
>> 
>> It's funny you'd mention this! I often format code that way, not out of any 
>> great love of it, but from muscle-memory of living under an old coding 
>> guideline somewhere in the distant past claiming that the ugliness of 
>> trailing unfinished-binops draws the eye to them and makes the user pay 
>> attention. Doug Crockford recommends this style; but of course Don Knuth 
>> agrees with you. I don't feel strongly about them as such, but I feel ... 
>> anti-strongly, I guess? Like changing that one thing isn't worth a 
>> cross-codebase rewrite / merge collision.
> 
> I’m not sure who’s recommending what. The above style obscures operators. 
> Does anyone disagree with that? A lot of code has been written in that way; I 
> think because developers value aesthetics over clarity, or just don’t think 
> about it. I care because when something doesn’t stand out, my brain fills in 
> the gaps with whatever it expects. For me, that leads to a bunch of silly 
> logic errors.
> 
> I need to see it this way:
> 
>  if (some_expression->with_calls()
>  || another_expression->with(nested_calls())
>  && an_even_longer_expression->making_your_eyes->glaze_over())
> 
> The need for parens now stands out. Sorry this isn’t a good example. Nested 
> expressions would make it much more compelling.
> 
> That’s the coding convention we use for Swift code (at least in the stdlib). 
> The compiler C++ code is just a hodge-podge.
> If anyone actually thinks trailing operators are a good idea for our code 
> base, I won’t argue, but I’ve never heard that argument.
> 
> BTW- I’m not interested at all in doing a mass reformatting or forcing a 
> convention on people. I just don’t want to apply clang-format to every line 
> of code I touch without knowing what settings to use.

I've never had a problem with the trailing operators, and find them mildly more 
aesthetically pleasing (when not in an if, it makes it clearer what I plan to 
do with the next line), but I see how they put it in your face in an if. I can 
change my style.

Jordan

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 11:38 AM, Graydon Hoare  wrote:
> 
> 
>> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev 
>>  wrote:
>> 
>> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
>> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
>> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
>> 
>> During the code review, I ran `git clang-format` as part of being a good 
>> citizen. There's only one problem with the tool. It rewraps long boolean 
>> expressions, hiding those unsightly operators at the end of lines (after all 
>> who wants to see those?).
>> 
>>   if (some_expression->with_calls() ||
>>   another_expression->with(nested_calls()) &&
>>   an_even_longer_expression->making_your_eyes->glaze_over())
>> 
>> I don't get involved in style wars, but this is not a style change, it's an 
>> objective code quality degradation. It's a demonstrably bug-prone thing to 
>> do. It's hurt me too many times in the past, and I'm not happy using a 
>> formatting tool that injects future bugs and harms code comprehension.
> 
> It's funny you'd mention this! I often format code that way, not out of any 
> great love of it, but from muscle-memory of living under an old coding 
> guideline somewhere in the distant past claiming that the ugliness of 
> trailing unfinished-binops draws the eye to them and makes the user pay 
> attention. Doug Crockford recommends this style; but of course Don Knuth 
> agrees with you. I don't feel strongly about them as such, but I feel ... 
> anti-strongly, I guess? Like changing that one thing isn't worth a 
> cross-codebase rewrite / merge collision.

I’m not sure who’s recommending what. The above style obscures operators. Does 
anyone disagree with that? A lot of code has been written in that way; I think 
because developers value aesthetics over clarity, or just don’t think about it. 
I care because when something doesn’t stand out, my brain fills in the gaps 
with whatever it expects. For me, that leads to a bunch of silly logic errors.

I need to see it this way:

  if (some_expression->with_calls()
  || another_expression->with(nested_calls())
  && an_even_longer_expression->making_your_eyes->glaze_over())

The need for parens now stands out. Sorry this isn’t a good example. Nested 
expressions would make it much more compelling.

That’s the coding convention we use for Swift code (at least in the stdlib). 
The compiler C++ code is just a hodge-podge.
If anyone actually thinks trailing operators are a good idea for our code base, 
I won’t argue, but I’ve never heard that argument.

BTW- I’m not interested at all in doing a mass reformatting or forcing a 
convention on people. I just don’t want to apply clang-format to every line of 
code I touch without knowing what settings to use.

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Graydon Hoare via swift-dev]

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev  
> wrote:
> 
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good 
> citizen. There's only one problem with the tool. It rewraps long boolean 
> expressions, hiding those unsightly operators at the end of lines (after all 
> who wants to see those?).
> 
>if (some_expression->with_calls() ||
>another_expression->with(nested_calls()) &&
>an_even_longer_expression->making_your_eyes->glaze_over())
> 
> I don't get involved in style wars, but this is not a style change, it's an 
> objective code quality degradation. It's a demonstrably bug-prone thing to 
> do. It's hurt me too many times in the past, and I'm not happy using a 
> formatting tool that injects future bugs and harms code comprehension.

It's funny you'd mention this! I often format code that way, not out of any 
great love of it, but from muscle-memory of living under an old coding 
guideline somewhere in the distant past claiming that the ugliness of trailing 
unfinished-binops draws the eye to them and makes the user pay attention. Doug 
Crockford recommends this style; but of course Don Knuth agrees with you. I 
don't feel strongly about them as such, but I feel ... anti-strongly, I guess? 
Like changing that one thing isn't worth a cross-codebase rewrite / merge 
collision.

That said ...

> ** Option 2: Contributors each tweak clang-format according to their (in my 
> case strong) bias:

This option seems least-desirable to me. My preference would be that code stays 
formatted as uniformly and invariably as possible; I'm surprised to notice we 
have a .clang-format in the repo, given that it's not being enforced (and 
there's not even a build-system rule to use it, as far as I can see). How would 
people feel about automatic enforcement? i.e. testing a patch fails if 
clang-format has nonempty tree-reformatting to do.

-Graydon

(Who is happy to setq c-indentation-style to anything from Allman to Whitesmith)

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Michael Gottesman via swift-dev]

Can I make a more radical suggestion. Maybe the thing to do here is to enforce 
git-clang-format so that everyone uses it. It would be really simple to do. You 
would require people to put it in a pre commit hook. Then swift-ci would have a 
job that ran git-clang-format and would require it to come through clean.

Michael

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev  
> wrote:
> 
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good 
> citizen. There's only one problem with the tool. It rewraps long boolean 
> expressions, hiding those unsightly operators at the end of lines (after all 
> who wants to see those?).
> 
>if (some_expression->with_calls() ||
>another_expression->with(nested_calls()) &&
>an_even_longer_expression->making_your_eyes->glaze_over())
> 
> I don't get involved in style wars, but this is not a style change, it's an 
> objective code quality degradation. It's a demonstrably bug-prone thing to 
> do. It's hurt me too many times in the past, and I'm not happy using a 
> formatting tool that injects future bugs and harms code comprehension.
> 
> When the LLVM coding style was originally ratified, this aspect was left up 
> to individual preference and didn't get any discussion AFAIK. I think
> clang-format then ended up with a `BreakBeforeBinaryOperators: None` style 
> out of sheer inertia. 
> 
> So, how should I use clang-format on Swift compiler code? Vote please.
> 
> ** Option 1: Add a simple configuration option to swift/.clang-format:
> 
> 1a. BreakBeforeBinaryOperators: All
> 
> 1b. BreakBeforeBinaryOperators: NonAssignment
> 
> I have absolutely no preference between 1a and 1b. It's purely style.
> 
> 1a:
> SomeLongTypeName someLongVariableName =
>  someLongExpression();
> 
> 1b:
> SomeLongTypeName someLongVariableName
>  = someLongExpression();
> 
> ** Option 2: Contributors each tweak clang-format according to their (in my 
> case strong) bias:
> 
> My own command line:
> 2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
> 2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: 
> NonAssignment}"
> 
> ** Option 3: Don't bother using clang-format.
> 
> Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.
> 
> -Andy
> ___
> 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] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 10:34 AM, Andrew Trick via swift-dev 
>  wrote:
> 
> 
>> On Jan 26, 2017, at 10:25 AM, Jordan Rose > > wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev >> > wrote:
>>> 
 
 On Jan 26, 2017, at 9:29 AM, Ben Langmuir > wrote:
 
> 
> On Jan 26, 2017, at 9:14 AM, Andrew Trick  > wrote:
> 
> 
>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir > > wrote:
>>> 
>>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>>> 
>>> 1a. BreakBeforeBinaryOperators: All
>>> 
>>> 1b. BreakBeforeBinaryOperators: NonAssignment
>> 
>>> 
>>> I have absolutely no preference between 1a and 1b. It's purely style.
>>> 
>>> 1a:
>>> SomeLongTypeName someLongVariableName =
>>> someLongExpression();
>>> 
>>> 1b:
>>> SomeLongTypeName someLongVariableName
>>> = someLongExpression();
>> 
>> 1b sounds good to me.
> 
> I contradicted myself above. If you like the style shown in (1b), the 
> configuration option is actually BreakBeforeBinaryOperators: All.
 
 Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
 your example code against the above description :-)
>>> 
>>> Alright, I’l reformat my PR with that config, unless anyone else wants to 
>>> weigh in.
>>> 
>>> Incidentally, I despise what clang-format does with asserts now:
>>>   assert(condition
>>>  && “text”)
>>> 
>>> It’s a consequence of us not using a legit assert package, so I don’t know 
>>> if I want to push to get clang-format changed.
>> 
>> What do you want it to do with this style of assert?
> 
> assert((precondition1 || predcondition2) &&
>“informative message”)
> 
> The boolean operator is filling in for a comma. That’s how it’s meant to be 
> parsed by the reader. It’s presence in the code is purely distracting. From 
> the tool’s point of view, it’s tautological so shouldn’t be given 
> significance as a boolean operator.

clang-format bug filed to put this tangent to rest:
https://llvm.org/bugs/show_bug.cgi?id=31772 


-Andy

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 10:25 AM, Jordan Rose  wrote:
> 
>> 
>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev > > wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir >> > wrote:
>>> 
 
 On Jan 26, 2017, at 9:14 AM, Andrew Trick > wrote:
 
 
> On Jan 26, 2017, at 9:11 AM, Ben Langmuir  > wrote:
>> 
>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>> 
>> 1a. BreakBeforeBinaryOperators: All
>> 
>> 1b. BreakBeforeBinaryOperators: NonAssignment
> 
>> 
>> I have absolutely no preference between 1a and 1b. It's purely style.
>> 
>> 1a:
>> SomeLongTypeName someLongVariableName =
>> someLongExpression();
>> 
>> 1b:
>> SomeLongTypeName someLongVariableName
>> = someLongExpression();
> 
> 1b sounds good to me.
 
 I contradicted myself above. If you like the style shown in (1b), the 
 configuration option is actually BreakBeforeBinaryOperators: All.
>>> 
>>> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
>>> your example code against the above description :-)
>> 
>> Alright, I’l reformat my PR with that config, unless anyone else wants to 
>> weigh in.
>> 
>> Incidentally, I despise what clang-format does with asserts now:
>>   assert(condition
>>  && “text”)
>> 
>> It’s a consequence of us not using a legit assert package, so I don’t know 
>> if I want to push to get clang-format changed.
> 
> What do you want it to do with this style of assert?

assert((precondition1 || predcondition2) &&
   “informative message”)

The boolean operator is filling in for a comma. That’s how it’s meant to be 
parsed by the reader. It’s presence in the code is purely distracting. From the 
tool’s point of view, it’s tautological so shouldn’t be given significance as a 
boolean operator.

-Andy

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Jordan Rose via swift-dev]

> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev  
> wrote:
> 
>> 
>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir > > wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 9:14 AM, Andrew Trick >> > wrote:
>>> 
>>> 
 On Jan 26, 2017, at 9:11 AM, Ben Langmuir > wrote:
> 
> ** Option 1: Add a simple configuration option to swift/.clang-format:
> 
> 1a. BreakBeforeBinaryOperators: All
> 
> 1b. BreakBeforeBinaryOperators: NonAssignment
 
> 
> I have absolutely no preference between 1a and 1b. It's purely style.
> 
> 1a:
> SomeLongTypeName someLongVariableName =
> someLongExpression();
> 
> 1b:
> SomeLongTypeName someLongVariableName
> = someLongExpression();
 
 1b sounds good to me.
>>> 
>>> I contradicted myself above. If you like the style shown in (1b), the 
>>> configuration option is actually BreakBeforeBinaryOperators: All.
>> 
>> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
>> your example code against the above description :-)
> 
> Alright, I’l reformat my PR with that config, unless anyone else wants to 
> weigh in.
> 
> Incidentally, I despise what clang-format does with asserts now:
>   assert(condition
>  && “text”)
> 
> It’s a consequence of us not using a legit assert package, so I don’t know if 
> I want to push to get clang-format changed.

What do you want it to do with this style of assert?

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 9:29 AM, Ben Langmuir  wrote:
> 
>> 
>> On Jan 26, 2017, at 9:14 AM, Andrew Trick > > wrote:
>> 
>> 
>>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir >> > wrote:
 
 ** Option 1: Add a simple configuration option to swift/.clang-format:
 
 1a. BreakBeforeBinaryOperators: All
 
 1b. BreakBeforeBinaryOperators: NonAssignment
>>> 
 
 I have absolutely no preference between 1a and 1b. It's purely style.
 
 1a:
 SomeLongTypeName someLongVariableName =
 someLongExpression();
 
 1b:
 SomeLongTypeName someLongVariableName
 = someLongExpression();
>>> 
>>> 1b sounds good to me.
>> 
>> I contradicted myself above. If you like the style shown in (1b), the 
>> configuration option is actually BreakBeforeBinaryOperators: All.
> 
> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check 
> your example code against the above description :-)

Alright, I’l reformat my PR with that config, unless anyone else wants to weigh 
in.

Incidentally, I despise what clang-format does with asserts now:
  assert(condition
 && “text”)

It’s a consequence of us not using a legit assert package, so I don’t know if I 
want to push to get clang-format changed.

-Andy___
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 - OS X (swift 3.1) #230

[Jordan Rose via swift-dev]

Jenkins error, not my commit.

> On Jan 26, 2017, at 00:13, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-3.1-incremental-RA-osx [#230]
> 
> Build URL:https://ci.swift.org/job/oss-swift-3.1-incremental-RA-osx/230/ 
> 
> Project:  oss-swift-3.1-incremental-RA-osx
> Date of build:Wed, 25 Jan 2017 23:22:53 -0800
> Build duration:   50 min
> 
> Changes
> 
> Commit a2f29b62ed9eb52252b0062301d790b5ff71a4f6 by jordan_rose:
> Use interface types when checking #keyPath. (#7028)
> 
> edit: lib/Sema/TypeCheckExprObjC.cpp
> add: validation-test/compiler_crashers_2_fixed/0064-sr3714.swift

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Ben Langmuir via swift-dev]

> On Jan 26, 2017, at 9:14 AM, Andrew Trick  wrote:
> 
> 
>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir > > wrote:
>>> 
>>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>>> 
>>> 1a. BreakBeforeBinaryOperators: All
>>> 
>>> 1b. BreakBeforeBinaryOperators: NonAssignment
>> 
>>> 
>>> I have absolutely no preference between 1a and 1b. It's purely style.
>>> 
>>> 1a:
>>> SomeLongTypeName someLongVariableName =
>>> someLongExpression();
>>> 
>>> 1b:
>>> SomeLongTypeName someLongVariableName
>>> = someLongExpression();
>> 
>> 1b sounds good to me.
> 
> I contradicted myself above. If you like the style shown in (1b), the 
> configuration option is actually BreakBeforeBinaryOperators: All.

Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check your 
example code against the above description :-)

> -Andy

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

> On Jan 26, 2017, at 9:11 AM, Ben Langmuir  wrote:
>> 
>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>> 
>> 1a. BreakBeforeBinaryOperators: All
>> 
>> 1b. BreakBeforeBinaryOperators: NonAssignment
> 
>> 
>> I have absolutely no preference between 1a and 1b. It's purely style.
>> 
>> 1a:
>> SomeLongTypeName someLongVariableName =
>> someLongExpression();
>> 
>> 1b:
>> SomeLongTypeName someLongVariableName
>> = someLongExpression();
> 
> 1b sounds good to me.

I contradicted myself above. If you like the style shown in (1b), the 
configuration option is actually BreakBeforeBinaryOperators: All.

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[Ben Langmuir via swift-dev]

> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev  
> wrote:
> 
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good 
> citizen. There's only one problem with the tool. It rewraps long boolean 
> expressions, hiding those unsightly operators at the end of lines (after all 
> who wants to see those?).
> 
>if (some_expression->with_calls() ||
>another_expression->with(nested_calls()) &&
>an_even_longer_expression->making_your_eyes->glaze_over())
> 
> I don't get involved in style wars, but this is not a style change, it's an 
> objective code quality degradation. It's a demonstrably bug-prone thing to 
> do. It's hurt me too many times in the past, and I'm not happy using a 
> formatting tool that injects future bugs and harms code comprehension.
> 
> When the LLVM coding style was originally ratified, this aspect was left up 
> to individual preference and didn't get any discussion AFAIK. I think
> clang-format then ended up with a `BreakBeforeBinaryOperators: None` style 
> out of sheer inertia. 
> 
> So, how should I use clang-format on Swift compiler code? Vote please.
> 
> ** Option 1: Add a simple configuration option to swift/.clang-format:
> 
> 1a. BreakBeforeBinaryOperators: All
> 
> 1b. BreakBeforeBinaryOperators: NonAssignment

> 
> I have absolutely no preference between 1a and 1b. It's purely style.
> 
> 1a:
> SomeLongTypeName someLongVariableName =
>  someLongExpression();
> 
> 1b:
> SomeLongTypeName someLongVariableName
>  = someLongExpression();

1b sounds good to me.

> 
> ** Option 2: Contributors each tweak clang-format according to their (in my 
> case strong) bias:
> 
> My own command line:
> 2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
> 2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: 
> NonAssignment}"
> 
> ** Option 3: Don't bother using clang-format.
> 
> Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.
> 
> -Andy
> ___
> 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] Race conditions with lazy variables

[Dan Zimmerman via swift-dev]

Hey,

Today I ran into an issue where I had a lazy instance variable that was being 
initialized multiple times due to a race condition. For example:
```
import Darwin
import Dispatch

func doSomethingIntense() {
usleep(10)
}

var counter: Int = 0

class Cat {
lazy var sound: String = {
doSomethingIntense()
  let isFive = counter == 5
counter += 1
print("Getting 
\(Unmanaged.passUnretained(self).toOpaque()).sound")
return isFive ? "doctorate denied" : "meow"
}()
}

let cat = Cat()
for _ in 1..<10 {
  if #available(OSX 10.10, *) {
  usleep(100);
  DispatchQueue.global(qos: .background).async {
  print("The cat says \(cat.sound)")
  }
  }
}

dispatchMain()
```

I was wondering what the "swifty" way to fix this issue would be (assuming I 
only want the lazy initializer to be called once) - since dispatch_once was 
taken out I don't see a clean way to do this without interacting with 
pthread_mutex's directly.

I was also wondering if there's been any discussion surrounding this - i.e. I 
can't imagine an instance where I have a lazy variable initialized via a 
closure that I'm ok with it being initialized twice.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

[swift-corelibs-dev] swift-corelibs-dev build-script with --foundation is not working for me

[Kris Simon via swift-corelibs-dev]

Hi,

a couple of days ago i ran into swift on linux. The whole thing makes so much 
sense for us. Developing our tools in swift could be a huge benefit. I am 
excited to get deeper into swift for linux. 

I build swift on Ubuntu successfully (without errors) from scratch with this 
options:

./utils/build-script --release --foundation --verbose-build 
--build-stdlib-deployment-targets all -l -b -p --skip-test-linux 
--build-swift-static-stdlib --build-swift-static-sdk-overlay --xctest -c

My goal is to have Foundation in static compiled binaries.
As mentioned everything in the build process works fine, but the execution of a 
simple script as shown below failed.

import Foundation

print("Hello Swift.")
I get the following error:
/bin/swiftc /home/hello.swift -o /home/hello 
/home/hello.swift:1:8: error: no such module 'Foundation'
How to build Swift with the current state of foundation? 
Can you please give me a little kick into the right direction? The web is not 
very useful in this early state, but i am really want to get into it. 

Thanks a lot, 
Kris___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-dev] Proposal: Opaque SIL values

[Joe Groff via swift-dev]

> On Jan 26, 2017, at 12:45 AM, Andrew Trick  wrote:
> 
> 
>> On Jan 25, 2017, at 6:13 PM, Joe Groff  wrote:
>> 
>>> Naturally, opaque types must limit some optimizations, such as inlining.
>> 
>> I don't see how opaque types by themselves prevent inlining. You can inline 
>> a generic into another generic, or a function using a resilient type into 
>> another function.
> 
> Good point. I was just hand-waving here about resilient types, which we can’t 
> inline by design, and archetypes where we can’t inline protocol methods 
> because method resolution requires specialization. But yeah, we should be 
> inlining methods on unbound generic nominal types. I updated the doc.

We can't inline any information about the type layout of a resilient type, but 
it wouldn't block inlining of functions that use values of the resilient type 
when we have visibility into their bodies. It doesn't seem right to me to call 
them out as "not inlinable" when most of the non-inlinable things about them, 
like layout, value witnesses, and type metadata, are below the abstraction 
level of SIL.

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

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

[John McCall via swift-dev]

> On Jan 26, 2017, at 5:07 AM, Andrew Trick via swift-dev  
> wrote:
> Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
> want to get feedback on how Swift compiler devs plan to use `clang-format`. 
> (BTW, here's the PR https://github.com/apple/swift/pull/6922).
> 
> During the code review, I ran `git clang-format` as part of being a good 
> citizen. There's only one problem with the tool. It rewraps long boolean 
> expressions, hiding those unsightly operators at the end of lines (after all 
> who wants to see those?).
> 
>if (some_expression->with_calls() ||
>another_expression->with(nested_calls()) &&
>an_even_longer_expression->making_your_eyes->glaze_over())

Well, I mean, I hope nobody mixes || and && like this. :)

Anyway, a vote:

> I don't get involved in style wars, but this is not a style change, it's an 
> objective code quality degradation. It's a demonstrably bug-prone thing to 
> do. It's hurt me too many times in the past, and I'm not happy using a 
> formatting tool that injects future bugs and harms code comprehension.
> 
> When the LLVM coding style was originally ratified, this aspect was left up 
> to individual preference and didn't get any discussion AFAIK. I think
> clang-format then ended up with a `BreakBeforeBinaryOperators: None` style 
> out of sheer inertia. 
> 
> So, how should I use clang-format on Swift compiler code? Vote please.
> 
> ** Option 1: Add a simple configuration option to swift/.clang-format:
> 
> 1a. BreakBeforeBinaryOperators: All
> 
> 1b. BreakBeforeBinaryOperators: NonAssignment
> 
> I have absolutely no preference between 1a and 1b. It's purely style.

> 
> 1a:
> SomeLongTypeName someLongVariableName =
>  someLongExpression();
> 
> 1b:
> SomeLongTypeName someLongVariableName
>  = someLongExpression();
> 
> ** Option 2: Contributors each tweak clang-format according to their (in my 
> case strong) bias:
> 
> My own command line:
> 2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
> 2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: 
> NonAssignment}"
> 
> ** Option 3: Don't bother using clang-format.
> 
> Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.

I agree with your point that we should discourage breaking after the logical
operators, and maybe also + and so on.  Relational and assignment operators
I care less about, and I don't see a strong reason to force a choice, so I'm 
with
option #2.

John.

> 
> -Andy
> ___
> 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] Proposal: Opaque SIL values

[John McCall via swift-dev]

> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev  
> wrote:
> I’m sending out a proposal for fundamentally changing SIL. This work feeds 
> into generic code optimization, resilience, semantic ARC, and SIL ownership. 
> This was discussed at length back in October—some info went out on 
> swift-dev—but I realized there hasn’t been a formal proposal. So here it is. 
> I want to make sure enough people have seen this before pushing my PR that 
> puts the infrastructure in place: https://github.com/apple/swift/pull/6922 
> .
> 
> Rendered Proposal: 
> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 
> 
> 
> Markdown:
> 

We've already talked about this at length, so I just want to say for the record 
that it looks great, and thanks for taking this on.

What's the purpose of SILFunctionConventions?  To provide a context with which 
to interpret the information in SILFunctionType?

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

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Philippe Hausler via swift-corelibs-dev]

You are probably missing the package libblocksruntime-dev. That would cause 
that failure.

Sent from my iPhone

> On Jan 26, 2017, at 6:33 AM, Dennis Schafroth  wrote:
> 
> Thanks for the suggestions. 
> 
> It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing 
> a Block.h which does exist in 3.0.2
> 
> :-Dennis
> 
>> On 26 Jan 2017, at 05.20, Philippe Hausler  wrote:
>> 
>> We should run those tests with ASAN, I thought I had fixed that with the 
>> Sierra merge.
>> 
>> Sent from my iPhone
>> 
>>> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Based on the backtrace, I think the code is running into a memory issue 
>>> with Swift Foundation:
>>> https://bugs.swift.org/browse/SR-2485
>>> https://bugs.swift.org/browse/SR-2462
>>> 
>>> I haven’t seen this in a while - are you able to try running on Swift 3.1 
>>> or 3.0.2?
>>> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
>>> You could also try replacing every 'let’ with ‘var’ but that might not be 
>>> the right solution :-)
>>> 
>>> Regards,
>>> Will Stanton
>>> 
 On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
  wrote:
 
 Hi
 
 Trying to do some simple date parsing from syslog format (“Jan 25 
 20:21:22”) into Date. Seem to work once but crashes on second call
 
 
 func dateConv(_ dateString: String) -> Date? {
 let dateFormatter = DateFormatter()
 dateFormatter.dateFormat = "MMM dd HH:mm"
 dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
 if let date = dateFormatter.date(from: dateString) {
  print("Real date: \(date)" )
  return date
 }
 return nil
 }
 
 var date  = dateConv("Jan 25 20:10")
 var date2 = dateConv("Jan 25 20:11”)
 
 # swift main.swift
 Real date: 2000-01-25 19:10:00 +
 0  swift0x0334ab78 
 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
 2  swift0x0334b6aa
 3  libpthread.so.0  0x7fec92166890
 4  libswiftCore.so  0x7fec8e8f0735
 5  libFoundation.so 0x7fec8c0ab6ee
 6  libFoundation.so 0x7fec8bd7a222
 7  libFoundation.so 0x7fec8bd7c623
 8  libFoundation.so 0x7fec8bf0e873 
 _TFC10Foundation6NSDateg11descriptionSS + 99
 9  libFoundation.so 0x7fec8c182829 
 _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
 10 libswiftCore.so  0x7fec8e78c745 
 _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
 
 using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
 
 cheers,
 :-Dennis
>>> 
>>> ___
>>> 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] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

[Dennis Schafroth via swift-corelibs-dev]

Thanks for the suggestions. 

It works with 3.0.2 but won't compile with 3.1 beta for Ubuntu 14.04. Missing a 
Block.h which does exist in 3.0.2

:-Dennis

> On 26 Jan 2017, at 05.20, Philippe Hausler  wrote:
> 
> We should run those tests with ASAN, I thought I had fixed that with the 
> Sierra merge.
> 
> Sent from my iPhone
> 
>> On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev 
>>  wrote:
>> 
>> Based on the backtrace, I think the code is running into a memory issue with 
>> Swift Foundation:
>> https://bugs.swift.org/browse/SR-2485
>> https://bugs.swift.org/browse/SR-2462
>> 
>> I haven’t seen this in a while - are you able to try running on Swift 3.1 or 
>> 3.0.2?
>> Your code seems to work on the IBM Sandbox with 3.0.2 but not 3.0.1.
>> You could also try replacing every 'let’ with ‘var’ but that might not be 
>> the right solution :-)
>> 
>> Regards,
>> Will Stanton
>> 
>>> On Jan 25, 2017, at 5:04 PM, Dennis Schafroth via swift-users 
>>>  wrote:
>>> 
>>> Hi
>>> 
>>> Trying to do some simple date parsing from syslog format (“Jan 25 
>>> 20:21:22”) into Date. Seem to work once but crashes on second call
>>> 
>>> 
>>> func dateConv(_ dateString: String) -> Date? {
>>> let dateFormatter = DateFormatter()
>>> dateFormatter.dateFormat = "MMM dd HH:mm"
>>> dateFormatter.locale = Locale(identifier: "da_DK_POSIX")
>>> if let date = dateFormatter.date(from: dateString) {
>>>   print("Real date: \(date)" )
>>>   return date
>>> }
>>> return nil
>>> }
>>> 
>>> var date  = dateConv("Jan 25 20:10")
>>> var date2 = dateConv("Jan 25 20:11”)
>>> 
>>> # swift main.swift
>>> Real date: 2000-01-25 19:10:00 +
>>> 0  swift0x0334ab78 
>>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
>>> 1  swift0x03349346 llvm::sys::RunSignalHandlers() + 54
>>> 2  swift0x0334b6aa
>>> 3  libpthread.so.0  0x7fec92166890
>>> 4  libswiftCore.so  0x7fec8e8f0735
>>> 5  libFoundation.so 0x7fec8c0ab6ee
>>> 6  libFoundation.so 0x7fec8bd7a222
>>> 7  libFoundation.so 0x7fec8bd7c623
>>> 8  libFoundation.so 0x7fec8bf0e873 
>>> _TFC10Foundation6NSDateg11descriptionSS + 99
>>> 9  libFoundation.so 0x7fec8c182829 
>>> _TTWV10Foundation4Dates23CustomStringConvertibleS_FS1_g11descriptionSS + 57
>>> 10 libswiftCore.so  0x7fec8e78c745 
>>> _TFs15_print_unlockedu0_R_s16TextOutputStreamrFTxRq__T_ + 997
>>> 
>>> using swift 3.0.1. Am I doing something wrong? I seems to work on macOS.
>>> 
>>> cheers,
>>> :-Dennis
>> 
>> ___
>> 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-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick via swift-dev]

Before I pull in a large PR that "accidentally" reformats a bunch of code, I 
want to get feedback on how Swift compiler devs plan to use `clang-format`. 
(BTW, here's the PR https://github.com/apple/swift/pull/6922).

During the code review, I ran `git clang-format` as part of being a good 
citizen. There's only one problem with the tool. It rewraps long boolean 
expressions, hiding those unsightly operators at the end of lines (after all 
who wants to see those?).

if (some_expression->with_calls() ||
another_expression->with(nested_calls()) &&
an_even_longer_expression->making_your_eyes->glaze_over())

I don't get involved in style wars, but this is not a style change, it's an 
objective code quality degradation. It's a demonstrably bug-prone thing to do. 
It's hurt me too many times in the past, and I'm not happy using a formatting 
tool that injects future bugs and harms code comprehension.

When the LLVM coding style was originally ratified, this aspect was left up to 
individual preference and didn't get any discussion AFAIK. I think
clang-format then ended up with a `BreakBeforeBinaryOperators: None` style out 
of sheer inertia. 

So, how should I use clang-format on Swift compiler code? Vote please.

** Option 1: Add a simple configuration option to swift/.clang-format:

1a. BreakBeforeBinaryOperators: All

1b. BreakBeforeBinaryOperators: NonAssignment

I have absolutely no preference between 1a and 1b. It's purely style.

1a:
SomeLongTypeName someLongVariableName =
  someLongExpression();

1b:
SomeLongTypeName someLongVariableName
  = someLongExpression();

** Option 2: Contributors each tweak clang-format according to their (in my 
case strong) bias:

My own command line:
2a. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: All}"
2b. " --style "{BasedOnStyle: LLVM, BreakBeforeBinaryOperators: NonAssignment}"

** Option 3: Don't bother using clang-format.

Let emacs do its indentation thing. Embrace idiosyncrasies in the code base.

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

Re: [swift-dev] Proposal: Opaque SIL values

[Andrew Trick via swift-dev]

> On Jan 25, 2017, at 4:22 PM, Karl Wagner  wrote:
> 
> 
>> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > > wrote:
>> 
>> I’m sending out a proposal for fundamentally changing SIL. This work feeds 
>> into generic code optimization, resilience, semantic ARC, and SIL ownership. 
>> This was discussed at length back in October—some info went out on 
>> swift-dev—but I realized there hasn’t been a formal proposal. So here it is. 
>> I want to make sure enough people have seen this before pushing my PR that 
>> puts the infrastructure in place: https://github.com/apple/swift/pull/6922 
>> .
>> 
>> Rendered Proposal: 
>> https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7 
>> 
>> 
>> Markdown:
>> 
>> 
>> -Andy
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> I won’t pretend to understand all of the implications of this, but as a 
> newcomer to the codebase I found SILGen (particularly lowering) extremely 
> confusing to unpick.
> 
> The simplification and separation described here makes a lot of sense to me, 
> and I believe it would make it easier for myself and others to contribute to 
> the project. As do your comments in the PR about using consistent idioms 
> throughout the compiler.
> 
> So as far as those things are considerations, I’m really happy with this 
> proposal.
> 
> - Karl


Thanks. I appreciate the encouragement. I’m actually trying not to add more 
complexity without offering some way to reason about it.

I added another section to the proposal that offers some background:
https://gist.github.com/atrick/38063a90bf4a6ebae05fe83ea9ebc0b7#sil-types-and-argument-conventions
 


...
Here's how this design fits into broader picture of the layers of
abstraction in the type system:

- Formal types: The AST types directly exposed by the language.
  (e.g. `T?`)

- Canonical types: desugared formal AST types.
  (e.g. `Optional`)

- Lowered types: Canonical types in the ASTContext that can be
  directly referenced by SIL. These "formalize" some properties of the
  ABI. For example, they make the ownership and indirection of
  function arguments explicit. These formalized conventions must match
  on both the caller and callee side of every call. Lowered types
  include types that aren't part of the language's formal type
  system. See SILFunctionType.  Although these types have been lowered
  for use by SIL, they exist independent of a SILModule.
  (e.g. `@in Optional`)

- SIL types: The actual type associated with a SIL value. These merely
  wrap a lowered type with a flag indicating whether the SIL value
  has indirect SIL semantics. i.e. whether the value is an address or
  an object type. SIL types are part of a SILModule, and reflect the
  SILModule's conventions. Mapping lowered types to SIL types is
  specific to the current SIL stage.
  (`e.g. $Optional`)

- SIL storage types: These are SIL types with lowered addresses.  They
  represent the ABI requirements for indirection and storage of SIL
  objects. In the "lowered" SIL stage, the SIL type of every value is
  its storage type. Lowered types directly correspond to SIL storage
  types. For example, if a function parameter has an `@in` lowered type, then
  the storage type of the corresponding SIL argument is an address.
  (`e.g. $*Optional`)

- LLVM types: Represent the ABI requirements in terms of C types. This
  could introduce additional indirection, but I'd like to handle most
  if not all of that in SIL address lowering.
  (e.g. `%Sq* noalias nocapture, %swift.type* %T`)
  
So to recap, if you ask for the SIL type corresponding to a formal
convention, you'll get the SIL *storage* type
(e.g. `$*Optional`). If you ask for the SIL type for a function
argument corresponding to the same formal parameter, you will get the
right level of indirection for the current SIL stage
(e.g. `$Optional`). In short, the lowered type may specify a calling
convention that expects indirect storage, while the SIL type may be
direct.

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

Re: [swift-dev] Proposal: Opaque SIL values

[Andrew Trick via swift-dev]

> On Jan 25, 2017, at 6:13 PM, Joe Groff  wrote:
> 
>> Naturally, opaque types must limit some optimizations, such as inlining.
> 
> I don't see how opaque types by themselves prevent inlining. You can inline a 
> generic into another generic, or a function using a resilient type into 
> another function.

Good point. I was just hand-waving here about resilient types, which we can’t 
inline by design, and archetypes where we can’t inline protocol methods because 
method resolution requires specialization. But yeah, we should be inlining 
methods on unbound generic nominal types. I updated the doc.

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