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

[Joe Groff via swift-dev]

> On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev 
>  wrote:
> 
> We need new runtime entry points that make sense for the new mirror
> implementation.  The current entry points (the _reflect() function and
> all its implementation details) directly depend on the old mirrors.
> This step is slightly harder, but not doesn't require extraordinary
> skills.  This part requires writing a proposal, because the runtime
> API is going to be stable.


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

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

Re: [swift-dev] Trying to work out how default parameters work

[Joe Groff via swift-dev]

> On Dec 8, 2015, at 2:43 AM, Brent Royal-Gordon via swift-dev 
>  wrote:
> 
> My first question is simply this: is this the best place for the sort of 
> question I’m about to ask? Is there an IRC channel or Slack or something 
> where people who are working with Swift’s compiler internals are hanging out? 
> Are people on Twitter (hi, Joe Groff!) going to mind if I pester them with 
> random weird questions about compiler guts? 

This is definitely the best place to ask implementation questions. 140 
characters isn't great for deep dives on compiler internals.

-Joe

> With the idea in mind that the most important thing I want to find out is 
> “where do I ask things like this?”, here goes.
> 
> *
> 
> Based on this post 
> ,
>  I’m trying to make memberwise initializers give default values to parameters 
> which have are initialized in their declaration. This is basically just a 
> quick prototype to (a) learn about how the Swift compiler works, and (b) try 
> to figure out what the implementation issues are going to be like. (For 
> instance, I’ve already noticed that if two properties are declared in the 
> same tuple, it may be difficult to grab their default values.)
> 
> My initial approach—which I’m well aware is probably all wrong—is to grab the 
> Expr from the property’s pattern binding and then attach it to the parameter 
> tuple as a default argument. I didn’t see any obvious way to clone an Expr, 
> so I’m basically just using the same instance and hoping for the best.
> 
> --- a/lib/Sema/CodeSynthesis.cpp
> +++ b/lib/Sema/CodeSynthesis.cpp
> @@ -1952,13 +1952,27 @@ ConstructorDecl 
> *swift::createImplicitConstructor(TypeChecker &tc,
>  auto *arg = new (context) ParamDecl(/*IsLet*/true, Loc, var->getName(),
>  Loc, var->getName(), varType, decl);
>  arg->setImplicit();
> +  
> +  auto initKind = DefaultArgumentKind::None;
> +  ExprHandle * initExpr = nullptr;
> +  
> +  // Is this property's default simple enough to copy?
> +  auto *varPatternBinding = var->getParentPatternBinding();
> +  if (varPatternBinding && varPatternBinding->getNumPatternEntries() == 
> 1) {
> +auto * init = varPatternBinding->getInit(0);
> +if(init) {
> +  initExpr = ExprHandle::get(context, init);
> +  initKind = DefaultArgumentKind::Normal;
> +}
> +  }
> +  
>  argNames.push_back(var->getName());
>  Pattern *pattern = new (context) NamedPattern(arg);
>  pattern->setImplicit();
>  TypeLoc tyLoc = TypeLoc::withoutLoc(varType);
>  pattern = new (context) TypedPattern(pattern, tyLoc);
>  patternElts.push_back(TuplePatternElt(var->getName(), SourceLoc(),
> -pattern, false));
> +pattern, false, SourceLoc(), 
> initExpr, initKind));
>}
>  }
> 
> This sort of works in that -dump-ast and -print-ast look right, but when I 
> let the rest of the compiler run, I get a crash half a dozen calls down from 
> SILGenModule::emitDefaultArgGenerator(). Apparently initExpr’s type is null, 
> causing an earth-shattering kaboom.
> 
> My working theory is that, because createImplicitConstructor() is called 
> during type checking, some part of the type check, or some earlier pass in 
> the compiler, is not being performed which would normally infer the types of 
> the default values. But I’m really flying blind here, so it could very well 
> be that I’m abusing the AST in some horrible way or missing some step I 
> should obviously be performing. (I did notice, for instance, that the doc 
> comment on ExprHandle is vaguely gesturing at the idea that an expression 
> might be connected to the same AST in two different places.)
> 
> So what I’d like to know is:
> 
> 1) Again, what’s the best venue for these sorts of “I’ve just stumbled into a 
> maze of twisty little passages" questions?
> 2) Is there any documentation on the AST design in general, or the 
> implementation of TuplePattern and default values in particular, that can 
> help me figure out this part of the code?
> 3) Does anyone recognize what might be happening here?
> 
> Thanks,
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Questions about _Reflectable and CustomReflectable

[Joe Groff via swift-dev]

> On Dec 8, 2015, at 11:44 AM, Austin Zheng via swift-dev  
> wrote:
> 
> Hello devs,
> 
> I have two questions about the _Reflectable and CustomReflectable protocols 
> in the stdlib. (These are both in context of Jira ticket SR-88.)
> 
> First, I notice that _Reflectable encompasses both CustomReflectable and 
> CustomPlaygroundQuickLookable's functionality. It looks like there are a 
> couple of _MirrorTypes that exist only to provide quicklook functionality. 
> Can I assume that, quicklook behavior aside, a _MirrorType conformer that is 
> hardcoded to report zero children can be replaced by the default runtime 
> mirror (e.g. the type who the _FoobarMirrorType belongs to doesn't need to 
> conform to CustomReflectable)?

There's some accretion here. We didn't have time to phase out _MirrorType 
completely, so the new Swift 2 interfaces are still implemented for some times 
by falling back to _MirrorType's implementation.

> Secondly, is there an explicit replacement for _MirrorType's "summary" 
> property? As-is, the current Mirror type provides no analogous property, and 
> in most cases the existing custom mirrors just return the object's 
> description. Was the "reflection summary" functionality broken out into a 
> third protocol, or dropped altogether?

IIRC it was decided that the summary wasn't usefully different from 
debugDescription; I believe playgrounds just use the debugDescription now.

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

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

[Joe Groff via swift-dev]

> On Dec 9, 2015, at 10:05 AM, Nick Wellnhofer via swift-dev 
>  wrote:
> 
> On 09/12/2015 18:55, Nick Wellnhofer via swift-dev wrote:
>>> Is there a better way to get that symbol, and why wasn’t this a problem for
>>> x86_64?
>> 
>> AFAICS, this is a problem for x86_64 Linux. It's not a problem on Apple
>> platforms, because there C++ binaries are linked with compiler-rt instead of
>> the GCC runtime.
> 
> Ah, you probably meant why __mulodi4 isn't a problem on x86_64 Linux. I think 
> that's because it's defined by the 64-bit GCC runtime. (clang on Linux uses 
> the GCC runtime AFAIK.)

Right, libgcc doesn't provide 128-bit integer entry points on 32-bit platforms, 
and doesn't provide the overflow-checking variant __muloti4 at all AFAIK.

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

Re: [swift-dev] Proof-of-concept port of Swift for Android

[Joe Groff via swift-dev]

> On Dec 8, 2015, at 8:57 PM, Chris Lattner via swift-dev  
> wrote:
> 
> On Dec 8, 2015, at 8:50 PM, Zhuowei Z via swift-dev  > wrote:
>> I'm currently working on adding support to the Swift compiler to allow it to 
>> target Android.
> 
> Cool.  Responding to one specific issue:
> 
>> - What's the role of the special linker script, and what's the purpose of 
>> the conformance tables in shared libraries? I've commented the conformance 
>> table loading code out on Android; is that why 'print("Hello world")' prints 
>> out "String(" infinity?
> 
> The linker script allows the compiler to be able to enumerate conformance 
> tables, which are part of reflection information.  I’m not an expert in this 
> area (Joe Groff or John McCall could better respond) but I would completely 
> believe the are the reason for your print failure.  print is defined as 
> taking an Any, and does a downcast to a protocol, and that is probably 
> failing.

Yes, this is exactly the problem. You'll need some way for the conformance 
sections from every .o file to be collected into a section of the final binary 
that the runtime can consult at runtime in swift_conformsToProtocol. Can the 
existing swift.ld script be adapted to work on Android?

-Joe

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

Re: [swift-dev] Initialization of default values

[Joe Groff via swift-dev]

> On Dec 9, 2015, at 3:28 PM, Matthew Johnson via swift-dev 
>  wrote:
> 
> I am working on a proposal for flexible memberwise initialization and would 
> like to understand how Swift currently handles initialization of members that 
> have a default specified in the declaration when an initializer does not 
> explicitly initialize them.  Can someone familiar with this provide a brief 
> summary or point me in the right direction to learn more (either 
> documentation or compiler code).

This is under flux. Currently the compiler emits a default argument generator 
function for each defaulted argument, and emits a corresponding call at any 
call site that uses the default argument. The idea behind this was that the 
value of the argument could be changed without breaking ABI, but in practice 
this has been problematic, and constrains resilience in other undesirable ways. 
We're planning to move to a more C++-like model, where the default argument 
expression is instantiated at each call site. I think Doug and Jordan would be 
the best ones to discuss both the current model and our planned final design.

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

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

[Joe Groff via swift-dev]

> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev  
> wrote:
> 
> In order to write textual SIL -> SIL testcases that exercise the handling of 
> debug information by SIL passes, we need to make a couple of additions to the 
> textual SIL language. In memory, the debug information attached to SIL 
> instructions references information from the AST. If we want to create debug 
> info from parsing a textual .sil file, these bits need to be made explicit.
> 
> Let me illustrate this with an example. The function
> 
>> func foo(x : Int) -> Int {
>>  return bar(x)
>> }
> 
> is compiled to SIL as 
> 
>> // main.foo (Swift.Int) -> Swift.Int
>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>> // %0 // users: %1, %2, %4
>> bb0(%0 : $Int):
>>  debug_value %0 : $Int  // let x, argno: 1   // id: %1 
>> line:1:10:in_prologue
>>  return %4 : $Int// id: %5 line:2:3:return
>> }
> 
> Note that there is a bunch of information available in comments that will be 
> lost once we parse that textual SIL again. I’d like to add syntax to SIL for 
> the information in the comments. This proposal deals with lifting the debug 
> variable information (the first comment) into actual SIL syntax. A similar 
> proposal for locations will be coming soon.
> With the proposed syntax, this could like like:
> 
>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>> bb0(%0 : $Int):
>>  debug_value %0 : $Int, !dbg_var(name: "x", type: "_TTSi", argno: 1)
>>  return %4 : $Int
>> }
> 
> More formally, debug variable info may be attached to debug_value, 
> debug_value_addr, alloc_box, and alloc_stack instructions.
> 
>  sil-instruction ::= 'alloc_stack' sil-type dbg-var
>  sil-instruction ::= 'alloc_stack' sil-type dbg-var
>  sil-instruction ::= debug_value sil-operand dbg-var
>  sil-instruction ::= debug_value_addr sil-operand dbg-var
>  dbg-var ::= ‘!dbg_var’ ‘(‘ var-attr (',' var-attr)*) ‘)'
>  var-attr ::= ‘name:’ string-literal
>  var-attr ::= ’type:’ string-literal
>  var-attr ::= ‘argno:’ integer-literal
> 
> This syntax for `dbg-var` is borrowed straight from LLVM IR and thus invokes 
> a familiar feeling. Since the primary use-case of it will be in test cases, 
> the verbose dictionary-like syntax is really helpful.
> 
> Syntax alternatives I’ve considered and rejected include:
> 1. debug_value %0 : $Int, “x”, “_TtSi”, 1
>   Why: Hard to read, potentially ambiguous because some fields are optional.
> 
> 2. debug_value [name “x”] [type “_TtSi”] [argno 1] %0 : $Int
>   Why: Attributes in square brackets don’t typically have arguments and come 
> before the entity they are modifying.
> 
> 3. debug_value @var(name: “x”, type: “_TtSi”, argno: 1) %0 : $Int
>   Why: The ‘@‘ sigil is used not just for attributes but also for global 
> symbols and thus creates an ambiguity.

Thanks for working on this, Adrian! My thoughts:

- I don't see a reason to mangle the type name at SIL time. You should 
reference the formal AST type directly in the instruction, and print and parse 
it using the normal (Swift) type parser.
- Since these are core parts of the instruction, I would say they need no 
decoration at all; they should just be part of the instruction syntax:

debug_value %0 : $Int, name "x", type $Int, argno 1

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

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

[Joe Groff via swift-dev]

> On Dec 10, 2015, at 9:29 AM, William Dillon  wrote:
> 
> Yep.  I see that are a few of those in there (1700 and change).  When it 
> comes to linking and ELF, I am fumbling in the dark a bit.  With the hope of 
> getting some context, I decided to see whether R_ARM_REL32 is used in any 
> other shared libraries in the system; it is not.  It seems as though 
> R_ARM_REL32 is not appropriate for use in dynamic libraries, but the 
> generated swift executables are trying to use it that way.  I thought I 
> remembered that swift binaries are only capable of static liking for the time 
> being, is that true?  Could the problem be as simple as the compiler that I 
> built on ARM is trying to emit executables expecting dynamic linking when 
> that’s not supported yet?

We use relative references to symbols in the conformance table to avoid the 
need for the dynamic linker to eagerly resolve relocations. These should be 
wholly internal to the image, though, and resolvable by the static linker. I'm 
not sure why they'd persist to dynamic linking time like this.

-Joe

> I’m building the debug variant (I’ve been using release due to the memory 
> requirements of linking debug) now to see if it does the same thing.  I don’t 
> understand why the arch. change would cause differences here.
> 
> By the way, that pull request for module.map looks perfect.  I’ll have to 
> wait for it to merge in before I can prepare any kind of pull request of my 
> own.  I think that is the only thing that breaks other builds that I don’t 
> know how to fix on my own.
> 
> Thanks,
> - Will
> 
>> On Dec 9, 2015, at 8:23 PM, Dmitri Gribenko  wrote:
>> 
>> Here's a relevant line (there are lots, this is just one instance):
>> 
>> 003a91cc  0015d403 R_ARM_REL32   003af914   _TMps13GeneratorType
>> 
>> _TMps13GeneratorType ---> protocol descriptor for Swift.GeneratorType
>> 
>> Dmitri
>> 
>> On Wed, Dec 9, 2015 at 7:25 PM, William Dillon  
>> wrote:
>>> I’m looking at that pull request currently, thanks for the link.
>>> 
>>> Here is the output of readelf -r for libswiftcore, test.swift (as compiled)
>>> and test.swift.
>>> 
>>> Thanks for looking into this!
>>> - Will
>>> 
>>> 
>>> 
>>> On Dec 9, 2015, at 7:14 PM, Dmitri Gribenko  wrote:
>>> 
>>> On Wed, Dec 9, 2015 at 7:05 PM, Dmitri Gribenko  wrote:
>>> 
>>> On Wed, Dec 9, 2015 at 3:05 PM, William Dillon via swift-dev
>>>  wrote:
>>> 
>>> Nick was correct in noting that __muloti4 wasn’t needed on 32-bit platforms.
>>> I added another case to the preprocessor conditional for __muloti4, and
>>> specified __arm__ and __linux__ for mulodi4.  The __multi3 and __divti3
>>> references went away.
>>> 
>>> Then, I went on to the module.map file for bringing in the Glibc headers.
>>> I’m trying to think of a way to either remove the architecture specific
>>> paths to many of those libraries (they’re now x86_64-linux-gnu, but need to
>>> be arm-linux-gnueabihf for arm).  I read the modules documentation at
>>> http://clang.llvm.org/docs/Modules.html and it doesn’t look like it’s
>>> possible to have conditionals in there.  I’m considering whether it’s a good
>>> idea to preprocess that file in some way to fill them out with the correct
>>> paths in the build scripts.  I went ahead and changed them all (breaking
>>> x86_64 for the time being).
>>> 
>>> 
>>> Did you try https://github.com/apple/swift/pull/282 ?
>>> 
>>> At this point, the compiler and standard library are all built, and I think
>>> I have one final issue.  In the testing suite, the binaries generated by the
>>> swift compiler don’t run.  They’re emitting unexpected reloc type errors.
>>> It appears that reolc type 0x03 is R_ARM_REL32 which is not permitted for
>>> use with shared libraries:
>>> 
>>> CollectionOfOne.swift.tmp/a.out: error while loading shared libraries:
>>> /home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/lib/swift/linux/libswiftCore.so:
>>> unexpected reloc type 0x03
>>> 
>>> This also happens with small example swift programs that I’ve written for
>>> testing.
>>> 
>>> 
>>> +John for this error.
>>> 
>>> 
>>> It would be also helpful if you could find which code contains these
>>> relocations.  Try 'objdump -R libswiftCore.so' or 'readelf -r'.
>>> 
>>> Dmitri
>>> 
>>> --
>>> main(i,j){for(i=2;;i++){for(j=2;j>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
> 

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

Re: [swift-dev] Proof-of-concept port of Swift for Android

[Joe Groff via swift-dev]

> On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev 
>  wrote:
> 
> 
>> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev  
>> wrote:
>> 
>> Hi, maybe one of the Apple devs can help out with this quick Q:
>> 
>> To interface with the JNI, we’d presumably need to call swift functions from 
>> our compiled swift binaries from C (or directly from Java, the result being 
>> the same). Is there a way to demangle certain symbols in the output binary 
>> to this effect, or is there another / a better way to access Swift functions 
>> from C?
> 
> Others can probably give a more detailed response, but...
> 
> There’s a Swift demangler in Swift’s “Basic” library 
> (lib/Basic/Demangle.cpp), along with a standalone tool (swift-demangle) you 
> can experiment with. The information in the mangled name should be complete 
> enough to call, but you’ll need to match Swift’s calling convention.
> 
> If it’s just a specific set of Swift functions you want to call from C, you 
> can use the @_silgen_name attribute to override the mangled name, and/or make 
> them @convention(c) to use the C calling convention.

@_silgen_name isn't the right answer here, since the convention will be wrong, 
and it won't interact properly with Clang imports and exports. Like Slava said, 
you want something like the '@_cdecl' attribute he proposed and I 
half-implemented.

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

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

[Joe Groff via swift-dev]

> On Dec 15, 2015, at 1:25 PM, Adrian Prantl  wrote:
> 
>> 
>> On Dec 10, 2015, at 10:19 AM, John McCall  wrote:
>> 
>>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev  
>>> wrote:
>>>> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev 
>>>>  wrote:
>>>> 
>>>> In order to write textual SIL -> SIL testcases that exercise the handling 
>>>> of debug information by SIL passes, we need to make a couple of additions 
>>>> to the textual SIL language. In memory, the debug information attached to 
>>>> SIL instructions references information from the AST. If we want to create 
>>>> debug info from parsing a textual .sil file, these bits need to be made 
>>>> explicit.
>>>> 
>>>> Let me illustrate this with an example. The function
>>>> 
>>>>> func foo(x : Int) -> Int {
>>>>> return bar(x)
>>>>> }
>>>> 
>>>> is compiled to SIL as 
>>>> 
>>>>> // main.foo (Swift.Int) -> Swift.Int
>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>> // %0 // users: %1, %2, %4
>>>>> bb0(%0 : $Int):
>>>>> debug_value %0 : $Int  // let x, argno: 1   // id: %1 
>>>>> line:1:10:in_prologue
>>>>> return %4 : $Int// id: %5 line:2:3:return
>>>>> }
>>>> 
>>>> Note that there is a bunch of information available in comments that will 
>>>> be lost once we parse that textual SIL again. I’d like to add syntax to 
>>>> SIL for the information in the comments. This proposal deals with lifting 
>>>> the debug variable information (the first comment) into actual SIL syntax. 
>>>> A similar proposal for locations will be coming soon.
>>>> With the proposed syntax, this could like like:
>>>> 
>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>> bb0(%0 : $Int):
>>>>> debug_value %0 : $Int, !dbg_var(name: "x", type: "_TTSi", argno: 1)
>>>>> return %4 : $Int
>>>>> }
>>>> 
>>>> More formally, debug variable info may be attached to debug_value, 
>>>> debug_value_addr, alloc_box, and alloc_stack instructions.
>>>> 
>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>> sil-instruction ::= debug_value sil-operand dbg-var
>>>> sil-instruction ::= debug_value_addr sil-operand dbg-var
>>>> dbg-var ::= ‘!dbg_var’ ‘(‘ var-attr (',' var-attr)*) ‘)'
>>>> var-attr ::= ‘name:’ string-literal
>>>> var-attr ::= ’type:’ string-literal
>>>> var-attr ::= ‘argno:’ integer-literal
>>>> 
>>>> This syntax for `dbg-var` is borrowed straight from LLVM IR and thus 
>>>> invokes a familiar feeling. Since the primary use-case of it will be in 
>>>> test cases, the verbose dictionary-like syntax is really helpful.
>>>> 
>>>> Syntax alternatives I’ve considered and rejected include:
>>>> 1. debug_value %0 : $Int, “x”, “_TtSi”, 1
>>>> Why: Hard to read, potentially ambiguous because some fields are optional.
>>>> 
>>>> 2. debug_value [name “x”] [type “_TtSi”] [argno 1] %0 : $Int
>>>> Why: Attributes in square brackets don’t typically have arguments and come 
>>>> before the entity they are modifying.
>>>> 
>>>> 3. debug_value @var(name: “x”, type: “_TtSi”, argno: 1) %0 : $Int
>>>> Why: The ‘@‘ sigil is used not just for attributes but also for global 
>>>> symbols and thus creates an ambiguity.
>>> 
>>> Thanks for working on this, Adrian! My thoughts:
>>> 
>>> - I don't see a reason to mangle the type name at SIL time. You should 
>>> reference the formal AST type directly in the instruction, and print and 
>>> parse it using the normal (Swift) type parser.
>> 
>> In addition to all the other good reasons to do this, this means that 
>> archetypes in the type will be (1) sensibly bound in the context and (2) 
>> actually substituted by inlining and generic specialization.
> 
> By deferring the type mangling to IRGen time I’m hitting an interesting 
> problem:
> 
> Let’s say we have the function
>  func id(x : T) -> T { retur

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

[Joe Groff via swift-dev]

> On Dec 15, 2015, at 2:34 PM, Adrian Prantl  wrote:
> 
>> 
>> On Dec 15, 2015, at 2:27 PM, Joe Groff  wrote:
>> 
>>> 
>>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl  wrote:
>>> 
>>>> 
>>>> On Dec 10, 2015, at 10:19 AM, John McCall  wrote:
>>>> 
>>>>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev 
>>>>>  wrote:
>>>>>> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev 
>>>>>>  wrote:
>>>>>> 
>>>>>> In order to write textual SIL -> SIL testcases that exercise the 
>>>>>> handling of debug information by SIL passes, we need to make a couple of 
>>>>>> additions to the textual SIL language. In memory, the debug information 
>>>>>> attached to SIL instructions references information from the AST. If we 
>>>>>> want to create debug info from parsing a textual .sil file, these bits 
>>>>>> need to be made explicit.
>>>>>> 
>>>>>> Let me illustrate this with an example. The function
>>>>>> 
>>>>>>> func foo(x : Int) -> Int {
>>>>>>> return bar(x)
>>>>>>> }
>>>>>> 
>>>>>> is compiled to SIL as 
>>>>>> 
>>>>>>> // main.foo (Swift.Int) -> Swift.Int
>>>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>>>> // %0 // users: %1, %2, %4
>>>>>>> bb0(%0 : $Int):
>>>>>>> debug_value %0 : $Int  // let x, argno: 1   // id: %1 
>>>>>>> line:1:10:in_prologue
>>>>>>> return %4 : $Int// id: %5 
>>>>>>> line:2:3:return
>>>>>>> }
>>>>>> 
>>>>>> Note that there is a bunch of information available in comments that 
>>>>>> will be lost once we parse that textual SIL again. I’d like to add 
>>>>>> syntax to SIL for the information in the comments. This proposal deals 
>>>>>> with lifting the debug variable information (the first comment) into 
>>>>>> actual SIL syntax. A similar proposal for locations will be coming soon.
>>>>>> With the proposed syntax, this could like like:
>>>>>> 
>>>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>>>> bb0(%0 : $Int):
>>>>>>> debug_value %0 : $Int, !dbg_var(name: "x", type: "_TTSi", argno: 1)
>>>>>>> return %4 : $Int
>>>>>>> }
>>>>>> 
>>>>>> More formally, debug variable info may be attached to debug_value, 
>>>>>> debug_value_addr, alloc_box, and alloc_stack instructions.
>>>>>> 
>>>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>>>> sil-instruction ::= debug_value sil-operand dbg-var
>>>>>> sil-instruction ::= debug_value_addr sil-operand dbg-var
>>>>>> dbg-var ::= ‘!dbg_var’ ‘(‘ var-attr (',' var-attr)*) ‘)'
>>>>>> var-attr ::= ‘name:’ string-literal
>>>>>> var-attr ::= ’type:’ string-literal
>>>>>> var-attr ::= ‘argno:’ integer-literal
>>>>>> 
>>>>>> This syntax for `dbg-var` is borrowed straight from LLVM IR and thus 
>>>>>> invokes a familiar feeling. Since the primary use-case of it will be in 
>>>>>> test cases, the verbose dictionary-like syntax is really helpful.
>>>>>> 
>>>>>> Syntax alternatives I’ve considered and rejected include:
>>>>>> 1. debug_value %0 : $Int, “x”, “_TtSi”, 1
>>>>>> Why: Hard to read, potentially ambiguous because some fields are 
>>>>>> optional.
>>>>>> 
>>>>>> 2. debug_value [name “x”] [type “_TtSi”] [argno 1] %0 : $Int
>>>>>> Why: Attributes in square brackets don’t typically have arguments and 
>>>>>> come before the entity they are modifying.
>>>>>> 
>>>>>> 3. debug_value @var(name: “x”, type: “_TtSi”, argno: 1) %0 : $Int
>>>>>> Why: The ‘@‘ sigil is used not just for attributes but also for global 
>>>>>

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 15, 2015, at 8:12 AM, Ryan Lovelett via swift-dev 
>  wrote:
> 
> I've been playing around with a Swift wrapper for the FFmpeg C libraries
> (e.g., libavutil, libavcodec, libavformat, etc...). While providing some
> extensions to some of the core C structures I've run into something that
> doesn't feel quite right to me.
> 
> Before I provide a discussion here is a Gist [0] that I hope illustrates
> the problem.
> 
> When inside of a Swift function declaration if I take `self` and send it
> to `withUnsafePointer` Swift requires the function to mark the function
> as `mutating`. This surprised me. Thanks to Swift being open source (🎉)
> I was able to go look at the implementation of `withUnsafePointer` [1].
> And I'm no longer surprised that its required by the compiler; the
> definition marks the argument as `inout`.
> 
> However, this seems wrong to me. In the "Pointers" section of "Using
> Swift with Cocoa and Objective-C (Swift 2.1)" [2] it says that `cost
> Type *` (pointer to a constant value) is equivalent to
> `UnsafePointer`. My understanding of C says that `const Type *`
> means that the instance of `Type` that the pointer points to cannot be
> modified. This corresponds with my understanding of the difference
> between `UnsafePointer` and `UnsafeMutablePointer`.
> 
> Therefore, from my perspective I feel like there is a bug here. It also
> seems that marking the `arg` of `withUnsafePointer` to `var` instead of
> `inout` would allow it to compile and would more closely model the
> `UnsafePointer`. I'm still new to all this and I don't want to make a
> fool of myself. So I'd rather ask here before I move forward and file a
> bug and MR.

Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to 
take an immutable parameter. Since this is a stdlib API change, you should 
suggest that on swift-evolution.

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

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

[Joe Groff via swift-dev]

Yeah, option 1 seems reasonable to me. I might give it attribute-like spelling, 
though, to help bracket it and keep it separate from the real name and 
declaration:

sil [debug_decl_context test.foo :  (T) -> ()] @_Tfoo : $... {
}

-Joe

> On Dec 15, 2015, at 4:30 PM, Adrian Prantl  wrote:
> 
>> 
>> On Dec 15, 2015, at 2:37 PM, Joe Groff  wrote:
>> 
>>> 
>>> On Dec 15, 2015, at 2:34 PM, Adrian Prantl  wrote:
>>> 
>>>> 
>>>> On Dec 15, 2015, at 2:27 PM, Joe Groff  wrote:
>>>> 
>>>>> 
>>>>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl  wrote:
>>>>> 
>>>>>> 
>>>>>> On Dec 10, 2015, at 10:19 AM, John McCall  wrote:
>>>>>> 
>>>>>>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev 
>>>>>>>  wrote:
>>>>>>>> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev 
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> In order to write textual SIL -> SIL testcases that exercise the 
>>>>>>>> handling of debug information by SIL passes, we need to make a couple 
>>>>>>>> of additions to the textual SIL language. In memory, the debug 
>>>>>>>> information attached to SIL instructions references information from 
>>>>>>>> the AST. If we want to create debug info from parsing a textual .sil 
>>>>>>>> file, these bits need to be made explicit.
>>>>>>>> 
>>>>>>>> Let me illustrate this with an example. The function
>>>>>>>> 
>>>>>>>>> func foo(x : Int) -> Int {
>>>>>>>>> return bar(x)
>>>>>>>>> }
>>>>>>>> 
>>>>>>>> is compiled to SIL as 
>>>>>>>> 
>>>>>>>>> // main.foo (Swift.Int) -> Swift.Int
>>>>>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>>>>>> // %0 // users: %1, %2, %4
>>>>>>>>> bb0(%0 : $Int):
>>>>>>>>> debug_value %0 : $Int  // let x, argno: 1   // id: %1 
>>>>>>>>> line:1:10:in_prologue
>>>>>>>>> return %4 : $Int// id: %5 
>>>>>>>>> line:2:3:return
>>>>>>>>> }
>>>>>>>> 
>>>>>>>> Note that there is a bunch of information available in comments that 
>>>>>>>> will be lost once we parse that textual SIL again. I’d like to add 
>>>>>>>> syntax to SIL for the information in the comments. This proposal deals 
>>>>>>>> with lifting the debug variable information (the first comment) into 
>>>>>>>> actual SIL syntax. A similar proposal for locations will be coming 
>>>>>>>> soon.
>>>>>>>> With the proposed syntax, this could like like:
>>>>>>>> 
>>>>>>>>> sil hidden @_TF4main3fooFSiSi : $@convention(thin) (Int) -> Int {
>>>>>>>>> bb0(%0 : $Int):
>>>>>>>>> debug_value %0 : $Int, !dbg_var(name: "x", type: "_TTSi", argno: 1)
>>>>>>>>> return %4 : $Int
>>>>>>>>> }
>>>>>>>> 
>>>>>>>> More formally, debug variable info may be attached to debug_value, 
>>>>>>>> debug_value_addr, alloc_box, and alloc_stack instructions.
>>>>>>>> 
>>>>>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>>>>>> sil-instruction ::= 'alloc_stack' sil-type dbg-var
>>>>>>>> sil-instruction ::= debug_value sil-operand dbg-var
>>>>>>>> sil-instruction ::= debug_value_addr sil-operand dbg-var
>>>>>>>> dbg-var ::= ‘!dbg_var’ ‘(‘ var-attr (',' var-attr)*) ‘)'
>>>>>>>> var-attr ::= ‘name:’ string-literal
>>>>>>>> var-attr ::= ’type:’ string-literal
>>>>>>>> var-attr ::= ‘argno:’ integer-literal
>>>>>>>> 
>>>>>>>> This syntax for `dbg-var` is borrowed straight from LLVM IR and thus 
>>>>>>>> invok

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev 
>  wrote:
> 
> On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote:
>> 
>>> Come to think of it, what's the actual use-case for withUnsafePointer()?
>> 
>> I'm not sure we still have one that isn't covered by &x; that's my point.
>> 
>>> If a value is mutable, you can already use &x or 
>>> withUnsafeMutablePointer(), and if it's immutable, you can't call 
>>> withUnsafePointer() today anyway. The proposed change would just make 
>>> withUnsafePointer() into the equivalent of `var x = value; 
>>> callSomethingWith(&x)`. The only reason to really want a 
>>> withUnsafePointer() function is if it can give you an UnsafePointer to an 
>>> immutable value without copying it, but we can't do that. I'm inclined to 
>>> say we should just get rid of withUnsafePointer() entirely, at least until 
>>> such time as Swift has a way to pass immutable values by-ref.
>> 
>> I'm inclined to agree.  Proposal?
> 
> Sure, I'll write one up. I suspect that withUnsafePointer() / 
> withUnsafeMutablePointer() are likely to be rarely used today, and most uses 
> can probably be trivially replaced with just passing a &x ref, so this 
> shouldn't be a big deal.

We can't remove withUnsafe[Mutable]Pointer; as I mentioned to Dave, it's 
necessary to persist a pointer for more than one immediate call.

> 
> I'll also go ahead and write up one suggesting that we should allow for using 
> &x when x is immutable when passing a parameter to a function that takes 
> UnsafePointer.

That would be useful, though I would argue that the '&' shouldn't be necessary. 
We aren't C; '&x' means "this call mutates x", not "I'm taking a pointer to x".

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

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev 
>  wrote:
> 
> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
>> 
>> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to 
>> take an immutable parameter. Since this is a stdlib API change, you should 
>> suggest that on swift-evolution.
> 
> A change like that is going to break any code that relies on the inout 
> optimization (where it uses call-by-reference instead of copy-in copy-out 
> when possible). Yes, such code is in violation of Swift semantics today, but 
> it does work.

If a value is immutable, it should be easy for the compiler to reuse the 
address of memory it may already be using for it. 

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

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 15, 2015, at 6:39 PM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev 
>>  wrote:
>> 
>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
>>> 
>>> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' 
>>> to take an immutable parameter. Since this is a stdlib API change, you 
>>> should suggest that on swift-evolution.
>> 
>> A change like that is going to break any code that relies on the inout 
>> optimization (where it uses call-by-reference instead of copy-in copy-out 
>> when possible). Yes, such code is in violation of Swift semantics today, but 
>> it does work.
> 
> Two questions:
> 
> 1. Don’t we want a withUnsafeMutablePointer for the mutating cases (where the 
> inout optimization can take effect) anyway?

Yeah, a withUnsafeMutablePointer variant that is inout would be necessary.

> 2. Joe, these APIs predate many of your changes that make &x transparently 
> convert to Unsafe[Mutable]Pointer arguments.  Are they obsolete?  Can we 
> replace them with { x: Unsafe[Mutable]Pointer in … }(&y) ?

Not if you need the same pointer across multiple calls, or you need to convert 
or adjust the pointer before the call. A call like foo(&x) that involves a 
pointer conversion only guarantees that pointer for that exact call, as if 
you'd written withUnsafe[Mutable]Pointer(&x) { foo($0) }. 

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

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 16, 2015, at 10:34 AM, John McCall via swift-dev  
> wrote:
> 
>> On Dec 16, 2015, at 12:12 AM, Dave Abrahams via swift-dev 
>>  wrote:
>>> On Dec 15, 2015, at 11:51 PM, Kevin Ballard  wrote:
>>> On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote:
>>>> 
>>>>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard  wrote:
>>>>> 
>>>>> On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote:
>>>>>> 
>>>>>>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
>>>>>>>> 
>>>>>>>> Yeah, it seems to me like a reasonable refinement for 
>>>>>>>> 'withUnsafePointer' to take an immutable parameter. Since this is a 
>>>>>>>> stdlib API change, you should suggest that on swift-evolution.
>>>>>>> 
>>>>>>> A change like that is going to break any code that relies on the inout 
>>>>>>> optimization (where it uses call-by-reference instead of copy-in 
>>>>>>> copy-out when possible). Yes, such code is in violation of Swift 
>>>>>>> semantics today, but it does work.
>>>>>> 
>>>>>> Two questions:
>>>>>> 
>>>>>> 1. Don’t we want a withUnsafeMutablePointer for the mutating cases 
>>>>>> (where the inout optimization can take effect) anyway?
>>>>> 
>>>>> I'm thinking here of cases like passing a context pointer to KVO. You're 
>>>>> not actually mutating it, you just need a pointer that's the same every 
>>>>> time you call the code.
>>>> 
>>>> Well, it is not possible to code a version of withUnsafePointer that makes 
>>>> that guarantee in Swift.
>>> 
>>> Yeah but we want to move in the direction of making that more reliable, not 
>>> less.
>> 
>> I am not sure I agree with you.  I would defer to John McCall on this one, 
>> but my understanding is that it's an explicit non-goal to make that 
>> guarantee.
> 
> I think it’s useful to be able to make this guarantee for some variables; I 
> just don’t want it to be assumed for all variables.  I’m okay with the idea 
> that &myGlobalStoredVar will consistently yield the same pointer.

I agree we can make that guarantee for globals, and maybe local stored 
properties as well. It's tricky to do that for potentially computed properties, 
which includes any class properties or properties outside your resilience 
domain, so though we can make a best effort not to wantonly change pointer 
identity across calls that take pointers to the same property, I don't think we 
can fully eliminate the need for an explicit withUnsafePointer form.

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

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 16, 2015, at 11:47 AM, Kevin Ballard  wrote:
> 
> On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote:
>> 
>>> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev 
>>>  wrote:
>>> 
>>> On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote:
 
> Come to think of it, what's the actual use-case for withUnsafePointer()?
 
 I'm not sure we still have one that isn't covered by &x; that's my point.
 
> If a value is mutable, you can already use &x or 
> withUnsafeMutablePointer(), and if it's immutable, you can't call 
> withUnsafePointer() today anyway. The proposed change would just make 
> withUnsafePointer() into the equivalent of `var x = value; 
> callSomethingWith(&x)`. The only reason to really want a 
> withUnsafePointer() function is if it can give you an UnsafePointer to an 
> immutable value without copying it, but we can't do that. I'm inclined to 
> say we should just get rid of withUnsafePointer() entirely, at least 
> until such time as Swift has a way to pass immutable values by-ref.
 
 I'm inclined to agree.  Proposal?
>>> 
>>> Sure, I'll write one up. I suspect that withUnsafePointer() / 
>>> withUnsafeMutablePointer() are likely to be rarely used today, and most 
>>> uses can probably be trivially replaced with just passing a &x ref, so this 
>>> shouldn't be a big deal.
>> 
>> We can't remove withUnsafe[Mutable]Pointer; as I mentioned to Dave, it's 
>> necessary to persist a pointer for more than one immediate call.
> 
> Rare cases like that can be covered by either declaring a nested function 
> taking the pointer and calling it, calling an anonymous local closure of the 
> right type, or even using withExtendedLifetime(&x) { (ptr: UnsafePointer) 
> in ... }.

These are all just withUnsafePointer with different spelling.

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

Re: [swift-dev] `withUnsafePointer` mutates `self`

[Joe Groff via swift-dev]

> On Dec 16, 2015, at 11:59 AM, Kevin Ballard  wrote:
> 
> On Wed, Dec 16, 2015, at 11:49 AM, Joe Groff wrote:
>>  
>>> On Dec 16, 2015, at 11:47 AM, Kevin Ballard >> > wrote:
>>>  
>>> On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote:
  
> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
>  
> On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote:
>>  
>>> Come to think of it, what's the actual use-case for withUnsafePointer()?
>>  
>> I'm not sure we still have one that isn't covered by &x; that's my point.
>>  
>>> If a value is mutable, you can already use &x or 
>>> withUnsafeMutablePointer(), and if it's immutable, you can't call 
>>> withUnsafePointer() today anyway. The proposed change would just make 
>>> withUnsafePointer() into the equivalent of `var x = value; 
>>> callSomethingWith(&x)`. The only reason to really want a 
>>> withUnsafePointer() function is if it can give you an UnsafePointer to 
>>> an immutable value without copying it, but we can't do that. I'm 
>>> inclined to say we should just get rid of withUnsafePointer() entirely, 
>>> at least until such time as Swift has a way to pass immutable values 
>>> by-ref.
>>  
>> I'm inclined to agree.  Proposal?
>  
> Sure, I'll write one up. I suspect that withUnsafePointer() / 
> withUnsafeMutablePointer() are likely to be rarely used today, and most 
> uses can probably be trivially replaced with just passing a &x ref, so 
> this shouldn't be a big deal.
  
 We can't remove withUnsafe[Mutable]Pointer; as I mentioned to Dave, it's 
 necessary to persist a pointer for more than one immediate call.
>>>  
>>> Rare cases like that can be covered by either declaring a nested function 
>>> taking the pointer and calling it, calling an anonymous local closure of 
>>> the right type, or even using withExtendedLifetime(&x) { (ptr: 
>>> UnsafePointer) in ... }.
>>  
>> These are all just withUnsafePointer with different spelling.
>  
> That's true, but they all have the benefit of not requiring extra stdlib 
> functions. swiftdoc.org lists 36 global functions, a full 4 of which are 
> withUnsafePointer + variants. The existence of the functions also implies 
> that they're necessary to work with pointers (especially the documentation). 
> My suspicion is that nearly all current uses of these functions can be 
> replaced with &x refs with no change in functionality. Even the stdlib only 
> has a handful of uses of withUnsafeMutablePointer (and none at all for 
> withUnsafePointer), and looking through them quickly, it looks like only the 
> ones in public/core/Runtime.swift.gyb require a workaround.
>  

The standard library isn't a representative sample, since it doesn't interact 
directly with that much C code. I would check out Github for more information; 
I've had a number of discussions with developers who were doing things that are 
only possible with withUnsafePointer.

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

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

[Joe Groff via swift-dev]

> On Dec 17, 2015, at 3:37 AM, Emanuel Zephir via swift-dev 
>  wrote:
> 
> Okay, that works.
> 
> I have a few questions about SR-210:
> 
> 1) The attached patch adds support for undefined integer value-cases in the 
> switch_value instruction. What is the runtime meaning of this construct?

SIL 'undef' has the same meaning as LLVM's 'undef'. It means that the exact 
value isn't important and can be substituted with an arbitrary bit pattern. 
It's UB if the behavior of the program depends on the value of an undef, but 
safe if the undef can be eliminated, such as if it's dead, or eliminated by an 
operation like 'x & 0' or 'x - x' that's invariant of 'x'.

> 2) Are there any other SIL instructions in the select/switch family that need 
> modifications? If yes, which? At least some of them (e.g. select_value) don't 
> support this either.

'undef' ought to be parsed as part of the SIL value grammar. It'd be worth 
doing a pass to make sure we consistently use the same parsing rule everywhere 
we accept a value.

-Joe

> 3) Are there any areas that need special attention when writing tests and 
> otherwise validating this change?
> 
> 
> --Emanuel
> 
> On Wed, Dec 16, 2015 at 10:15 AM, Michael Gottesman  > wrote:
> SGTM. If you want as you finish these, I have a list of them = ).
> 
> I just filed another one:
> 
> https://bugs.swift.org/browse/SR-247 
> 
> Michael
> 
>> On Dec 16, 2015, at 5:30 AM, Emanuel Zephir > > wrote:
>> 
>> Unless anyone objects, I'd like to claim this. I've assigned issue SR-210 to 
>> myself.
>> 
>> --Emanuel
>> 
>> On Sun, Dec 13, 2015 at 1:29 PM, Michael Gottesman via swift-dev 
>> mailto:swift-dev@swift.org>>wrote:
>> This is a small starter project for those who are interested in working with 
>> SIL.
>> 
>> The SIL Parser currently is unable to parse switch_enum of undef. I wrote a 
>> patch that does the work some time ago, but I never have had time to finish 
>> it (i.e. make sure everything works ok/write tests). I posted the patch in 
>> this issue:
>> 
>> https://bugs.swift.org/browse/SR-210 
>> 
>> My hope is that even though a lot of the work is already done this may serve 
>> as good starting point for someone who wants to poke at the SIL Parser (a 
>> part of the code base that has not gotten as much attention as others).
>> 
>> Michael
>> 
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-dev 
>> 
>> 
>> 
> 
> 
>  ___
> swift-dev mailing list
> swift-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-dev 
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] inout and aliasing in the optimizer

[Joe Groff via swift-dev]

> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev 
>  wrote:
> 
> Hi,
> 
> I'm currently working on improving alias analysis in the optimizer and I run 
> into following problem:
> 
> If alias analysis assumes that inout may not alias any other object, we may 
> violate memory safety. Note that currently it's not always assumed, e.g. not 
> in computeMemoryBehavior for apply insts.
> 
> As I understood, if the inout rule is violated, the program is not expected 
> to behave as intended, but is still must be memory safe.
> For this reason we had to insert explicit checks for inout violations in the 
> stdlib, e.g. in ArrayBuffer: _precondition(_isNativeTypeChecked == 
> wasNativeTypeChecked, "inout rules were violated: the array was overwritten")
> 
> Now with improved alias analysis and assuming inout-no-alias, the optimizer 
> (specifically redundant load elimination) may eliminate these precondition 
> checks in the stdlib.
> And I can think of other cases, e.g.
> 
> sil @test(@inout %1 : $*C) {
>   %2 = load %1
>   apply inout_violating_function // replaces *%1 and releases the original 
> *%1.
>   %3 = load %1
>   %4 = ref_element_addr %3
>   %ptr = load %4
> }
> 
> Redundant load elimination may optimize this to
> 
> sil @test(@inout %1 : $*C) {
>   %2 = load %1
>   apply inout_violating_function // replaces *%1 and releases the original 
> *%1.
>   %4 = ref_element_addr %2
>   %ptr = load %4  // load pointer from freed memory
> }
> 
> What I propose is to add a utility function in Types.h
> 
> inline bool isNotAliasedIndirectParameter(ParameterConvention conv,
>   bool assumeInoutIsNotAliasing)
> 
> and optimizations, which use this function, must decide if it is safe to pass 
> true in assumeInoutIsNotAliasing. This might be the case for high-level 
> optimizations like COW array opts.
> For alias analysis I think we have to go the conservative way.
> 
> John, Joe: any comments?

I agree that we can't make a blanket assumption that inout is noalias. Arnold 
made a similar conclusion last year, so I think we already treat them as 
aliasing. IRGen won't apply the LLVM noalias attribute to inout parameters, for 
instance. It's probably better to target `inout` with specific known-acceptable 
optimizations (load forwarding, writeback elimination, transforming to 
input-result pair, etc.) than generally treating it as noalias.

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

Re: [swift-dev] tips for debugging the swift executable

[Joe Groff via swift-dev]

> On Dec 17, 2015, at 2:57 PM, Rafkind, Jon via swift-dev  
> wrote:
> 
> I use gdb on linux to debug the swift binary. I find that gdb takes about 20 
> seconds just to read the symbols before I can even interact with gdb. I was 
> wondering if anyone knew of a way to decrease the symbol load time, either by 
> some gdb settings or by compiling swift/llvm/clang in such a way as to get a 
> usefully debuggable binary but without so many symbols.
> 
> My swift binary is a massive 1.1gb.
> 
> $ ls -lh swift
> -rwxr-xr-x 1 jon jon 1.1G Dec  8 18:43 swift*
> 
> I built all of llvm/clang/swift in Debug mode.
> 
> (Tangentially related, but using gold instead of ld to link swift is about 
> 2-3x faster)

You might give lldb a shot, if you haven't already. It seems to cope better 
with large binaries, and expr evaluation is more stable IME.

-Joe

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

[swift-dev] Value-result ABI for small trivial inouts

[Joe Groff via swift-dev]

We currently always pass inout parameters indirectly, but it seems to me that 
for inout parameters that are of small trivial types like Int or CGSize, a 
value-result calling convention might always be preferable, and we might want 
to codify that in the stable ABI. Values of these types are likely to be SSAed, 
and the indirect convention forces memory traffic that would otherwise be 
unnecessary. On ARMv7 and ARM64, the argument and return register sets are the 
same, so a value-result convention is likely to be able to compile down to 
in-place operations on those registers, so it's a potential code size win too.

(Value-result is not a clear win for nontrivial types, since it forces a load 
and retain onto the outermost caller that inouts a value in memory, since we 
can't invalidate the memory during the inout call. The extra retain would 
potentially defeat COW optimization. We have primitives like 
`isUniquelyReferenced` that depend on mutable references being in memory too.)

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

Re: [swift-dev] Value-result ABI for small trivial inouts

[Joe Groff via swift-dev]

> On Dec 17, 2015, at 3:43 PM, Greg Parker  wrote:
> 
> 
>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev  
>> wrote:
>> 
>> On ARMv7 and ARM64, the argument and return register sets are the same
> 
> Nit: True on arm64. Not true on armv7; the GPR parameters are r0-r3 but GPR 
> return is r0-r1.

True, I meant that one sequence is a prefix of the other. If you pass the first 
argument in and return it out via {r0, r1} the operations could be done 
in-place.

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

Re: [swift-dev] Value-result ABI for small trivial inouts

[Joe Groff via swift-dev]

> On Dec 17, 2015, at 3:43 PM, John McCall  wrote:
> 
>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev  
>> wrote:
>> We currently always pass inout parameters indirectly, but it seems to me 
>> that for inout parameters that are of small trivial types like Int or 
>> CGSize, a value-result calling convention might always be preferable, and we 
>> might want to codify that in the stable ABI. Values of these types are 
>> likely to be SSAed, and the indirect convention forces memory traffic that 
>> would otherwise be unnecessary. On ARMv7 and ARM64, the argument and return 
>> register sets are the same, so a value-result convention is likely to be 
>> able to compile down to in-place operations on those registers, so it's a 
>> potential code size win too.
>> 
>> (Value-result is not a clear win for nontrivial types, since it forces a 
>> load and retain onto the outermost caller that inouts a value in memory, 
>> since we can't invalidate the memory during the inout call. The extra retain 
>> would potentially defeat COW optimization. We have primitives like 
>> `isUniquelyReferenced` that depend on mutable references being in memory 
>> too.)
> 
> IIRC, the mutation model does try to make stronger promises about updates to 
> stored variables and properties; this would interfere with that.

Maybe. I know we try to make stronger promises about partial object updates, so 
things like swap(&a.x, &a.y) or swap(&a[0], &a[1]) work with stored `x` and `y` 
or addressed subscripts, but we're still pretty cavalier about when the updates 
get published. A capture or reabstraction can implicitly introduce writebacks 
on the callee side even if the caller passed in a property they know to be 
stored.

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

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

[Joe Groff via swift-dev]

> On Dec 19, 2015, at 6:53 PM, Chaitanya Mannem via swift-users 
>  wrote:
> 
> Hi,
> 
> 
> I wanted to know if it is possible to compile swift code for bare metal. I 
> know there is a runtime but does swift depend on it to execute even if I 
> don't use those features?, can I disable them somehow. I was hoping that 
> since you can produce LLVM Bytecode that you can cross compile using the 
> arm-none-eabi toolchain for an embedded use-case 
> (http://www.ti.com/tool/ek-tm4c123gxl) 
> . Please tell me there's hope, I don't 
> want to use C++  :(

The code that emits runtime calls in IRGen is fairly well-factored. One thing 
you might experiment with is adding an `-fstandalone` flag that causes the 
compiler to diagnose any time it has to generate code with a runtime call. If 
you're willing to forgo the standard library and build from LLVM primitives up 
and always use -Ounchecked, you might be able to generate standalone binaries 
without a runtime dependency. You're on your own if you go that road though.

-Joe

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

[swift-dev] swift_retainCount in CoreFoundation

[Joe Groff via swift-dev]

It looks like the corelibs implementation of CoreFoundation references 
swift_retainCount in order to implement CFGetRetainCount. Is getting the retain 
count necessary to CF functionality, or can these functions be removed?

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

Re: [swift-dev] swift_retainCount in CoreFoundation

[Joe Groff via swift-dev]

> On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev  
> wrote:
> 
> It looks like the corelibs implementation of CoreFoundation references 
> swift_retainCount in order to implement CFGetRetainCount. Is getting the 
> retain count necessary to CF functionality, or can these functions be removed?

The only use of CFGetRetainCount in the corelibs that I see appears to be in 
CFMachPort.c, to drop CFMachPorts that are uniquely referenced from the run 
loop. Is that file relevant to Linux Foundation? Is this check necessary?

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

[swift-dev] Combining native and ObjC swift_class_getInstanceExtents entry points

[Joe Groff via swift-dev]

In the runtime currently, there are two entry points for asking for the size of 
a class's instances, one for known-native Swift classes, and one for 
possibly-ObjC classes. It looks like they're only currently used for 
_debugPrecondition checks in ManagedBuffer's initializers to catch 
improperly-sized subclasses in debug builds, so I'm wondering whether saving an 
`isObjC` branch in the known-native case is worth the extra entry point. Any 
concerns with merging them?

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

Re: [swift-dev] swift_retainCount in CoreFoundation

[Joe Groff via swift-dev]

> On Dec 25, 2015, at 9:02 PM, Philippe Hausler  wrote:
> 
> > On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev  > swift.org <https://lists.swift.org/mailman/listinfo/swift-dev>> wrote:
> > 
> > It looks like the corelibs implementation of CoreFoundation references 
> > swift_retainCount in order to implement CFGetRetainCount. Is getting the 
> > retain count necessary to CF functionality, or can these functions be 
> > removed?
> 
> For some reason I was not on this list;
> So in response to your query about CF’s usage of CFGetRetainCount - I think 
> we can safely forbid that function in the swift version since there is no 
> safe way to use it (even CFMachPort is a bit dodgy for it’s usage).
> 
> It might take some surgery but I can probably excise that fairly simply.

That'd be awesome. Thanks Philippe! For CFMachPort's usage, since it's checking 
for a retainCount of 1, maybe we could use swift_isUniquelyReferenced* instead, 
which we do need to reliably support for COW.

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

Re: [swift-dev] swift_retainCount in CoreFoundation

[Joe Groff via swift-dev]

> On Dec 26, 2015, at 12:52 PM, Philippe Hausler  wrote:
> 
> 
>> On Dec 26, 2015, at 12:31 PM, Joe Groff > <mailto:jgr...@apple.com>> wrote:
>> 
>>> 
>>> On Dec 25, 2015, at 9:02 PM, Philippe Hausler >> <mailto:phaus...@apple.com>> wrote:
>>> 
>>> > On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev >> > swift.org <https://lists.swift.org/mailman/listinfo/swift-dev>> wrote:
>>> > 
>>> > It looks like the corelibs implementation of CoreFoundation references 
>>> > swift_retainCount in order to implement CFGetRetainCount. Is getting the 
>>> > retain count necessary to CF functionality, or can these functions be 
>>> > removed?
>>> 
>>> For some reason I was not on this list;
>>> So in response to your query about CF’s usage of CFGetRetainCount - I think 
>>> we can safely forbid that function in the swift version since there is no 
>>> safe way to use it (even CFMachPort is a bit dodgy for it’s usage).
>>> 
>>> It might take some surgery but I can probably excise that fairly simply.
>> 
>> That'd be awesome. Thanks Philippe! For CFMachPort's usage, since it's 
>> checking for a retainCount of 1, maybe we could use 
>> swift_isUniquelyReferenced* instead, which we do need to reliably support 
>> for COW.
>> 
>> -Joe
> 
> Actually the method that was being used there is not even compiled on mac 
> targets, I was able to safely excise the usage and disallow the function in 
> the Swift version of CF. 
> 
> I pushed this:
> https://github.com/apple/swift-corelibs-foundation/commit/d430c06fe417e285c5b120ccbf1d1082807e3b5c
>  
> <https://github.com/apple/swift-corelibs-foundation/commit/d430c06fe417e285c5b120ccbf1d1082807e3b5c>
> 
> Which should no longer swift_retainCount in swift-corelibs-foundation builds 
> anymore.

Nice, thanks again Philippe!

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

Re: [swift-dev] Distinguishing classes from value types/ObjC bridged types?

[Joe Groff via swift-dev]

> On Dec 29, 2015, at 4:50 PM, Austin Zheng via swift-dev  
> wrote:
> 
> Hello,
> 
> First, some background. I'm currently working on refactoring the way mirrors 
> are handled within the Swift standard library (conversion from use of 
> _Reflectable and _MirrorType to CustomReflectable).
> 
> Note that the _MirrorType protocol exposes an 'objectIdentifier' property 
> which is only relevant for class instances. Each type's mirror would have to 
> manually implement this property, with mirrors for non-class types expected 
> to return nil.
> 
> CustomReflectable moves away from each type having a custom 
> _MirrorType-conforming mirror type in favor of using Mirror for everything, 
> which means that certain manually specified properties such as 
> 'objectIdentifier' and 'summary' disappear, and must be replaced by other 
> language features.
> 
> Now, the current way I distinguish between classes and non-class types (for 
> the dump() function) is through the following code (variable names are made 
> up):
> 
> if let thisClassThing = thisThing as? AnyObject {
>   let theIdentifier = ObjectIdentifier(thisClassThing)
>   // do other stuff...
> }
> 
> (In the context of dump(), this is necessary to ensure that dumping an object 
> with a cycle of references doesn't result in infinite recursion.)
> 
> However, where this breaks down is when Foundation is imported. In this case, 
> performing as? or is casts/checks on a bridged Swift type such as String or 
> Array results in the test returning true or the type being bridged to an 
> NS* object type.
> 
> My question is whether or not there exist tools in the stdlib to determine 
> whether an instance is an instance of a class or not, while also being able 
> to distinguish between native Swift bridgeable structs and their NS* 
> equivalents. I have a few ideas I'm exploring but I wanted to run this 
> question by the community first to see if there's anything I'm missing, or if 
> anyone has any good ideas.
> 
> Thanks for your time, and if you have any questions I'd be happy to clarify.

You can ask if `thisThing.dynamicType is AnyObject.Type`, since the metatypes 
of bridgeable types don't themselves bridge.

-Joe

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev  
> wrote:
> 
> I’m seeing an assertion failure when I try to compile the following on Linux:
> 
>   typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
> 
> The assertion failing is:
> 
>assert(getASTContext().LangOpts.EnableObjCInterop ||
>   *repr != MetatypeRepresentation::ObjC);
> 
> in ExistentialMetatypeType::ExistentialMetatypeType(). Commenting it out and 
> the code compiles and works.
> 
> Can someone that understands the compiler suggest the correct fix?

It looks like you're trying to poke at private runtime metadata structures; 
please don't do that. What are you trying to do?

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 10:05 AM, Philippe Hausler  wrote:
> 
> That is the asset in the compiler that is being hit when the code 
> unsafeBitCasts to a c function.
> 
> typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
> let accessor = unsafeBitCast(symbol, TypeMetadataAccessor.self) // <— this 
> causes the compiler to assert there.

Under the ObjC runtime model, C and ObjC APIs represent class metatypes as 
pointers to their ObjC class representation, but that distinction doesn't 
matter in non-ObjC interop. This is easy to fix, but I'll reiterate that type 
metadata accessors are something you almost certainly have no business directly 
interacting with. What are you trying to do?

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

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 2:41 PM, Luke Howard  wrote:
> 
> 
>>> It looks like you're trying to poke at private runtime metadata structures; 
>>> please don't do that. What are you trying to do?
>> 
>> Per our exchange yesterday – implement NSStringFromClass() heuristics for 
>> NSKeyedArchiver
> 
> Sorry I mean NSClassFromString(). I thought indirecting the lookup through 
> the metadata accessor was at least a little bit less bad than accessing it 
> directly. :)

If you're experimenting privately that's OK, but I'd prefer to get the runtime 
functionality in place before committing anything. We already have our hands 
full trying to clean up and stabilize the standard library/runtime interfaces.

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

Re: [swift-dev] Linker script on Linux

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev  
> wrote:
> 
> Per [SR-404], anything that consumed libFoundation could not dynamically cast 
> to a Foundation protocol because the build script was missing the magic 
> swift.ld linker script to advertise the start of the protocol conformances 
> table.

Is it possible that the library is getting linked by clang instead of swiftc? I 
would expect the swiftc driver to pass the linker script down to ld (but maybe 
it's not).

> (There’s also some weird issue where dlsym() seems to return the previous 
> table if it can’t find one, but that’s a separate issue.)

Might be a runtime bug—are we looking up the symbol with RTLD_LOCAL?

-Joe

> 
> The build system is opaque enough that I’m not exactly sure how the linker is 
> driven when building shared libraries, but it would be great if the linker 
> script was added automagically.
> 
> — Luke
> --
> www.lukehoward.com 
> soundcloud.com/lukehoward
> 
> 
> ___
> 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] Where are @_attributes documented?

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 4:58 PM, Ling Wang via swift-dev  
> wrote:
> 
> I want to submit some patches but I’m not sure whether I should apply some 
> @_attributes(like @_transparent and @_semantics) that I see in stdlib to my 
> API because I don’t know their meanings.

If it starts with an underscore, the answer is always "no, unless you're the 
standard library". These attributes are compiler-internal and not intended to 
be used by user code. We reserve the right to change them with reckless abandon.

> Where are they documented?

Some are documented in the compiler's 'doc/' subdirectory in various places.

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

Re: [swift-dev] Compiling SIL with swiftc

[Joe Groff via swift-dev]

> On Dec 31, 2015, at 2:33 AM, Luke Howard via swift-dev  
> wrote:
> 
> Newbie question, is the following supposed to work?
> 
> $ ./swiftc -emit-sil -o lookup.sil lookup.swift
> $ ./swiftc -parse-sil -o lookup lookup.sil
> 
> It fails with a gazillion errors:
> 
> lookup.sil:61:25: error: use of undeclared type 'SomeProtocol'
>   %23 = metatype $@thin SomeProtocol.Protocol
> ^~~~
> lookup.sil:62:3: error: expressions are not allowed at the top level
>   %24 = metatype $@thick SomeProtocol.Protocol// user: %25
>   ^
> lookup.sil:62:17: error: consecutive statements on a line must be separated 
> by ';'
>   %24 = metatype $@thick SomeProtocol.Protocol// user: %25
> ^
> ;
> ...
> 
> almost as if it thinks it’s Swift.

This should work. I think, though, that if you try to compile multiple files 
together, it currently parses them all as .swift files, which might explain the 
failure.

-Joe

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

Re: [swift-dev] Where are @_attributes documented?

[Joe Groff via swift-dev]

> On Dec 30, 2015, at 7:42 PM, Ling Wang  wrote:
> 
> Yes I’m submitting patches to stdlib. Thanks for pointing me to the doc 
> folder.

Even if you're working on the stdlib, I wouldn't worry too much about using any 
internal attributes right away. The performance team usually handles adding 
those where needed.

-Joe

>> On Dec 30, 2015, at 7:35 PM, Joe Groff  wrote:
>> 
>> 
>>> On Dec 30, 2015, at 4:58 PM, Ling Wang via swift-dev  
>>> wrote:
>>> 
>>> I want to submit some patches but I’m not sure whether I should apply some 
>>> @_attributes(like @_transparent and @_semantics) that I see in stdlib to my 
>>> API because I don’t know their meanings.
>> 
>> If it starts with an underscore, the answer is always "no, unless you're the 
>> standard library". These attributes are compiler-internal and not intended 
>> to be used by user code. We reserve the right to change them with reckless 
>> abandon.
>> 
>>> Where are they documented?
>> 
>> Some are documented in the compiler's 'doc/' subdirectory in various places.
>> 
>> -Joe
> 

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

Re: [swift-dev] Radar and bugs.swift.org

[Joe Groff via swift-dev]

> On Dec 31, 2015, at 11:47 AM, Keith Smiley via swift-dev 
>  wrote:
> 
> Would it be worthwhile for the swift team if those of us who have created 
> many swift related radars to copy them over to bugs.swift.org 
> ?

Definitely. If you can spare the extra effort, we'd appreciate cross references 
between the public and Radar bugs on Jira and Radar too.

-Joe

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

Re: [swift-dev] swift_retainCount in CoreFoundation

[Joe Groff via swift-dev]

> On Jan 4, 2016, at 12:10 PM, Tony Parker  wrote:
> 
> Hi Joe,
> 
> I think we can probably elide CFGetRetainCount from the corelibs-foundation. 
> It’s almost always an anti-pattern to check a retain count anyway (as I’m 
> sure you’re aware since you’re trying to kill the swift version of it).
> 
> File a bug for us and we’ll get on it.

I think Philippe already took care of this. Thanks for following up, though, 
Tony!

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

Re: [swift-dev] C Macros and Variadic functions

[Joe Groff via swift-dev]

> On Jan 5, 2016, at 1:57 PM, Kate Stone via swift-dev  
> wrote:
> 
>> On Jan 5, 2016, at 12:32 PM, Ryan Lovelett via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Just to be clear though the intent of my question was not to quibble
>> with compiler error messages. My real question is how are we meant to do
>> systems programming with Swift on Linux if we cannot call ioctl?
> 
> In the absence of an automatic mechanism for importing the definition of 
> variadic functions you can still define your own prototypes and bind them to 
> the system implementation.  For example, this declaration:
> 
> @_silgen_name("ioctl") func ioctl(fildes: CInt, request: UInt64, result: 
> UnsafePointer) -> Int
> 
> … gives you a non-variadic interface to ioctl that you can use for 
> invocations that conform to this specific convention.  You can define as many 
> overloads as you wish, and so long as you’re cautious about which one you’re 
> using for a given request you should be able to make progress.
> 
> The same basic strategy can be applied to any variadic functional interfaces. 
>  Ideally you’d want to hide this implementation detail behind a more 
> Swift-friendly API where the request type is implied to create a more 
> type-safe interface.

Don't do this. User code never has any business using underscored attributes. 
@_silgen_name produces an external reference to a Swift function, with Swift's 
calling convention.  It cannot be safely used to refer to C functions, 
especially not variadic ones, since the convention for variadics in C is also 
different from non-variadic C functions. For variadic functions, you should 
write non-variadic wrappers in C (which can be static inline, to avoid wrapping 
overhead in production builds) and import them as Clang modules. See how open 
and fcntl are exported by the Darwin and Glibc overlays for an example.

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

Re: [swift-dev] Understanding runtime entry points

[Joe Groff via swift-dev]

> On Jan 1, 2016, at 10:58 PM, Austin Zheng via swift-dev  
> wrote:
> 
> Hello,
> 
> I'm trying to better understand how calls are made between the Swift standard 
> library code and the runtime entry points. I've read through most of the 
> documentation in the repo but still have some questions.

The particular functions in question aren't so much runtime entry points as 
Swift methods that happen to be written in C++, in a way that makes them 
incidentally ABI-compatible with Swift methods. 

> More specifically, here's an example: the '_EnumMirror' struct below 
> represents a mirror reflecting a value whose type is an enum. 
> 
> --
> 
> struct _EnumMirror : _MirrorType {
>  let data: _MagicMirrorData
>  var value: Any { return data.value }
>  var valueType: Any.Type { return data.valueType }
>  // ... more stuff
> 
>  var caseName: UnsafePointer {
>@_silgen_name("swift_EnumMirror_caseName")get
>  }
>  // ... (more stuff)
> }
> 
> --
> 
> The 'caseName' property represents the name of the enum value's case (e.g. 
> "FirstCase" in Foo.FirstCase) as a C string. This property's getter calls 
> into a C++ runtime function named "swift_EnumMirror_caseName", which is 
> reproduced below (from Reflection.mm):
> 
> extern "C"
> const char *swift_EnumMirror_caseName(HeapObject *owner,
>  const OpaqueValue *value,
>  const Metadata *type) {
>  if (!isEnumReflectable(type))
>return nullptr;
> 
>  const auto Enum = static_cast(type);
>  const auto &Description = Enum->Description->Enum;
> 
>  unsigned tag;
>  getEnumMirrorInfo(value, type, &tag, nullptr, nullptr);// effectively, 
> same as "tag = type->vw_getEnumTag(value);"
>  return getFieldName(Description.CaseNames, tag);
> }
> 
> Now, I had a few questions about exactly how this interoperation works, 
> because I'd like to be able to get the name of an enum case using this entry 
> point from a different context (not from within an _EnumMirror property).
> 
> * swift_EnumMirror_caseName takes three arguments, but the Swift call site 
> doesn't seem to specify what gets passed into the function. Is there a 
> convention that is implicitly passing properties on _EnumMirror as arguments 
> into the C++ function when it's being called? I did note that there were 
> other runtime entry points (like "swift_MagicMirrorData_summary") where the 
> number of arguments in the Swift function matched the number of arguments in 
> the C++ function, but in those cases the Swift function was a free function 
> and not a method.

Swift structs are (currently) passed by passing each stored property 
individually. _EnumMirror is defined as a struct with owner/value/type fields, 
and the 'self' parameter to its methods gets broken down this way.

> * What I really want to do is to get the tag of an enum. I wrote a different 
> entry point that omits the unused "owner" property and simply calls 
> swift_EnumMirror_caseName with nullptr as the first argument. This other C++ 
> function takes 'value' (an OpaqueValue*) and 'type' (a Metadata*). I've 
> surmised that 'type' should be the Swift metatype of the enum instance (e.g. 
> myEnum.dynamicType), and I do get the case names table. However, if I pass in 
> the enum instance itself as 'value', my tag is always retrieved as 0. I 
> noticed that there's some sort of indirection in the form of "vw_getEnumTag", 
> which goes through something called the "value witness". Is there somewhere I 
> can read up about the value witness concept? I assume the reason the 
> 'original' code worked was because it was passing in a different object as 
> 'value', maybe one that could serve as a value witness for the reflected-upon 
> instance's type.

'value' is a pointer to the value in memory, not the value itself. Are you 
passing the enum's literal representation by value instead of passing a pointer 
to it?

-Joe

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

Re: [swift-dev] Understanding runtime entry points

[Joe Groff via swift-dev]

> On Jan 6, 2016, at 12:46 PM, Austin Zheng  wrote:
> 
> Thanks Joe, this is incredibly helpful, especially the note about how enums 
> are passed in 'piecewise'.

To clarify, what you're seeing in EnumMirror is not the enum itself, but the 
_EnumMirror structure, which is itself designed to be bitwise-compatible with a 
generic (owner, type, pointer to value) triple that can reference an arbitrary 
value in memory while keeping it alive if reference-counted. The 'value' field 
in this structure is always a pointer to the value of the 'type' type in 
memory. 

> 
> re. your question: I was indeed calling the C++ function from Swift and 
> directly passing in the enum (in pseudo-Swift):
> let myEnum : SomeEnumType = ...
> cplusplusFunction(value: myEnum, type: SomeEnumType.self)  // incorrect
> 
> How would I pass a pointer to the enum's value from Swift? I don't think 
> Swift exposes any mechanism to get the memory address of a Swift object. 
> Perhaps I should create an UnsafeMutablePointer, set its memory 
> to (a copy of) the enum value, and pass that pointer object in instead?

If all you want is the enum tag, you could implement a more straightforward 
interface. In Swift:

@_silgen_name("_swift_stdlib_getEnumTag")
func _getEnumTag(value: T) -> Int32

In C++:

/// Return the tag number for an enum, or crash if the value is not of enum 
type.
int32_t _swift_stdlib_getEnumTag(OpaqueValue *value, const Metadata *type) {
  assert(type->getKind() == MetadataKind::Enum);
  auto tag = type->vw_getEnumTag(value);
  type->vw_destroy(value);
  return tag;
}

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

Re: [swift-dev] [Discussion] New refcount representation

[Joe Groff via swift-dev]

This sounds awesome. Should we still consider using a non-pointer isa 
representation on 64 bit platforms? 16 bytes per object header is still kinda 
big. If we laid out the np-isa bits so that the "side allocation" bit were the 
MSB, and the strong refcount immediately below it, we could pull the same trick 
letting the strong refcount overflow into the side allocation bit. Drawbacks 
would be that we'd need to go back to a global sidetable to reference the 
overflow allocation, and that on Apple platforms, we'd need to follow whatever 
non-pointer-isa layout the Objective-C runtime uses, and the exact layout of 
the bits would have to remain runtime-private and thus not inlineable. If we're 
running on the assumption that side allocations are rarely needed, then paying 
for the lock in the rare case might be worth a potentially substantial memory 
savings. On platforms where we don't need ObjC interop, maybe we could avoid 
the need for the sidetable with non-pointer-isa by cloning the heap object's 
vtable into the side allocation and changing the masked isa pointer to refer to 
the side allocation. That would make the side allocation larger, and would make 
operations that extract the type metadata from a class for generics a bit more 
expensive, but would let vtable lookups remain fast.

-Joe

> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev  
> wrote:
> 
> I am considering a new representation for Swift refcounts and other 
> per-object data. This is an outline of the scheme. Comments and suggestions 
> welcome.
> 
> Today, each object stores 64-bits of refcounts and flags after the isa field.
> 
> In this new system, each object would store a pointer-size field after the 
> isa field. This field would have two cases: it could store refcounts and 
> flags, or it could store a pointer to a side allocation that would store 
> refcounts and flags and additional per-object data.
> 
> Advantages:
> * Saves 4 bytes per object on 32-bit for most objects.
> * Improves refcount overflow and underflow detection.
> * Might allow an inlineable retain/release fast path in the future.
> * Allows a new weak reference implementation that doesn't need to keep entire 
> dead objects alive.
> * Allows inexpensive per-object storage for future features like associated 
> references or class extensions with instance variables.
> 
> Disadvantages:
> * Basic RR operations might be slower on x86_64. This needs to be measured. 
> ARM architectures are probably unchanged.
> 
> 
> 
> The MSB bit would distinguish between the fastest-path in-object 
> retain/release and everything else. Objects that use some other RR path would 
> have that bit set. This would include objects whose refcount is stored in the 
> side allocation and objects whose refcount does not change because they are 
> allocated on the stack or in read-only memory.
> 
> The MSB bit also becomes set if you increment or decrement a retain count too 
> far. That means we can implement the RR fast path with a single conditional 
> branch after the increment or decrement:
> 
> retain:
>intptr_t oldRC = obj->rc
>newRC = oldRC + RC_ONE// sets MSB on overflow; MSB already set for 
> other special cases
>if (newRC >= 0) {
>CAS(obj->rc = oldRC => newRC)
>} else {
>call slow path
>// out-of-object refcount (MSB bits 0b10x)
>// or refcount has overflowed (MSB bits 0b111)
>// or refcount is constant(MSB bits 0b110)
>}
> 
> release:
>intptr_t oldRC = obj->rc
>newRC = oldRC - RC_ONE// sets MSB on overflow; MSB already set for 
> other special cases
>if (newRC >= 0) {
>CAS(obj->rc = oldRC => newRC)
>} else {
>call slow path
>// dealloc (MSB bits 0b111)
>// or out-of-object refcount   (MSB bits 0b10x)
>// or refcount has underflowed (MSB bits 0b111 and deallocating bit 
> already set)
>// or refcount is constant (MSB bits 0b110)
>}
> 
> There are some fussy bit representation details here to make sure that a 
> pre-existing MSB=1 does not become 0 after an increment or decrement. 
> 
> (In the more distant future this fast path could be inlineable while 
> preserving ABI flexibility: if worse comes to worse we can set the MSB all 
> the time and force inliners to fall back to the slow path runtime function. 
> We don't want to do this yet though.)
> 
> The side allocation could be used for:
> * New weak reference implementation that doesn't need to keep entire dead 
> objects alive.
> * Associated references or class extensions with instance variables
> * Full-size strong refcount and unowned refcount on 32-bit architectures
> * Future concurrency data or debugging instrumentation data
> 
> The Objective-C runtime uses a side table for similar purposes. It has the 
> disadvantage that retrieving an object's side allocation requires use of a 
> global hash table, which is slow and requires locking. 

Re: [swift-dev] [Discussion] New refcount representation

[Joe Groff via swift-dev]

> On Mar 16, 2016, at 4:08 PM, Greg Parker  wrote:
> 
> 
>> On Mar 16, 2016, at 9:25 AM, Joe Groff  wrote:
>> 
>> This sounds awesome. Should we still consider using a non-pointer isa 
>> representation on 64 bit platforms? 16 bytes per object header is still 
>> kinda big. If we laid out the np-isa bits so that the "side allocation" bit 
>> were the MSB, and the strong refcount immediately below it, we could pull 
>> the same trick letting the strong refcount overflow into the side allocation 
>> bit. Drawbacks would be that we'd need to go back to a global sidetable to 
>> reference the overflow allocation, and that on Apple platforms, we'd need to 
>> follow whatever non-pointer-isa layout the Objective-C runtime uses, and the 
>> exact layout of the bits would have to remain runtime-private and thus not 
>> inlineable. If we're running on the assumption that side allocations are 
>> rarely needed, then paying for the lock in the rare case might be worth a 
>> potentially substantial memory savings.
> 
> Packing everything into a single 64-bit field is tricky but might work.
> 
> I think OS X and Linux x86_64 is the worst case currently, with 3 low bits 
> and 17 high bits available. Here's what libobjc stores in its isa field on 
> x86_64:
> 
> 1 bit   is nonpointer
> 1 bit   has associated references
> 1 bit   has destructor
> 44 bits  class pointer
> 6 bits  magic for tools
> 1 bit   is weakly referenced
> 1 bit   is deallocating
> 1 bit   has additional refcount in side allocation
> 8 bits  refcount
> 
> Some of those bits can be combined or reduced:
> 
> is-nonpointer is unnecessary as long as at least one of the bits outside the 
> class pointer is set. There may be binary compatibility problems here, 
> though. (Do existing Swift apps check that bit directly?)
> 
> has-associated-references and is-weakly-referenced and 
> has-additional-refcount could be folded into a single has-sidetable bit. 
> 
> magic is needed for tools like `leaks` to distinguish real objects from 
> non-object allocations. If the isa field is not a simple pointer then there 
> are otherwise too many false objects for `leaks` to be usable. 6 bits is 
> pushing the bare minimum here, but we might be able to trim this by making 
> the tools smarter and more invasive. (For example: if the has-sidetable bit 
> is set then look for a side allocation pointing back to the object. If you 
> don't find one then it's not a real object.)  Being able to run `leaks` and 
> `heap` on an unprepared process is an important capability, and I don't think 
> we can afford to cripple it.
> 
> refcount can always be trimmed. I don't know what the shape of the "objects 
> whose refcount is ever greater than X" curve looks like.
> 
> 
> Given the above, we can claw back enough bits for things like a small unowned 
> refcount and is-pinned or is-nonstructurally-mutating bits. 
> 
> My biggest concern is future Swift concurrency support. I suspect we will 
> want storage for a thread ID or a lock. Maybe those would be uncommon enough 
> that they can live in a side allocation. Will we want a thread ID in every 
> thread-local object in production code so we can assert that it has not 
> incorrectly escaped, or can we leave things like that for debug builds only?
> 
> 
> One scheme that I want to investigate for ObjC's use is to allocate a flat 
> array of side allocations, and store an index into that array in the isa 
> field's extra bits. Depending on architecture that allows between 256K and 
> 64M objects with side allocations before falling back to a global table. If 
> that works well enough then packing everything into a single pointer-size 
> field becomes more plausible.
> 
> 
> Joe, did you measure the cost of a mask operation at every Swift virtual 
> call? I can't remember.

Yeah. The effect of the mask operation was unmeasurable on the Macbook Pro and 
iPhone 5s I was testing on. Masking using a resilient mask value loaded from a 
dylib did have a noticeable impact on an Apple Watch, though.

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

Re: [swift-dev] Returning more than two scalars from C code

[Joe Groff via swift-dev]

> On Mar 22, 2016, at 5:57 AM, Bryan Chan via swift-dev  
> wrote:
> 
> I tried to google for an answer but couldn't find anything. What is the 
> correct way to do the following on Linux?
> 
> @_silgen_name("foo")
> func foo(theInt: UInt)
> -> (a: UInt, b: UInt, c: UInt)
> 
> var (d, e, f) = foo(aNum)
> 
> Where foo is:
> 
> typedef struct {
> long a;
> long b;
> long c;
> } Tuple;
> 
> extern "C" {
> Tuple foo(int i) {
> return Tuple{ i, i, i };
> }
> }
> 
> Currently, the call to foo crashes because foo wants to return the tuple 
> indirectly, but the Swift call expects the three scalar return values in 
> registers. This example is a generalization of runtime functions such as 
> swift_class_getInstanceExtents, which happens to work because it only returns 
> two scalars in RAX and RDX, which is supported by Clang. But my tests show 
> that three-scalar tuples/structs will cause problems. On architectures where 
> Clang only supports one scalar return value, the problem is worse.
> 
> Am I doing something wrong or is there already a way to deal with this (e.g. 
> annotation in Swift code to make it obey C ABI, or vice versa)?
> 

Don't use @_silgen_name. If you want to use a C API from Swift, define a Clang 
module for its headers, and import the module. See 
http://clang.llvm.org/docs/Modules.html for documentation on Clang module maps.

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

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

[Joe Groff via swift-dev]

> On Mar 22, 2016, at 9:55 AM, Ryan Lovelett  wrote:
> 
> On Mon, Mar 14, 2016, at 06:42 PM, Dmitri Gribenko wrote:
>> On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett
>>  wrote:
>>> On Tue, Mar 1, 2016, at 12:16 AM, Dmitri Gribenko wrote:
 IIRC there is no issue in the bug tracker, please feel free to file one!
 
 Also, if you are familiar with binutils internals, it might be helpful
 to bisect the linker.
>>> 
>>> I'm finally getting around to bisecting binutils. I'm making some
>>> progress but I'm getting hung up on one thing. The build script keeps
>>> finding the "regular" linker at `/usr/bin/ld` instead of mine
>>> `/tmp/binutils/2.25/usr/local/bin/ld`.
>>> 
>>> I tried to update the PATH environment variable such that mine is before
>>> `/usr/bin` but that doesn't seem to work. Is there an argument to send
>>> that can force mine?
>> 
>> I'm afraid '/usr/bin/ld' is hardcoded in clang.  A few days ago Clang
>> added a command-line option to override that:
>> 
>> commit 635bc7fefc12cc1333ba6ec77e563b7c8af01265
>> Author: Peter Zotov 
>> Date:   Wed Mar 9 05:18:16 2016 +
>> 
>>Accept absolute paths in the -fuse-ld option.
>> 
>>This patch extends the -fuse-ld option to accept a full path to an
>> executable
>>and use it verbatim to invoke the linker. There are generally two
>>reasons
>>to desire this.
>> 
>>The first reason relates to the sad truth is that Clang is
>>retargetable,
>>Binutils are not.
>> 
>>While any Clang from a binary distribution is sufficient to compile
>>code
>>for a wide range of architectures and prefixed BFD linkers (e.g.
>>installed as /usr/bin/arm-none-linux-gnueabi-ld) as well as
>>cross-compiled
>>libc's (for non-bare-metal targets) are widely available, including
>>on all
>>Debian derivatives, it is impossible to use them together because
>>the -fuse-ld= option allows to specify neither a linker prefix nor
>>a full path to one.
>> 
>>The second reason is linker development, both when porting existing
>>linkers
>>to new architectures and when working on a new linker such as LLD.
>> 
>>Differential Revision: http://reviews.llvm.org/D17952
>> 
>>git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262996
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>> 
>> Dmitri
> 
> Phew. Well I finally got everything ready to where I could bisect
> binutils. I won't bore with the details of what it took to actually be
> able to bisect binutils (unless someone actually wants to know).
> 
> I bisected from 71090e7a9dde8d28ff5c4b44d6d83e270d1088e4 to
> 2bd25930221dea4bf33c13a89c111514491440e2. 2bd259 was good and 71090 was
> bad.
> 
> ca3fe95e469b9daec153caa2c90665f5daaec2b5 is the first bad commit
> commit ca3fe95e469b9daec153caa2c90665f5daaec2b5
> Author: H.J. Lu mailto:hjl.to...@gmail.com>>
> Date:   Thu Mar 5 06:34:39 2015 -0800
> 
>Add extern_protected_data and set it for x86
> 
>With copy relocation, address of protected data defined in the
>shared
>library may be external.  This patch adds extern_protected_data and
>changes _bfd_elf_symbol_refs_local_p to return false for protected
>data
>if extern_protected_data is true.
> 
>bfd/
> 
>   PR ld/pr15228
>   PR ld/pr17709
>   * elf-bfd.h (elf_backend_data): Add extern_protected_data.
>   * elf32-i386.c (elf_backend_extern_protected_data): New.
>   Defined to 1.
>   * elf64-x86-64.c (elf_backend_extern_protected_data): Likewise.
>   * elflink.c (_bfd_elf_adjust_dynamic_copy): Don't error on
>   copy relocs against protected symbols if extern_protected_data
>   is true.
>   (_bfd_elf_symbol_refs_local_p): Don't return true on protected
>   non-function symbols if extern_protected_data is true.
>   * elfxx-target.h (elf_backend_extern_protected_data): New.
>   Default to 0.
>   (elfNN_bed): Initialize extern_protected_data with
>   elf_backend_extern_protected_data.
> 
>ld/testsuite/
> 
>   PR ld/pr15228
>   PR ld/pr17709
>   * ld-i386/i386.exp (i386tests): Add a test for PR ld/17709.
>   * ld-i386/pr17709-nacl.rd: New file.
>   * ld-i386/pr17709.rd: Likewise.
>   * ld-i386/pr17709a.s: Likewise.
>   * ld-i386/pr17709b.s: Likewise.
>   * ld-i386/protected3.d: Updated.
>   * ld-i386/protected3.s: Likewise.
>   * ld-x86-64/pr17709-nacl.rd: New file.
>   * ld-x86-64/pr17709.rd: Likewise.
>   * ld-x86-64/pr17709a.s: Likewise.
>   * ld-x86-64/pr17709b.s: Likewise.
>   * ld-x86-64/protected3.d: Updated.
>   * ld-x86-64/protected3.s: Likewise.
>   * ld-x86-64/x86-64.exp (x86_64tests): Add a test for PR
>   ld/17709.
> 
> :04 04 7fc861c288f9bed44c6444d1b04e2f6e688aeeaf
> fca3f6ce979e7c00ed44c04f506880015235806d M  bfd
> :04 04 a5e358abb99b2b4089765f16904f9ebc496c0f12
> 7ccba1e77448a0155e56e8155073b40804b00daa M  ld
> 
> I'd like to write this up as an issue, i

Re: [swift-dev] Returning more than two scalars from C code

[Joe Groff via swift-dev]

> On Mar 22, 2016, at 11:30 AM, Bryan Chan  wrote:
> 
> jgr...@apple.com wrote on 2016-03-22 12:05:06 PM:
> 
> > On Mar 22, 2016, at 5:57 AM, Bryan Chan via swift-dev  > wrote:
> >
> > > I tried to google for an answer but couldn't find anything. What is
> > > the correct way to do the following on Linux?
> > >
> > > @_silgen_name("foo")
> > > func foo(theInt: UInt)
> > > -> (a: UInt, b: UInt, c: UInt)
> > >
> > > var (d, e, f) = foo(aNum)
> > >
> [snip]
> > >
> > > Currently, the call to foo crashes because foo wants to return the
> > > tuple indirectly, but the Swift call expects the three scalar return
> > > values in registers. This example is a generalization of runtime
> > > functions such as swift_class_getInstanceExtents, which happens to
> > > work because it only returns two scalars in RAX and RDX, which is
> > > supported by Clang. But my tests show that three-scalar tuples/
> > > structs will cause problems. On architectures where Clang only
> > > supports one scalar return value, the problem is worse.
> > >
> > > Am I doing something wrong or is there already a way to deal with
> > > this (e.g. annotation in Swift code to make it obey C ABI, or vice versa)?
> >
> > Don't use @_silgen_name. If you want to use a C API from Swift,
> > define a Clang module for its headers, and import the module. See
> > http://clang.llvm.org/docs/Modules.html 
> >  for documentation on Clang
> > module maps.
> 
> Is this the solution for runtime functions like
> swift_class_getInstanceExtents as well?
The runtime functions are hacked in various unsavory ways to give them 
Swift-like calling conventions. Many of them also have important semantics that 
the compiler needs to be aware of, so if they aren't exported as standard 
library API in some way, you really shouldn't interact with them directly. 
(swift_class_getInstanceExtents happens to be OK, but what are you trying to do 
with it?)

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

Re: [swift-dev] large dictionary literal overflows swiftc stack

[Joe Groff via swift-dev]

I'd recommend testing to see if this is improved in Swift 3, if it's practical 
to switch your codebase over. There are some type checker improvements there 
that didn't make it into Swift 2.

-Joe

> On Mar 22, 2016, at 12:13 PM, Rafkind, Jon via swift-dev 
>  wrote:
> 
> Attached is a file from a project called PerfectLib that contains a 
> dictionary literal with 816 entries in it. On my system with exactly 559 
> entries (meaning the last entry is "res") the file can be compiled, but with 
> 560 or more it crashes. It looks like the crash is an infinite loop, I see 
> many entries like this in the stack trace.
> 
> frame #3351: 0x0199e0fe 
> swift`tryTypeVariableBindings(cs=0x7fff82e8, depth=12, 
> typeVar=0x07edba58, bindings=ArrayRef<(anonymous 
> namespace)::PotentialBinding> @ 0x7ffe00f8, 
> solutions=0x7fff7660, 
> allowFreeTypeVariables=Disallow)::PotentialBinding>, 
> llvm::SmallVectorImpl&, 
> swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
>frame #3352: 0x0199cdef 
> swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x7fff82e8,
>  solutions=0x7fff7660, allowFreeTypeVariables=Disallow) + 879 at 
> CSSolver.cpp:1551
>frame #3353: 0x0199b7c0 
> swift`swift::constraints::ConstraintSystem::solveRec(this=0x7fff82e8, 
> solutions=0x7fff7660, allowFreeTypeVariables=Disallow) + 608 at 
> CSSolver.cpp:1256
>frame #3354: 0x0199e0fe 
> swift`tryTypeVariableBindings(cs=0x7fff82e8, depth=11, 
> typeVar=0x07eca470, bindings=ArrayRef<(anonymous 
> namespace)::PotentialBinding> @ 0x7ffe1de8, 
> solutions=0x7fff7660, 
> allowFreeTypeVariables=Disallow)::PotentialBinding>, 
> llvm::SmallVectorImpl&, 
> swift::FreeTypeVariableBinding) + 1294 at CSSolver.cpp:1078
>frame #3355: 0x0199cdef 
> swift`swift::constraints::ConstraintSystem::solveSimplified(this=0x7fff82e8,
>  solutions=0x7fff7660, allowFreeTypeVariables=Disallow) + 879 at 
> CSSolver.cpp:1551
>frame #3356: 0x0199b7c0 
> swift`swift::constraints::ConstraintSystem::solveRec(this=0x7fff82e8, 
> solutions=0x7fff7660, allowFreeTypeVariables=Disallow) + 608 at 
> CSSolver.cpp:1256
> 
> The bottom of the stack is
> 
> frame #3391: 0x017d21d9 
> swift`swift::TypeChecker::solveForExpression(this=0x7fff97e0, 
> expr=0x7fff8fe0, dc=0x07ead5c0, convertType=Type @ 
> 0x7fff7518, allowFreeTypeVariables=Disallow, 
> listener=0x7fff8f50, cs=0x7fff82e8, 
> viable=0x7fff7660, options=(Storage = 16)) + 665 at 
> TypeCheckConstraints.cpp:1154
>frame #3392: 0x017d4ae7 
> swift`swift::TypeChecker::typeCheckExpression(this=0x7fff97e0, 
> expr=0x7fff8fe0, dc=0x07ead5c0, convertType=Type @ 
> 0x7fff8e48, convertTypePurpose=CTP_Unused, options=(Storage = 16), 
> listener=0x7fff8f50) + 711 at TypeCheckConstraints.cpp:1304
>frame #3393: 0x017d61f5 
> swift`swift::TypeChecker::typeCheckBinding(this=0x7fff97e0, 
> pattern=0x7fff8fe8, initializer=0x7fff8fe0, 
> DC=0x07ead5c0) + 261 at TypeCheckConstraints.cpp:1624
>frame #3394: 0x017d64cd 
> swift`swift::TypeChecker::typeCheckPatternBinding(this=0x7fff97e0, 
> PBD=0x07ed3fe8, patternNumber=0) + 237 at 
> TypeCheckConstraints.cpp:1674
>frame #3395: 0x01809eb1 
> swift`validatePatternBindingDecl(tc=0x7fff97e0, 
> binding=0x07ed3fe8, entryNumber=0) + 1025 at TypeCheckDecl.cpp:1214
>frame #3396: 0x018126b3 swift`(anonymous 
> namespace)::DeclChecker::visitPatternBindingDecl(this=0x7fff93b0, 
> PBD=0x07ed3fe8) + 83 at TypeCheckDecl.cpp:2842
>frame #3397: 0x018117ac swift`swift::ASTVisitor<(anonymous 
> namespace)::DeclChecker, void, void, void, void, void, 
> void>::visit(this=0x7fff93b0, D=0x07ed3fe8) + 140 at 
> DeclNodes.def:91
>frame #3398: 0x018076f7 swift`(anonymous 
> namespace)::DeclChecker::visit(this=0x7fff93b0, 
> decl=0x07ed3fe8) + 39 at TypeCheckDecl.cpp:2672
>frame #3399: 0x01807650 
> swift`swift::TypeChecker::typeCheckDecl(this=0x7fff97e0, 
> D=0x07ed3fe8, isFirstPass=false) + 160 at TypeCheckDecl.cpp:5561
>frame #3400: 0x018ca5ce swift`(anonymous 
> namespace)::StmtChecker::visitBraceStmt(this=0x7fff9600, 
> BS=0x07ed4038) + 1166 at TypeCheckStmt.cpp:1078
>frame #3401: 0x018c9f0b swift`swift::ASTVisitor<(anonymous 
> namespace)::StmtChecker, void, swift::Stmt*, void, void, void, 
> void>::visit(this=0x7fff9600, S=0x07ed4038) + 91 at 
> StmtNodes.def:43
>frame #3402: 0x018c99fa swift`bool (anonymous 
> namespace)::StmtChecker::typeCheckStmt(this=0x7fff9600,
>  S=0x7fff9668) + 42 at TypeCheckStmt.cpp:3

Re: [swift-dev] Returning more than two scalars from C code

[Joe Groff via swift-dev]

> On Mar 22, 2016, at 12:06 PM, Bryan Chan  wrote:
> 
> jgr...@apple.com wrote on 2016-03-22 02:37:47 PM:
> 
> > The runtime functions are hacked in various unsavory ways to give 
> > them Swift-like calling conventions. Many of them also have 
> > important semantics that the compiler needs to be aware of, so if 
> > they aren't exported as standard library API in some way, you really
> > shouldn't interact with them directly. 
> > (swift_class_getInstanceExtents happens to be OK, but what are you 
> > trying to do with it?)
> 
> I am trying to build Swift on a different architecture (s390x). This
> function was causing crashes due to the ABI mismatch, and I also
> found that the issue is not 100% fixed on x86 either, so I wondered
> if the community has an opinion on the right way to deal with this
> in the runtime, or if the answer is simply "don't do this for
> 3-scalar returns".
> 

Yeah, there's no good way right now to return three scalars from Clang. 
swift_class_getInstanceExtents and a few other runtime entrypoints like 
allocBox and allocError use the `TwoWordPair::Return` hack to use types that 
happen to return in two registers on i386, x86_64, armv7, and arm64. If s390x's 
C ABI doesn't define any such types, you might need to wait for proper support 
for Swift calling conventions in Clang. I believe it's on John McCall's 
near-term todo list to do that.

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

Re: [swift-dev] large dictionary literal overflows swiftc stack

[Joe Groff via swift-dev]

> On Mar 22, 2016, at 1:41 PM, Rafkind, Jon  wrote:
> 
> Ok I will test with swift 3, but just to avoid any confusion I am not a 
> developer on PerfectLib. I was just using that file as a test case for my 
> application that is based on the swiftc code base. My application is designed 
> to consume arbitrary swift 2.2 code. If there is a problem with swift 3 then 
> I suppose it can be fixed, but if swift 3 has no issues then it looks like I 
> have few options for remediation.

Did your code compile previously as is with Swift 2.1? We'd like to at least 
fix any regressions we introduced in 2.2.

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

Re: [swift-dev] long double usage in swift

[Joe Groff via swift-dev]

> On Mar 23, 2016, at 2:25 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hi,
> 
> I was looking at an ABI related issue on Windows.  In trying to construct a 
> test case, it seems that I am unable to import a declaration using a long 
> double into swift.  I was wondering if there is something about long double 
> usage in swift that I am unaware of.
> 
> Inputs/abi.h:
> 
> float fp32_call(void);
> double fp64_call(void);
> long double fp80_call(void);
> 
> Inputs/module.map:
> 
> module abi {
>   header "abi.h"
> }
> 
> test.swift:
> 
> %swift -I Inputs -parse %s
> import abi
> 
> @inline(never)
> func blackhole(t : T) { }
> 
> func test_floating_point() {
> }
> 
> Thanks!

For better or worse, the failure mode for unsupported C declarations in the 
Clang importer is just to discard them. It sounds like we didn't add support 
for long double imports.

-Joe

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

[swift-dev] Requiring Xcode 7.3 to build Swift master for Apple platforms?

[Joe Groff via swift-dev]

Xcode 7.3 included a fix for the Apple linker that's necessary to support some 
of the metadata format changes we're making in Swift 3. I have some workarounds 
in place that I'd like to remove since they suppress linker coalescing of some 
constant strings. Would anyone object to us requiring using Xcode 7.3 to 
develop Swift for OS X and other Apple platforms? If not, we could 
conditionalize the workarounds behind a flag, though that's additional 
complexity and testing surface I'd like to avoid.

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

Re: [swift-dev] Requiring Xcode 7.3 to build Swift master for Apple platforms?

[Joe Groff via swift-dev]

> On Mar 29, 2016, at 11:29 AM, Andrew Hyatt  wrote:
> 
> Agreed. The minimum OS X version for Xcode 7.3 is 10.11.0, which would make 
> El Capitan required to run Swift 3.0.

If Xcode 7.3 requires 10.11, I'd say it's likely that the version of Xcode that 
includes Swift 3 will need to be hosted on 10.11 as well. You can still use the 
tools to build binaries targeting back to Mavericks, though.

> 
> - Andrew Hyatt
> ahyatt...@icloud.com
> 
>> On Mar 29, 2016, at 11:23, David Abraham via swift-dev  
>> wrote:
>> 
>> Would this be a temporary limitation? I'd prefer to see Swift available to 
>> any development environment even on Apple Platforms.

Practically, you're dependent on Apple's tools to build anything for Apple 
platforms already. We don't support any third-party linkers for Darwin.

-Joe

>> It contributes to the message of openness. 
>> 
>> -Dave 
>> 
>> Enviado desde mi iPhone
>> 
>>> El mar 29, 2016, a las 2:02 PM, Joe Groff via swift-dev 
>>>  escribió:
>>> 
>>> Xcode 7.3 included a fix for the Apple linker that's necessary to support 
>>> some of the metadata format changes we're making in Swift 3. I have some 
>>> workarounds in place that I'd like to remove since they suppress linker 
>>> coalescing of some constant strings. Would anyone object to us requiring 
>>> using Xcode 7.3 to develop Swift for OS X and other Apple platforms? If 
>>> not, we could conditionalize the workarounds behind a flag, though that's 
>>> additional complexity and testing surface I'd like to avoid.
>>> 
>>> -Joe
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] ObjC Interoperability under armv7--linux-gnueabi

[Joe Groff via swift-dev]

> On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev  
> wrote:
> 
> Dear colleagues
> Ihave built swiftc, libswiftCore.so and other outputs under 
> armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. 
> I linked the simplest swift-application, which creates the instance of custom 
> ObjC-class and call instance-method of it. If somebody interested, I am ready 
> to provide patches, though I know that it can not be included into upstream. 
> But there is not success yet. When I try to run application under 
> armv7l-linux, I get following error:
> 
> Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass 
> NSArray.  Offset of first instance variable, __magic_refCount, is 4.  
> Last instance variable in superclass, _sortedArrayHint, ends at offset 
> 8.  This probably means that you are subclassing aclass from a library, 
> which has changed in a binary-incompatibleway.
> 
> Could anybody explain it? I think, it is explained by some difference between 
> NSArray-implementation in XCode framework and in my opensource library. Is it 
> true? And in what way I can try to fix it? May be, to modify my 
> NSArray-source, but how?
> Thanks in advance for answer.

The implementation of our ObjC interop makes pretty deep invasive assumptions 
about the Apple ObjC runtime ABI as well as the implementation of classes in 
Cocoa. It probably needs to be rewritten from the ground up to support another 
runtime and Foundation implementation.

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

Re: [swift-dev] ObjC Interoperability under armv7--linux-gnueabi

[Joe Groff via swift-dev]

> On Mar 30, 2016, at 3:27 AM, Iliya Trub  wrote:
> 
> I'd like to add, that I have overcomed "subject"error in very simple path. I 
> indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error 
> disappeared, but the new error appeared:
> 
> main2: dwarf/Gparser.c:456: fetch_proc_info: Assertion
> `c->pi.unwind_info' failed
> 
> Any opinions? I even do not know, from what library Gparser.c is.
> So, sucess story with launch of the simplest application is not reached.

It's highly unlikely that the Gnustep runtime will be able to make any sense of 
the class metadata we emit, or that the assumptions we make about NSObject, 
NSString, etc. are valid for Gnustep's implementations, so you're in undefined 
behavior territory.

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

Re: [swift-dev] isUniquelyReferenced issues

[Joe Groff via swift-dev]

> On Mar 31, 2016, at 3:58 PM, Patrick Pijnappel via swift-dev 
>  wrote:
> 
> In trying to implement a COW type, but I'm running into problems with 
> isUniqueReferenced breaking in even fairly simple cases. For example (with 
> -O) the code below prints "bar: false", commenting out the print in test() 
> makes it print "bar: true", and removing the var parameter var foo: Foo and 
> using var foo = foo instead breaks it again. Am I doing something wrong here?
> 
> class FooStorage { var x: Int = 0 }
> 
> struct Foo { var storage = FooStorage() }
> 
> func bar(var foo: Foo) {
>   print("bar: \(isUniquelyReferencedNonObjC(&foo.storage))")
> }
> 
> func test() {
>   var foo = Foo()
>   print("test: \(isUniquelyReferencedNonObjC(&foo.storage))")
>   bar(foo)
> }
> 
> test()

You're not doing anything wrong, this is just the ARC optimizer at work. `foo` 
inside `test` is dead after the call to `bar`, so ownership is transferred 
directly to `bar`'s parameter.

-Joe

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

Re: [swift-dev] isUniquelyReferenced issues

[Joe Groff via swift-dev]

> On Mar 31, 2016, at 4:21 PM, Joe Groff via swift-dev  
> wrote:
> 
>> 
>> On Mar 31, 2016, at 3:58 PM, Patrick Pijnappel via swift-dev 
>>  wrote:
>> 
>> In trying to implement a COW type, but I'm running into problems with 
>> isUniqueReferenced breaking in even fairly simple cases. For example (with 
>> -O) the code below prints "bar: false", commenting out the print in test() 
>> makes it print "bar: true", and removing the var parameter var foo: Foo and 
>> using var foo = foo instead breaks it again. Am I doing something wrong here?
>> 
>> class FooStorage { var x: Int = 0 }
>> 
>> struct Foo { var storage = FooStorage() }
>> 
>> func bar(var foo: Foo) {
>>  print("bar: \(isUniquelyReferencedNonObjC(&foo.storage))")
>> }
>> 
>> func test() {
>>  var foo = Foo()
>>  print("test: \(isUniquelyReferencedNonObjC(&foo.storage))")
>>  bar(foo)
>> }
>> 
>> test()
> 
> You're not doing anything wrong, this is just the ARC optimizer at work. 
> `foo` inside `test` is dead after the call to `bar`, so ownership is 
> transferred directly to `bar`'s parameter.

If you want to ensure that `foo` remains alive despite this, you can use 
`withExtendedLifetime`:

class FooStorage { var x: Int = 0 }

struct Foo { var storage = FooStorage() }

func bar(var foo: Foo) {
print("bar: \(isUniquelyReferencedNonObjC(&foo.storage))")
}

func test() {
var foo = Foo()
print("test: \(isUniquelyReferencedNonObjC(&foo.storage))")
withExtendedLifetime(foo) {
bar(foo)
}
}

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

Re: [swift-dev] isUniquelyReferenced issues

[Joe Groff via swift-dev]

> On Mar 31, 2016, at 11:49 PM, Patrick Pijnappel  
> wrote:
> 
> The modified version doesn't seem to change any of the results (on -O or 
> -Onone). Note that the problem is that it's not uniquely referenced inside 
> bar where it actually should be – that would mean that ownership is currently 
> not directly transferred right?

You're right, I'm sorry, I misread your original comment. If the ARC optimizer 
didn't transfer ownership, then it is correct for `isUniquelyReferenced` to be 
false inside `bar`, since the `foo` inside of `test` and the `foo` parameter to 
`bar` are semantically independent values. If this weren't the case, then `bar` 
could modify a COW value type and have its changes be seen back in `test`'s 
copy.

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On Apr 6, 2016, at 10:21 AM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hi,
> 
> I was playing around with the idea of swift and Windows since there are some 
> interesting differences between COFF/PE and (ELF and MachO).
> 
> PE/COFF does not directly address symbols in external modules 
> (DSOs/dylibs/DLLs).  Instead, there is an indirect addressing model (thunks 
> in Windows parlance).  Fortunately, LLVM has a nice way to model this: 
> GlobalValues have an associated "DLLStorageClass" which indicates whether 
> something is "imported" (provided by an external module), "exported" 
> (provided to external modules), or "default" (everything else).
> 
> Adjusting the IRGen to correctly annotate this part of the semantics should 
> get us part of the way to supporting swift on PE/COFF.
> 
> The thing to consider with this is that the DLL storage class is dependent on 
> how the module(s) are being built.  For example, something may change from 
> the exported storage to default if being built into a static library rather 
> than a shared object and is not meant to be re-exported.
> 
> Part of this information really needs to be threaded from the build system so 
> that we know whether a given SIL module is external or internal.
> 
> Given that this would potentially effect ABI stability, it seems like this is 
> a good time to tackle it so that we can push this into the resilience work 
> that is being done for swift 3.
> 
> I would appreciate any pointers and suggestions as to how to best go about 
> handling this.

As Jordan noted, we probably want to thread this information through for ELF 
and Mach-O builds too, for a couple of reasons. One, if you're building a 
static library as opposed to a .so or .dylib, it's not desirable to reexport 
that static library's API by default through any executables or dynamic 
libraries that use it. We currently get this wrong; if the compiler knew it was 
building for a static library, it could give public symbols in the .a 'hidden' 
visibility so that they do the right thing when linked into dylibs. Second, 
ELF's default visibility is problematic for Swift, since it allows 
default-visibility symbols to be interposed at load time by other dynamic 
libraries. This imposes a performance penalty on shared libraries accessing 
their own data, interferes with some of the load-time optimizations we do with 
metadata that assume we can hardcode relative references within a linkage unit, 
and is flat-out dangerous in the face of interprocedural optimization. For 
these reasons, we export symbols with "protected" visibility when we're 
emitting them as part of the current dylib, but import external public symbols 
with default visibility. Since we already need to track this distinction, it 
should be possible to approximate the right thing for Windows by using 
dllexport where we set protected visibility on ELF, or dllimport otherwise.

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

Re: [swift-dev] A type-checking performance case study

[Joe Groff via swift-dev]

> On Apr 8, 2016, at 11:47 AM, John McCall via swift-dev  
> wrote:
> 
> One very drastic solution to this problem would be to eliminate non-labelled 
> overloads.  (A perhaps more-reasonable way to describe this is to say that 
> argument labels are a part of the name, and therefore two declarations with 
> different labels are not overloads.)  That is, given the syntactic form of an 
> expression, we would always be able to find a single function that it could 
> invoke.  The current argument-labelling design of the language does make this 
> more palatable than it was in earlier iterations.  However, I don't think 
> it's palatable enough: this change would be very limiting, and in particular 
> I think we are very unlikely to accept it for operators or single-argument 
> initializers.

Independent of eliminating overloads, our model has been strongly trending 
toward "labels are part of the name". It seems like a bug to me at this point 
that we consider declarations with different argument labels to be overloads in 
the type checker. Now that we've banned tuple splatting, we should be able to 
enforce argument label matching much earlier in the type-checker pipeline, 
which should prune the overload set a lot for initializers and many Cocoa 
naming conventions.

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

Re: [swift-dev] Help needed: SE-0035 design detail

[Joe Groff via swift-dev]

> On Apr 10, 2016, at 12:46 PM, Daniel Duan via swift-dev  
> wrote:
> 
> Hi all,
> 
> I'm in the process of implementing SE-0035, which limits capturing inout
> parameter to @noescape contexts. The proposal is clear on capture behavior for
> the following:
> 
> 1. closure literals
> 2. nested function passed as arguments.
> 
> But I'm not sure what to do with this case, in which 'x' escapes.
> 
> func captureAndEscape(inout x: Int) -> () -> Void { func foo()
> { _ = x } return foo }
> 
> The most obvious answer is it should be considered with the same rule as
> a closure literal, but a nested function can not have @noescape in its type
> (for now anyways).
> 
> So, should this be legal, then? If not, where/how should the error be? 

Ideally IMO, we would consider a reference to a local function to be 
`@noescape` or not based on how the reference is used, rather than the type of 
the function declaration itself:

func escapes(_: () -> ())
func noescapes(_: @noescape () -> ())

func foo(inout x: Int) -> () -> () {
  func local() { _ = x }

  local() // full application doesn't form a closure, ref is @noescape here

  noescapes(local) // parameter is noescape, so ref is noescape

  escapes(local) // parameter is escapable, so ref is escapable

  var x = local // assigning to var forms a closure, so ref is escapabale

  return local // returning forms a closure, so ref is escapable
}

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

Re: [swift-dev] Help needed: SE-0035 design detail

[Joe Groff via swift-dev]

> On Apr 11, 2016, at 1:28 PM, Daniel Duan via swift-dev  
> wrote:
> 
>> Joe Groff via swift-dev  swift.org> writes:
>> 
>>  return local // returning forms a closure, so ref is escapable
> 
> My plan was to check all return statements with FuncDecl as results, if
> any of them has inout captures, complain.
> 
> But this diagnosis is too coarse. A function can capture from any level of
> outer scope, so sometimes it's safe to let a inout escape, as long as the
> reference is still inside the scope it's captured from. Example:
> 
> func a(inout x: Int) -> () -> Void {
>func b() -> () -> Void {
>func c() {
>_ = x
>}
>return c // is this safe? We'll see…
>}
> 
>let f = b() // 'x' captured by f hasn't *really* escaped.
> 
>return f // now we have a problem
> }
> 
> It's unclear whether the statement 'return c' is problematic.
> 
> So there are two paths:
> 
> 1. make *any* escaping inout capture an error
> 2. track down original scope of each inout capture, compare it with the return
>   statement.
> 
> At the moment I haven't looked into how feasible 2 is.

A local analysis is fine, and more predictable anyways. We already impose these 
constraints on @noescape parameters. If the local function reference appears as 
part of a function application or as a noescape argument, then treat the 
reference as noescape, otherwise consider it to escape.

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

Re: [swift-dev] A type-checking performance case study

[Joe Groff via swift-dev]

> On Apr 11, 2016, at 8:40 AM, John McCall  wrote:
> 
>> On Apr 11, 2016, at 8:35 AM, Joe Groff  wrote:
>>> On Apr 8, 2016, at 11:47 AM, John McCall via swift-dev 
>>>  wrote:
>>> 
>>> One very drastic solution to this problem would be to eliminate 
>>> non-labelled overloads.  (A perhaps more-reasonable way to describe this is 
>>> to say that argument labels are a part of the name, and therefore two 
>>> declarations with different labels are not overloads.)  That is, given the 
>>> syntactic form of an expression, we would always be able to find a single 
>>> function that it could invoke.  The current argument-labelling design of 
>>> the language does make this more palatable than it was in earlier 
>>> iterations.  However, I don't think it's palatable enough: this change 
>>> would be very limiting, and in particular I think we are very unlikely to 
>>> accept it for operators or single-argument initializers.
>> 
>> Independent of eliminating overloads, our model has been strongly trending 
>> toward "labels are part of the name". It seems like a bug to me at this 
>> point that we consider declarations with different argument labels to be 
>> overloads in the type checker. Now that we've banned tuple splatting, we 
>> should be able to enforce argument label matching much earlier in the 
>> type-checker pipeline, which should prune the overload set a lot for 
>> initializers and many Cocoa naming conventions.
> 
> I completely agree, and the type-checker does now do this.

Nice. FWIW, your overload-hiding approach makes sense to me.

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool  
> wrote:
> On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool  
> wrote:
> Hi,
> 
> I was playing around with the idea of swift and Windows since there are some 
> interesting differences between COFF/PE and (ELF and MachO).
> 
> PE/COFF does not directly address symbols in external modules 
> (DSOs/dylibs/DLLs).  Instead, there is an indirect addressing model (thunks 
> in Windows parlance).  Fortunately, LLVM has a nice way to model this: 
> GlobalValues have an associated "DLLStorageClass" which indicates whether 
> something is "imported" (provided by an external module), "exported" 
> (provided to external modules), or "default" (everything else).
> 
> Adjusting the IRGen to correctly annotate this part of the semantics should 
> get us part of the way to supporting swift on PE/COFF.
> 
> The thing to consider with this is that the DLL storage class is dependent on 
> how the module(s) are being built.  For example, something may change from 
> the exported storage to default if being built into a static library rather 
> than a shared object and is not meant to be re-exported.
> 
> Part of this information really needs to be threaded from the build system so 
> that we know whether a given SIL module is external or internal.
> 
> To the DLL Storage semantics support, Ive taken a quick first stab at it.  
> Ive pushed the changes to 
> https://github.com/compnerd/apple-swift/tree/dllstorage and created a Pull 
> Request at https://github.com/apple/swift/pull/2080 .
> 
> However, as I expected, this is going to cause problems for building some of 
> the core libraries.  In particular, there are mismatches between what gets 
> compiled and is desired.  The swiftStubs and swiftRuntime are statically 
> compiled and then merged into swiftCore.  There is also the concern of the 
> the support modules (e.g. Platform).  If there are stubs that are being used 
> (e.g. via _silgen_name) then there are issues with calculating the correct 
> DLL storage for the associated global values.
> 
> Playing around with this, I was trying to special case the building of the 
> standard library (as the runtime will be statically linked into it, the 
> symbols that it is expecting to be externally available are actually private 
> linkage.  Not hacking up the compiler like this causes issues since there are 
> inverse dependencies (swiftCore gets dllimport interfaces from swiftRuntime, 
> which has dependencies on swiftCore).  The crux of the problem is that we do 
> not have a way to represent that in swift.
> 
> The easiest answer that seems to come to mind is to actually introduce an 
> attribute to indicate that an interface is part of a specific module and 
> assume that everything else is locally defined.  This would also potentially 
> allow us to handle things like @inline(always) @transparent interfaces which 
> get imported to ensure that a static inline function is given local 
> visibility rather than a DLL Import storage.
> 
> Unfortunately, I believe that currently Im stuck as I do not have a good way 
> to determine what type of dll storage class a symbol should be given (since 
> currently, theres no way to determine if we will have a symbol available 
> locally or not when actually linking).
>  
> It seems to me, at least initially, that we need a way to treat SwiftModule 
> as a container (a la llvm::Module) and indicate which of the TopLevelDecls 
> are meant to be a single "module" (DSO, DLL, whatever you want to call it) so 
> that we can properly track the DLL storage associated with them.  Am I 
> confusing something there?
> 
> Is there a preference on a means to handle this?

The runtime is linked as part of the standard library, and its ABI interface 
should be exported from libswiftCore.dylib/so/dll like the standard library's. 
We should already mark up the ABI entry points with the SWIFT_RUNTIME_EXPORT 
and SWIFT_RUNTIME_STDLIB_INTERFACE macros. Is it not sufficient to expand these 
macros to __dllexport?

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

Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on Pi from source

[Joe Groff via swift-dev]

> On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev  
> wrote:
> 
> 
> I was able to get Swift running on my Raspberry Pi using a variant of the 
> instructions at 
>  
> but sadly the packages I’ve found haven’t been updated for Swift 2.2 (so 
> things like `associatedtype` don’t work nicely between Mac and Linux).
> 
> So, I thought I’d try building from source again hoping that the previous 
> failure was resolved. But I’m still hitting the unimplemented relocation 
> issue in LLVM’s RuntimeDyldELF.cpp, in 
> RuntimeDyldELF::resolveARMRelocation(), where the relocation type that is 
> being requested is R_ARM_GOT_PREL.
> 
> I thought I read in my last go-round on this that this was a regression in 
> LLVM, but I’m not finding a pointer to this now, so maybe I’m misremembering.
> 
> Is there a trick to avoiding this issue in LLVM, or an existing patch 
> somewhere that I can cherry-pick?

What linker are you using? GNU ld 2.26 in particular changed the behavior of 
protected visibility in a way that's incompatible with our usage, and we 
haven't fully implemented a workaround. You might try using gold or an older 
binutils, if that's what you're currently using.

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

Re: [swift-dev] [swift-evolution] [Compiler] Help IR gen in targetting MSVC

[Joe Groff via swift-dev]

> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Apr 26, 2016, at 1:03 PM, Sangjin Han  wrote:
>> The problem can be solved by modifying that code. Thanks you. I thought that 
>> code will affect only to the CLong type not Int.
> 
> It changes what 'long' gets imported as.  If there's a Windows API defined 
> using 'long' (rather than some more meaningful typedef like 'size_t'), it's 
> important for it to be imported as Int32 rather than Int, since 'long' is 
> always 32 bits under MSVC.
> 
>> But I meet another problem to fix it. I couldn't find the conditional method 
>> to distinct x86_64-*-windows-msvc with x86_64-*-windows-cygnus in Swift 
>> source.
>> 
>> "#if os(Windows)" can not distinct MSVC from Cygwin.
>> 
>> Should I add new condition 'env()' for the environment?
> 
> That is an excellent question.
> 
> My understanding / memory is that, as far as their programming interfaces 
> goes, Cygwin and MSVC are very, very different environments.  Maybe it's 
> useful to have a condition that's true for both environments — although I'm 
> not sure why it would — but I don't think it deserves to be as prominent as 
> os(Windows).  So my gut reaction is that, rather than adding a #env, we ought 
> to just reserve os(Windows) for MSVC compatibility and make a new os(Cygwin) 
> for Cygwin.
> 
> This needs to be raised on swift-evolution, though.  CC'ing that list.

It's an interesting question. Mingw, Cygwin, and MSVC definitely vary greatly 
in ABI and C language level behavior, but the underlying Win32 system libraries 
remain the same. I think it makes sense to consider them different os(...) 
environments, but it would also make sense IMO to have a broader platform check 
for Win32. Along similar lines, Linux, FreeBSD, and Darwin are different OSes, 
but all also share a POSIX environment.

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

[swift-dev] ObjC generic containers and ObjectiveCBridgeable conformance

[Joe Groff via swift-dev]

Importing ObjC generics is currently disabled for the bridged container 
classes, NSArray, NSDictionary, and NSSet. To enable generics for these types, 
we need to figure out what to do about their interaction with 
ObjectiveCBridgeable container bridging. The mapping from generic Swift value 
type to generic ObjC class is nontrivial, since the element type may itself be 
bridged—Array bridges to NSArray, whereas Array 
would bridge to NSArray. We'd need multiple constrained 
conformances to be able to accurately model this relationship at compile time. 
Absent that functionality, I can think of a couple of approaches in the short 
term:

1) Do nothing, and import NSArray and friends as nongeneric types.
2) Import NSArray and friends as generic, and define the ObjectiveCBridgeable 
relationship in terms of their upper bound type, so that Array bridges to 
NSArray, Dictionary to NSDictionary, and 
so on.
3) Do (2), but also do additional special-case bridging in the compiler 
(again), to insert unchecked conversions from the upper bound types like 
NSArray to the appropriate generic type NSArray.

Are there any other approaches I'm missing?

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

Re: [swift-dev] Help with SR-1052: Handling generic return values

[Joe Groff via swift-dev]

> On May 3, 2016, at 6:28 PM, Trent Nadeau via swift-dev  
> wrote:
> 
> Can anyone help me with this?

I replied to the patch: 
https://github.com/tanadeau/swift/commit/c1b3c8ed688b2bf231a8a0653ebbacd838549d5e#commitcomment-17347334

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev  
> wrote:
> 
> Hi,
> 
> I made an experimental MSVC port. Of cause, dllimport/dllexport and the 
> driver for linking and many other part is not implemented. But dynamic 
> linking was possible with some trick.
> 
> I think it is useful for designing, my observation about the experimental 
> building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll and linking of 
> Hello.exe - its source has only 'print("Hello")'.
> 
> 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
>   Hello.obj needed defined in libswift*.dll
> _swift_getExistentialTypeMetadata,
> _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> _TMSS,
> _TZvOs7Process5_argcVs5Int32,
> swift_bufferAllocate,  
>   Some of above are dllexported by the macro, but _T* are not. Maybe, it 
> generated by swiftc.exe.
>   I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts all 
> symbols and generates 'allsymbol.def'.
>   With that .def, I could build the all-symbol-dllexported libswiftCore.dll.
>   (I'm hoping we can build it without this trick.)

The _T symbols are emitted by the Swift compiler. You should modify swiftc's 
IRGen to generate public symbols with LLVM's "dllexport" storage class when 
targeting Windows.

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On May 7, 2016, at 4:01 PM, Sangjin Han  wrote:
> 
> Hi all,
> 
> I merged Saleem's #2080 to my working branch, and did some experiment.
> 
> I could compile easily Hello.swift with #2080 merged one.
> 
>   swiftc -c -o Hello.obj Hello.swift
>   clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport 
> -Wl,
> 
> Without #2080, I should use the *.ll-modifying-trick. It is perfect in this 
> example.
> 
> But, we need the way to disable dllimport. The immediate mode did not work.

If it only affects immediate mode, this might be a problem with LLVM's MCJIT. I 
would recommend asking llvm-dev, cc-ing Lang Hames (lha...@apple.com), to see 
what the right thing to do to reference DLL exports from JIT code is.

-Joe

>   swift Hello.swift
>   LLVM ERROR: Program used external function 
> '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could not 
> be resolved!
> 
>   swift -O Hello.swift
>   LLVM ERROR: Program used external function 
> '__imp__swift_getExistentialTypeMetadata' which could not be resolved!
> 
> It seems swift.exe call directly the function in the DLL without import 
> library.
> 
> The feature also needed when we link to static library.
> 
> I don't know about the SIL, IR, so it is thankful someone tell me how to 
> approach this problem.



> 
> 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool :
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev  
> wrote:
> 
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev  
> > wrote:
> >
> > Hi,
> >
> > I made an experimental MSVC port. Of cause, dllimport/dllexport and the 
> > driver for linking and many other part is not implemented. But dynamic 
> > linking was possible with some trick.
> >
> > I think it is useful for designing, my observation about the experimental 
> > building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll and linking of 
> > Hello.exe - its source has only 'print("Hello")'.
> >
> > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
> >   Hello.obj needed defined in libswift*.dll
> > _swift_getExistentialTypeMetadata,
> > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> > _TMSS,
> > _TZvOs7Process5_argcVs5Int32,
> > swift_bufferAllocate, 
> >   Some of above are dllexported by the macro, but _T* are not. Maybe, it 
> > generated by swiftc.exe.
> >   I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts all 
> > symbols and generates 'allsymbol.def'.
> >   With that .def, I could build the all-symbol-dllexported libswiftCore.dll.
> >   (I'm hoping we can build it without this trick.)
> 
> The _T symbols are emitted by the Swift compiler. You should modify swiftc's 
> IRGen to generate public symbols with LLVM's "dllexport" storage class when 
> targeting Windows.
> 
> https://github.com/apple/swift/pull/2080 is a first cut attempt to do this.
>  
> 
> -Joe
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> 
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> 

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

Re: [swift-dev] Consider removing the space in Swift AST dump's "decl" attribute?

[Joe Groff via swift-dev]

> On May 9, 2016, at 10:00 AM, Minsheng Liu via swift-dev  
> wrote:
> 
> Thanks for your information. However, what I intend to work on is a 
> Swift-to-JS translator, which I guess probably need to stick with the 
> upstream anyway. I think that make the output a bit more parsing-friendly 
> will not harm, will it?
> Moreover, if you do not suggest parse the dumped AST, is there any 
> recommended way to reuse the compiler’s front-end?

It would be better to use an interface designed for programmatic consumption, 
either coding against Swift's libSwiftAST.a directly, or through our libIDE or 
SourceKit, than to use our debug dumping outputs.

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On May 9, 2016, at 7:19 PM, Saleem Abdulrasool  wrote:
> 
> On Sat, May 7, 2016 at 7:55 PM, Sangjin Han  wrote:
> One more,
> 
> I couldn't build the libswiftCore.dll which can be used for Hello.swift. At 
> least one symbol _TMSS is not dllexported.
> (But I could build the dll with dlltool.exe which make all symbols to be 
> dllexported)
> 
> To find out the reason, I built a Swift.ll instead of the Swift.obj for the 
> libswiftCore.dll. The Swift.ll are built from many stdlib/public/core/*.swift 
> and core/8/*.swift files, and about 50MB.
> 
> In that file, I could find many dllexport symbols, like
> @_TZvOs7Process5_argcVs5Int32 = dllexport global %Vs5Int32 zeroinitializer, 
> align 4
> and Hello.ll uses them,
> @_TZvOs7Process5_argcVs5Int32 = external dllimport global %Vs5Int32, align 4
> 
> In the case of _TMSS, Hello.ll uses the same way,
> @_TMSS = external dllimport global %swift.type, align 8
> But, Swift.ll did not declared with dllexport.
> @_TMSS = alias %swift.type, bitcast (i64* getelementptr inbounds (<{ i8**, 
> i64, i64, %swift.type*, i64 }>, <{ i8**, i64, i64, %swift.type*, i64 }>* 
> @_TMfSS, i32 0, i32 1) to %swift.type*)
> 
> How we can make @_TMSS also has the dllexport?  Or any other solution ?
> 
> Interesting.  Does changing the string type from struct to class help?  Ill 
> try to have a look at this.

Did you handle the path that creates these llvm::GlobalAlias objects for type 
metadata when adding the dllimport/export attributes?

-Joe

>  
> 
> -Han Sangjin
> 
> 
> 
> 
> 2016-05-08 8:01 GMT+09:00 Sangjin Han :
> Hi all,
> 
> I merged Saleem's #2080 to my working branch, and did some experiment.
> 
> I could compile easily Hello.swift with #2080 merged one.
> 
>   swiftc -c -o Hello.obj Hello.swift
>   clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport 
> -Wl,
> 
> Without #2080, I should use the *.ll-modifying-trick. It is perfect in this 
> example.
> 
> But, we need the way to disable dllimport. The immediate mode did not work.
> 
>   swift Hello.swift
>   LLVM ERROR: Program used external function 
> '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could not 
> be resolved!
> 
>   swift -O Hello.swift
>   LLVM ERROR: Program used external function 
> '__imp__swift_getExistentialTypeMetadata' which could not be resolved!
> 
> It seems swift.exe call directly the function in the DLL without import 
> library.
> 
> The feature also needed when we link to static library.
> 
> I don't know about the SIL, IR, so it is thankful someone tell me how to 
> approach this problem.
> 
> 
> 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool :
> On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev  
> wrote:
> 
> > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev  
> > wrote:
> >
> > Hi,
> >
> > I made an experimental MSVC port. Of cause, dllimport/dllexport and the 
> > driver for linking and many other part is not implemented. But dynamic 
> > linking was possible with some trick.
> >
> > I think it is useful for designing, my observation about the experimental 
> > building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll and linking of 
> > Hello.exe - its source has only 'print("Hello")'.
> >
> > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
> >   Hello.obj needed defined in libswift*.dll
> > _swift_getExistentialTypeMetadata,
> > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> > _TMSS,
> > _TZvOs7Process5_argcVs5Int32,
> > swift_bufferAllocate, 
> >   Some of above are dllexported by the macro, but _T* are not. Maybe, it 
> > generated by swiftc.exe.
> >   I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts all 
> > symbols and generates 'allsymbol.def'.
> >   With that .def, I could build the all-symbol-dllexported libswiftCore.dll.
> >   (I'm hoping we can build it without this trick.)
> 
> The _T symbols are emitted by the Swift compiler. You should modify swiftc's 
> IRGen to generate public symbols with LLVM's "dllexport" storage class when 
> targeting Windows.
> 
> https://github.com/apple/swift/pull/2080 is a first cut attempt to do this.
>  
> 
> -Joe
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> 
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
> 
> 
> 
> 
> 
> -- 
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On May 10, 2016, at 2:25 PM, Saleem Abdulrasool  wrote:
> 
> On Monday, May 9, 2016, Joe Groff  wrote:
> 
> > On May 9, 2016, at 7:19 PM, Saleem Abdulrasool  
> > wrote:
> >
> > On Sat, May 7, 2016 at 7:55 PM, Sangjin Han  wrote:
> > One more,
> >
> > I couldn't build the libswiftCore.dll which can be used for Hello.swift. At 
> > least one symbol _TMSS is not dllexported.
> > (But I could build the dll with dlltool.exe which make all symbols to be 
> > dllexported)
> >
> > To find out the reason, I built a Swift.ll instead of the Swift.obj for the 
> > libswiftCore.dll. The Swift.ll are built from many 
> > stdlib/public/core/*.swift and core/8/*.swift files, and about 50MB.
> >
> > In that file, I could find many dllexport symbols, like
> > @_TZvOs7Process5_argcVs5Int32 = dllexport global %Vs5Int32 zeroinitializer, 
> > align 4
> > and Hello.ll uses them,
> > @_TZvOs7Process5_argcVs5Int32 = external dllimport global %Vs5Int32, align 4
> >
> > In the case of _TMSS, Hello.ll uses the same way,
> > @_TMSS = external dllimport global %swift.type, align 8
> > But, Swift.ll did not declared with dllexport.
> > @_TMSS = alias %swift.type, bitcast (i64* getelementptr inbounds (<{ i8**, 
> > i64, i64, %swift.type*, i64 }>, <{ i8**, i64, i64, %swift.type*, i64 }>* 
> > @_TMfSS, i32 0, i32 1) to %swift.type*)
> >
> > How we can make @_TMSS also has the dllexport?  Or any other solution ?
> >
> > Interesting.  Does changing the string type from struct to class help?  Ill 
> > try to have a look at this.
> 
> Did you handle the path that creates these llvm::GlobalAlias objects for type 
> metadata when adding the dllimport/export attributes?
> 
> Ah, awesome, thanks for that hint.  That was indeed missing.  I suppose I 
> should audit a few more things.  I'll upload a new version shortly that 
> should take care of the dll storage on metadata.
>  

It might help to centralize the logic. In IRGen, there's a function 
getIRLinkage that decomposes a semantic SIL visibility into an LLVM linkage and 
visibility pair:

https://github.com/apple/swift/blob/master/lib/IRGen/GenDecl.cpp#L1201

It could be modified to produce a three-element tuple that includes the DLL 
storage class too.

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

Re: [swift-dev] swift (ABI) and Windows

[Joe Groff via swift-dev]

> On May 10, 2016, at 3:11 PM, Sangjin Han  wrote:
> 
> Joe,
> 
> LLVM's MCJIT? Did you mean the REPL mode?

By immediate mode, do you mean "swift foo.swift", where the script is 
immediately compiled and executed? That also uses MCJIT.

> 
> I'm not ready to ask a question or understand the answer about them. Maybe it 
> takes some time for me to handle them.
> Currently, I want to concentrate on the immediate mode, dynamic/static 
> linking on Windows (MSVC).

I suspect that this is because of an LLVM bug in handling dllimport/export in 
JIT mode. Asking the LLVM list, you should at least be able to confirm this, 
and maybe get help from other LLVM users who've run into similar issues.

-Joe

> 
> By the way, in Cygwin (although it uses similar ABI and the COFF format), 
> immediate mode and dynamic linking worked without the dll import/export 
> consideration, it was 'ld''s magic. The immediate mode in Cygwin does not 
> work if dllimport is applied. (same to Windows(MSVC) )
> 
> I think we may consider for only MSVC, if the REPL in Cygwin works without 
> dllimport consideration.
> 
> -Han Sangjin
> 
> 2016-05-10 2:06 GMT+09:00 Joe Groff :
> 
> > On May 7, 2016, at 4:01 PM, Sangjin Han  wrote:
> >
> > Hi all,
> >
> > I merged Saleem's #2080 to my working branch, and did some experiment.
> >
> > I could compile easily Hello.swift with #2080 merged one.
> >
> >   swiftc -c -o Hello.obj Hello.swift
> >   clang -o Hello.exe Hello.obj -llibswiftCore -llibswiftSwiftOnoneSupport 
> > -Wl,
> >
> > Without #2080, I should use the *.ll-modifying-trick. It is perfect in this 
> > example.
> >
> > But, we need the way to disable dllimport. The immediate mode did not work.
> 
> If it only affects immediate mode, this might be a problem with LLVM's MCJIT. 
> I would recommend asking llvm-dev, cc-ing Lang Hames (lha...@apple.com), to 
> see what the right thing to do to reference DLL exports from JIT code is.
> 
> -Joe
> 
> >   swift Hello.swift
> >   LLVM ERROR: Program used external function 
> > '__imp_globalinit_33_1BDF70FFC18749BAB495A73B459ED2F0_func3' which could 
> > not be resolved!
> >
> >   swift -O Hello.swift
> >   LLVM ERROR: Program used external function 
> > '__imp__swift_getExistentialTypeMetadata' which could not be resolved!
> >
> > It seems swift.exe call directly the function in the DLL without import 
> > library.
> >
> > The feature also needed when we link to static library.
> >
> > I don't know about the SIL, IR, so it is thankful someone tell me how to 
> > approach this problem.
> 
> 
> 
> >
> > 2016-05-07 5:01 GMT+09:00 Saleem Abdulrasool :
> > On Thu, May 5, 2016 at 5:26 PM, Joe Groff via swift-dev 
> >  wrote:
> >
> > > On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev 
> > >  wrote:
> > >
> > > Hi,
> > >
> > > I made an experimental MSVC port. Of cause, dllimport/dllexport and the 
> > > driver for linking and many other part is not implemented. But dynamic 
> > > linking was possible with some trick.
> > >
> > > I think it is useful for designing, my observation about the experimental 
> > > building of libswiftCore.dll, libswiftSwiftOnoneSupport.dll and linking 
> > > of Hello.exe - its source has only 'print("Hello")'.
> > >
> > > 1) SWIFT_RUNTIME_EXPORT was not enough for dllexport.
> > >   Hello.obj needed defined in libswift*.dll
> > > _swift_getExistentialTypeMetadata,
> > > _TFs5printFTGSaP__9separatorSS10terminatorSS_T_,
> > > _TMSS,
> > > _TZvOs7Process5_argcVs5Int32,
> > > swift_bufferAllocate, 
> > >   Some of above are dllexported by the macro, but _T* are not. Maybe, it 
> > > generated by swiftc.exe.
> > >   I used the utility 'dlltool.exe' from Cygwin/MinGW world. It extracts 
> > > all symbols and generates 'allsymbol.def'.
> > >   With that .def, I could build the all-symbol-dllexported 
> > > libswiftCore.dll.
> > >   (I'm hoping we can build it without this trick.)
> >
> > The _T symbols are emitted by the Swift compiler. You should modify 
> > swiftc's IRGen to generate public symbols with LLVM's "dllexport" storage 
> > class when targeting Windows.
> >
> > https://github.com/apple/swift/pull/2080 is a first cut attempt to do this.
> >
> >
> > -Joe
> > ___
> > swift-dev mailing list
> > swift-dev@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-dev
> >
> >
> >
> > --
> > Saleem Abdulrasool
> > compnerd (at) compnerd (dot) org
> >
> 
> 

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

Re: [swift-dev] What do to when stdlib guidelines conflict with proposal?

[Joe Groff via swift-dev]

> On May 11, 2016, at 10:18 PM, Chris Lattner via swift-dev 
>  wrote:
> 
> On May 11, 2016, at 8:17 PM, Russ Bishop via swift-dev  
> wrote:
>> 
>>> On May 11, 2016, at 4:50 PM, Dmitri Gribenko  wrote:
>>> 
>>> On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev
>>>  wrote:
 I’m implementing SE-0017 but based on the standard library guidelines I 
 think Unmanaged should have initializers that take 
 UnsafePointer/UnsafeMutablePointer and vice-versa which would fit more 
 naturally with the way other conversions work.
 
 A later commit already moved toOpaque to be an initializer on 
 OpaquePointer. I would add convenience initializers to UnsafePointer as 
 well.
 
 Any objections to just implementing this as initializers and marking 
 fromOpaque as deprecated? I’m not sure how strict we should be in sticking 
 to the proposal.
>>> 
>>> Unmanaged shall be redesigned.  We thought about this change, and
>>> decided to go for the incremental change as proposed.  Bigger changes
>>> should be considered as a part of a cohesive Unmanaged redesign.
>>> 
>> 
>> Why did someone move toOpaque then? It seems like the door was already 
>> opened there - it isn’t possible to stick to the proposal as approved anyway.
>> 
>> I can certainly move it back but the initializer vs static seems like a 
>> best-practices and library design issue orthogonal to Unmanaged itself. 
>> 
>> 
>> At the end of the day if the core team still prefers to go with the 
>> fromOpaque/toOpaque approach I’m happy to implement it (in fact I have both 
>> implemented locally right now).
> 
> As Dmitri, we specifically discussed this in the core team meeting (I brought 
> it up :-).  The problem is that we really only want the toOpaque() method to 
> exist on UnsafePointer and don’t have the ability to model that in the 
> language yet.  When that ability exists, we’ll revise these APIs and many 
> others.
> 
> Until then, it is best to keep with the spirit of the current design, warts 
> and all.  Thanks for bringing this up!

We might want to wait till we review Andy's UnsafeBytePointer proposal. If we 
accept that, it will separate UnsafePointer into its own type.

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

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-dev]

> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev  
> wrote:
> 
> 
> - I’m uncomfortable with using the term “undefined behavior” as if it’s 
> universally understood. Up until now we haven't formally had that notion in 
> Swift, just “type safety” and “memory safety” and “invariant-preserving” and 
> the like. Maybe we need it now, but I think it needs to be explicitly 
> defined. (I’d actually talk to Dave about exactly what terms make the most 
> sense for users.)

We do have undefined behavior, and use that term in the standard library docs 
where appropriate:

stdlib/public/core/Optional.swift-  /// `!` (forced unwrap) operator. However, 
in optimized builds (`-O`), no
stdlib/public/core/Optional.swift-  /// check is performed to ensure that the 
current instance actually has a
stdlib/public/core/Optional.swift-  /// value. Accessing this property in the 
case of a `nil` value is a serious
stdlib/public/core/Optional.swift:  /// programming error and could lead to 
undefined behavior or a runtime
stdlib/public/core/Optional.swift-  /// error.
stdlib/public/core/Optional.swift-  ///
stdlib/public/core/Optional.swift-  /// In debug builds (`-Onone`), the 
`unsafelyUnwrapped` property has the same
--
stdlib/public/core/StringBridge.swift-  /// The caller of this function 
guarantees that the closure 'body' does not
stdlib/public/core/StringBridge.swift-  /// escape the object referenced by the 
opaque pointer passed to it or
stdlib/public/core/StringBridge.swift-  /// anything transitively reachable 
form this object. Doing so
stdlib/public/core/StringBridge.swift:  /// will result in undefined behavior.
stdlib/public/core/StringBridge.swift-  @_semantics("self_no_escaping_closure")
stdlib/public/core/StringBridge.swift-  func 
_unsafeWithNotEscapedSelfPointer(
stdlib/public/core/StringBridge.swift-_ body: @noescape (OpaquePointer) 
throws -> Result
--
stdlib/public/core/Unmanaged.swift-  /// reference's lifetime fixed for the 
duration of the
stdlib/public/core/Unmanaged.swift-  /// '_withUnsafeGuaranteedRef' call.
stdlib/public/core/Unmanaged.swift-  ///
stdlib/public/core/Unmanaged.swift:  /// Violation of this will incur undefined 
behavior.
stdlib/public/core/Unmanaged.swift-  ///
stdlib/public/core/Unmanaged.swift-  /// A lifetime of a reference 'the 
instance' is fixed over a point in the
stdlib/public/core/Unmanaged.swift-  /// programm if:

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

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-dev]

> On May 12, 2016, at 11:21 AM, John McCall  wrote:
> 
>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev 
>>  wrote:
>>> On May 12, 2016, at 10:44, Joe Groff  wrote:
>>> 
>>> 
 On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev 
  wrote:
 
 
 - I’m uncomfortable with using the term “undefined behavior” as if it’s 
 universally understood. Up until now we haven't formally had that notion 
 in Swift, just “type safety” and “memory safety” and 
 “invariant-preserving” and the like. Maybe we need it now, but I think it 
 needs to be explicitly defined. (I’d actually talk to Dave about exactly 
 what terms make the most sense for users.)
>>> 
>>> We do have undefined behavior, and use that term in the standard library 
>>> docs where appropriate:
>>> 
>>> stdlib/public/core/Optional.swift-  /// `!` (forced unwrap) operator. 
>>> However, in optimized builds (`-O`), no
>>> stdlib/public/core/Optional.swift-  /// check is performed to ensure that 
>>> the current instance actually has a
>>> stdlib/public/core/Optional.swift-  /// value. Accessing this property in 
>>> the case of a `nil` value is a serious
>>> stdlib/public/core/Optional.swift:  /// programming error and could lead to 
>>> undefined behavior or a runtime
>>> stdlib/public/core/Optional.swift-  /// error.
>>> stdlib/public/core/Optional.swift-  ///
>>> stdlib/public/core/Optional.swift-  /// In debug builds (`-Onone`), the 
>>> `unsafelyUnwrapped` property has the same
>>> --
>>> stdlib/public/core/StringBridge.swift-  /// The caller of this function 
>>> guarantees that the closure 'body' does not
>>> stdlib/public/core/StringBridge.swift-  /// escape the object referenced by 
>>> the opaque pointer passed to it or
>>> stdlib/public/core/StringBridge.swift-  /// anything transitively reachable 
>>> form this object. Doing so
>>> stdlib/public/core/StringBridge.swift:  /// will result in undefined 
>>> behavior.
>>> stdlib/public/core/StringBridge.swift-  
>>> @_semantics("self_no_escaping_closure")
>>> stdlib/public/core/StringBridge.swift-  func 
>>> _unsafeWithNotEscapedSelfPointer(
>>> stdlib/public/core/StringBridge.swift-_ body: @noescape (OpaquePointer) 
>>> throws -> Result
>>> --
>>> stdlib/public/core/Unmanaged.swift-  /// reference's lifetime fixed for the 
>>> duration of the
>>> stdlib/public/core/Unmanaged.swift-  /// '_withUnsafeGuaranteedRef' call.
>>> stdlib/public/core/Unmanaged.swift-  ///
>>> stdlib/public/core/Unmanaged.swift:  /// Violation of this will incur 
>>> undefined behavior.
>>> stdlib/public/core/Unmanaged.swift-  ///
>>> stdlib/public/core/Unmanaged.swift-  /// A lifetime of a reference 'the 
>>> instance' is fixed over a point in the
>>> stdlib/public/core/Unmanaged.swift-  /// programm if:
>> 
>> Those latter two are in stdlib-internal declarations. I think I have the 
>> same objection with using the term for 'unsafelyUnwrapped'.
> 
> Well, we can say "A program has undefined behavior if it does X or Y", or we 
> can say "A program which does X or Y lacks type safety".  In all cases we are 
> referring to a concept defined elsewhere.  If we say "undefined behavior", we 
> are using an easily-googled term whose popular discussions will quickly 
> inform the reader of the consequences of the violation.  If we say "type 
> safety", we are using a term with that's popularly used in very vague, 
> hand-wavey ways and whose consequences aren't usually discussed outside of 
> formal contexts.  If we say "memory safety", we're using a term that doesn't 
> even have that precedent.  So we can use the latter two terms if we want, but 
> that just means we need to have a standard place where we define them and 
> describe the consequences of violating them, probably with at least a 
> footnote saying "this is analogous to the undefined behavior rules of C and 
> C++".

In other places where the standard library intentionally has undefined 
behavior, it looks like we use the term "serious programming error", for 
instance in the the doc comment for `assert`:

/// * In -Ounchecked builds, `condition` is not evaluated, but the
///   optimizer may assume that it *would* evaluate to `true`. Failure
///   to satisfy that assumption in -Ounchecked builds is a serious
///   programming error.

which feels a bit colloquial to me, and doesn't provide much insight into the 
full consequences of UB. I think we're better off using an established term.

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

Re: [swift-dev] Relative Pointers and Windows ARM

[Joe Groff via swift-dev]

> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hi,
> 
> It seems that there are assumptions about the ability to create relative 
> address across sections which doesn't seem possible on Windows ARM.
> 
> Consider the following swift code:
> 
> final class _ContiguousArrayStorage { }
> 
> When compiled for Windows x86 (via swiftc -c -target i686-windows 
> -parse-as-library -parse-stdlib -module-name Swift -o Swift.obj 
> reduced.swift) it will generate the metadata pattern as:
> 
> __TMPCs23_ContiguousArrayStorage:
>   ...
>   .long 
> __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
>   ...
> 
> This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit relative 
> displacement of the target.
> 
> On Windows ARM (swiftc -c -target i686-windows -parse-pas-library 
> -parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will generate 
> similar assembly:
> 
> _TMPCs23_ContiguousArrayStorage:
>   ...
>   .long 
> _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
>   ...
> 
> However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the 
> 32-bit VA of the target.  If the symbol are in the same section, it is 
> possible to get a relative value.  However, I don't really see a way to 
> generate a relative offset across sections.  There is no relocation in the 
> COFF ARM specification which provides the 32-bit relative displacement of the 
> target.  There are 20, 23, and 24 bit relative displacements designed 
> specifically for branch instructions, but none that would operate on generic 
> data.
> 
> Is there a good way to address this ABI issue?  Or perhaps do we need 
> something more invasive to support such targets?  Now, I might be completely 
> overlooking something simple that I didn't consider, so pointing that out 
> would be greatly appreciated as well.

That's unfortunate. One possibly-crazy solution would be to use a different 
object format that does support the necessary relocations, such as LLVM's 
win32-macho target. That would forgo interoperability with non-LLVM toolchains, 
of course. 

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #4118

[Joe Groff via swift-dev]

Looks like my fault. I'll look into fixing it.

-Joe

> On May 18, 2016, at 3:58 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-osx [#4118]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/4118/
> Project:  oss-swift-incremental-RA-osx
> Date of build:Wed, 18 May 2016 15:40:21 -0700
> Build duration:   18 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
> Tests: 
> 
> Name: Swift
> Failed: 1 test(s), Passed: 7910 test(s), Total: 7911 test(s)
>   • Failed: Swift.IDE.import_as_member_objc.swift
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 351 test(s), Total: 351 test(s)
> 
> Changes
> 
>   • Commit d7e682abced99d9ff8629f0f37914034c02ea6b9 by daniel_dunbar:
> [Transmute] Remove unnecessary `public` attribute.
> 
>   • edit: Sources/Transmute/Package+sourceRoot.swift
> 
>   • Commit 0143eabd430c92dee6261a136cb1daf67e80fa1a by anders:
> [SR-1555] Temporarily disable whole-module optimization to avoid SR-1457
> 
>   • edit: Sources/Build/ToolProtocol.swift
>   • edit: Utilities/bootstrap
> 
>   • Commit 9633b476a42611ff0f91d7416f457c02cf1e6369 by daniel_dunbar:
> [Tests] Fix casing to match what test expects.
> 
>   • edit: Fixtures/Products/DynamicLibrary/Package.swift
> 
>   • Commit 55b5e13dc0f5c2f9f8ccc829b37f2ec7ea1b90c7 by daniel_dunbar:
> [POSIX] Change mkdir() to expect a single argument.
> 
>   • edit: Sources/Build/describe().swift
>   • edit: Tests/Utility/RmtreeTests.swift
>   • edit: Sources/Xcodeproj/generate().swift
>   • edit: Tests/Functional/ValidLayoutTests.swift
>   • edit: Sources/POSIX/mkdir.swift
>   • edit: Tests/Functional/ModuleMapTests.swift
>   • edit: Tests/Utility/PathTests.swift
> 
>   • Commit bde5857290039ebedcbb3ba727462f0ccdd5ad7a by daniel_dunbar:
> [POSIX] Change mkdir() to require an absolute path.
> 
>   • edit: Tests/Build/DescribeTests.swift
>   • edit: Sources/Build/Command.link().swift
>   • edit: Sources/Xcodeproj/generate().swift
>   • edit: Sources/Build/PackageVersion.swift
>   • edit: Sources/Build/misc.swift
>   • edit: Sources/Get/PackagesDirectory.swift
>   • edit: Sources/POSIX/mkdir.swift
>   • edit: Sources/swift-build/main.swift
>   • edit: Sources/Build/describe().swift
> 
>   • Commit 0fd26da4bd76637505e5627f3a402b82c9e8 by daniel_dunbar:
> [POSIX] Change mkdir() to not return anything.
> 
>   • edit: Tests/Functional/ValidLayoutTests.swift
>   • edit: Sources/POSIX/mkdir.swift
>   • edit: Sources/Build/describe().swift
>   • edit: Sources/Xcodeproj/generate().swift
>   • edit: Tests/Functional/ModuleMapTests.swift
> 
>   • Commit 5fdf4fce724ab3c66de1340b94944e17e17c3b6a by daniel_dunbar:
> [Tests] Update for SE-0047.
> 
>   • edit: Tests/PackageLoading/Utilities.swift
> 
>   • Commit d1ed26d0c2dbffc981c2096ef0ad8bfbbdc064bb by daniel_dunbar:
> [Tests] Fix duplicated utilities.
> 
>   • edit: Tests/Get/Utilities.swift
>   • edit: Tests/Utility/Utilities.swift
>   • edit: Tests/Functional/Utilities.swift
>   • edit: Tests/Build/Utilities.swift
>   • edit: Tests/Transmute/Utilities.swift
>   • edit: Tests/PackageLoading/Utilities.swift
>   • edit: Tests/Xcodeproj/Utilities.swift
> 
>   • Commit 0103fb4eafce7f6021f319a9c69718b030d80e60 by jgroff:
> Update ImportAsMember test not to use unprototyped function.
> 
>   • edit: test/IDE/Inputs/custom-modules/ImportAsMember.h
> 
>   • Commit ca53873226e94b077cb4c55f3b39034af64fdaa1 by dfarler:
> Don't show private discriminators in simplified demanglings
> 
>   • edit: test/Demangle/Inputs/simplified-manglings.txt
>   • edit: include/swift/Basic/Demangle.h
>   • edit: test/Demangle/Inputs/manglings.txt
>   • edit: lib/Basic/Demangle.cpp

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #4118

[Joe Groff via swift-dev]

Should be fixed by e248f83df9afc7bd588f264984f6ca0396c8015d.

-Joe

> On May 18, 2016, at 4:00 PM, Joe Groff via swift-dev  
> wrote:
> 
> Looks like my fault. I'll look into fixing it.
> 
> -Joe
> 
>> On May 18, 2016, at 3:58 PM, no-re...@swift.org wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#4118]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/4118/
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Wed, 18 May 2016 15:40:21 -0700
>> Build duration:  18 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
>> Tests: 
>> 
>> Name: Swift
>> Failed: 1 test(s), Passed: 7910 test(s), Total: 7911 test(s)
>>  • Failed: Swift.IDE.import_as_member_objc.swift
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 351 test(s), Total: 351 test(s)
>> 
>> Changes
>> 
>>  • Commit d7e682abced99d9ff8629f0f37914034c02ea6b9 by daniel_dunbar:
>> [Transmute] Remove unnecessary `public` attribute.
>> 
>>  • edit: Sources/Transmute/Package+sourceRoot.swift
>> 
>>  • Commit 0143eabd430c92dee6261a136cb1daf67e80fa1a by anders:
>> [SR-1555] Temporarily disable whole-module optimization to avoid SR-1457
>> 
>>  • edit: Sources/Build/ToolProtocol.swift
>>  • edit: Utilities/bootstrap
>> 
>>  • Commit 9633b476a42611ff0f91d7416f457c02cf1e6369 by daniel_dunbar:
>> [Tests] Fix casing to match what test expects.
>> 
>>  • edit: Fixtures/Products/DynamicLibrary/Package.swift
>> 
>>  • Commit 55b5e13dc0f5c2f9f8ccc829b37f2ec7ea1b90c7 by daniel_dunbar:
>> [POSIX] Change mkdir() to expect a single argument.
>> 
>>  • edit: Sources/Build/describe().swift
>>  • edit: Tests/Utility/RmtreeTests.swift
>>  • edit: Sources/Xcodeproj/generate().swift
>>  • edit: Tests/Functional/ValidLayoutTests.swift
>>  • edit: Sources/POSIX/mkdir.swift
>>  • edit: Tests/Functional/ModuleMapTests.swift
>>  • edit: Tests/Utility/PathTests.swift
>> 
>>  • Commit bde5857290039ebedcbb3ba727462f0ccdd5ad7a by daniel_dunbar:
>> [POSIX] Change mkdir() to require an absolute path.
>> 
>>  • edit: Tests/Build/DescribeTests.swift
>>  • edit: Sources/Build/Command.link().swift
>>  • edit: Sources/Xcodeproj/generate().swift
>>  • edit: Sources/Build/PackageVersion.swift
>>  • edit: Sources/Build/misc.swift
>>  • edit: Sources/Get/PackagesDirectory.swift
>>  • edit: Sources/POSIX/mkdir.swift
>>  • edit: Sources/swift-build/main.swift
>>  • edit: Sources/Build/describe().swift
>> 
>>  • Commit 0fd26da4bd76637505e5627f3a402b82c9e8 by daniel_dunbar:
>> [POSIX] Change mkdir() to not return anything.
>> 
>>  • edit: Tests/Functional/ValidLayoutTests.swift
>>  • edit: Sources/POSIX/mkdir.swift
>>  • edit: Sources/Build/describe().swift
>>  • edit: Sources/Xcodeproj/generate().swift
>>  • edit: Tests/Functional/ModuleMapTests.swift
>> 
>>  • Commit 5fdf4fce724ab3c66de1340b94944e17e17c3b6a by daniel_dunbar:
>> [Tests] Update for SE-0047.
>> 
>>  • edit: Tests/PackageLoading/Utilities.swift
>> 
>>  • Commit d1ed26d0c2dbffc981c2096ef0ad8bfbbdc064bb by daniel_dunbar:
>> [Tests] Fix duplicated utilities.
>> 
>>  • edit: Tests/Get/Utilities.swift
>>  • edit: Tests/Utility/Utilities.swift
>>  • edit: Tests/Functional/Utilities.swift
>>  • edit: Tests/Build/Utilities.swift
>>  • edit: Tests/Transmute/Utilities.swift
>>  • edit: Tests/PackageLoading/Utilities.swift
>>  • edit: Tests/Xcodeproj/Utilities.swift
>> 
>>  • Commit 0103fb4eafce7f6021f319a9c69718b030d80e60 by jgroff:
>> Update ImportAsMember test not to use unprototyped function.
>> 
>>  • edit: test/IDE/Inputs/custom-modules/ImportAsMember.h
>> 
>>  • Commit ca53873226e94b077cb4c55f3b39034af64fdaa1 by dfarler:
>> Don't show private discriminators in simplified demanglings
>> 
>>  • edit: test/Demangle/Inputs/simplified-manglings.txt
>>  • edit: include/swift/Basic/Demangle.h
>>  • edit: test/Demangle/Inputs/manglings.txt
>>  • edit: lib/Basic/Demangle.cpp
> 
> ___
> 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] Relative Pointers and Windows ARM

[Joe Groff via swift-dev]

> On May 19, 2016, at 9:07 AM, John McCall via swift-dev  
> wrote:
> 
>> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool  
>> wrote:
>> Hi,
>> 
>> It seems that there are assumptions about the ability to create relative 
>> address across sections which doesn't seem possible on Windows ARM.
>> 
>> Consider the following swift code:
>> 
>> final class _ContiguousArrayStorage { }
>> 
>> When compiled for Windows x86 (via swiftc -c -target i686-windows 
>> -parse-as-library -parse-stdlib -module-name Swift -o Swift.obj 
>> reduced.swift) it will generate the metadata pattern as:
>> 
>>__TMPCs23_ContiguousArrayStorage:
>>  ...
>>  .long 
>> __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
>>  ...
>> 
>> This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit 
>> relative displacement of the target.
>> 
>> On Windows ARM (swiftc -c -target i686-windows -parse-pas-library 
>> -parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will 
>> generate similar assembly:
>> 
>>_TMPCs23_ContiguousArrayStorage:
>>  ...
>>  .long 
>> _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
>>  ...
>> 
>> However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the 
>> 32-bit VA of the target.  If the symbol are in the same section, it is 
>> possible to get a relative value.  However, I don't really see a way to 
>> generate a relative offset across sections. There is no relocation in the 
>> COFF ARM specification which provides the 32-bit relative displacement of 
>> the target.  There are 20, 23, and 24 bit relative displacements designed 
>> specifically for branch instructions, but none that would operate on generic 
>> data.
>> 
>> Is there a good way to address this ABI issue?  Or perhaps do we need 
>> something more invasive to support such targets?  Now, I might be completely 
>> overlooking something simple that I didn't consider, so pointing that out 
>> would be greatly appreciated as well.
> 
> You can build PIC on Windows ARM, right?  How does Microsoft compile this:
> 
>  static int x;
>  int *get_x_addr() { return &x; }

I'm not familiar with Windows ARM, but if image loading works like Windows on 
Intel, then PIC isn't a thing—everything is compiled for a fixed address, and 
the kernel brute-force slides all the addresses at load time if it can't map an 
exe or dll at its preferred address.

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

Re: [swift-dev] Relative Pointers and Windows ARM

[Joe Groff via swift-dev]

> On May 18, 2016, at 6:01 PM, Saleem Abdulrasool  wrote:
> 
> On Wednesday, May 18, 2016, Joe Groff  wrote:
> 
> > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev 
> >  wrote:
> >
> > Hi,
> >
> > It seems that there are assumptions about the ability to create relative 
> > address across sections which doesn't seem possible on Windows ARM.
> >
> > Consider the following swift code:
> >
> > final class _ContiguousArrayStorage { }
> >
> > When compiled for Windows x86 (via swiftc -c -target i686-windows 
> > -parse-as-library -parse-stdlib -module-name Swift -o Swift.obj 
> > reduced.swift) it will generate the metadata pattern as:
> >
> > __TMPCs23_ContiguousArrayStorage:
> >   ...
> >   .long 
> > __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
> >   ...
> >
> > This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit 
> > relative displacement of the target.
> >
> > On Windows ARM (swiftc -c -target i686-windows -parse-pas-library 
> > -parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will 
> > generate similar assembly:
> >
> > _TMPCs23_ContiguousArrayStorage:
> >   ...
> >   .long 
> > _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
> >   ...
> >
> > However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the 
> > 32-bit VA of the target.  If the symbol are in the same section, it is 
> > possible to get a relative value.  However, I don't really see a way to 
> > generate a relative offset across sections.  There is no relocation in the 
> > COFF ARM specification which provides the 32-bit relative displacement of 
> > the target.  There are 20, 23, and 24 bit relative displacements designed 
> > specifically for branch instructions, but none that would operate on 
> > generic data.
> >
> > Is there a good way to address this ABI issue?  Or perhaps do we need 
> > something more invasive to support such targets?  Now, I might be 
> > completely overlooking something simple that I didn't consider, so pointing 
> > that out would be greatly appreciated as well.
> 
> That's unfortunate. One possibly-crazy solution would be to use a different 
> object format that does support the necessary relocations, such as LLVM's 
> win32-macho target. That would forgo interoperability with non-LLVM 
> toolchains, of course
> 
> Yeah, it would make interoperability harder.  But, is there a loader for 
> macho on Windows?

Sorry, if it wasn't clear, I meant that you could use mach-o (or ELF, or any 
object format really) for .o and .a files. You'd still link them into PE 
executables and DLLs.

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

Re: [swift-dev] Relative Pointers and Windows ARM

[Joe Groff via swift-dev]

> On May 19, 2016, at 12:22 PM, Tom Birch  wrote:
> 
> Would it be acceptable to make relative pointers optional, so we can pay the 
> extra load-time cost on platforms where it's hard/undesirable to implement 
> them?

That's also a reasonable answer, since sliding DLLs is already fairly costly. 
We'd need a bunch of extra tests to ensure both the relative and absolute forms 
work, though maybe with David Farler's work to abstract relative addresses it's 
already straightforward to have the RelativePointer<..> templates in the 
runtime work in a platform-independent way.

-Joe

> cheers,
> Tom
> 
> On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev  
> wrote:
> 
> > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool  
> > wrote:
> >
> > On Wednesday, May 18, 2016, Joe Groff  wrote:
> >
> > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev 
> > >  wrote:
> > >
> > > Hi,
> > >
> > > It seems that there are assumptions about the ability to create relative 
> > > address across sections which doesn't seem possible on Windows ARM.
> > >
> > > Consider the following swift code:
> > >
> > > final class _ContiguousArrayStorage { }
> > >
> > > When compiled for Windows x86 (via swiftc -c -target i686-windows 
> > > -parse-as-library -parse-stdlib -module-name Swift -o Swift.obj 
> > > reduced.swift) it will generate the metadata pattern as:
> > >
> > > __TMPCs23_ContiguousArrayStorage:
> > >   ...
> > >   .long 
> > > __TMnCs23_ContiguousArrayStorage-(__MPCs23_ContiguousArrayStorage+128)
> > >   ...
> > >
> > > This generates a IMAGE_REL_I386_REL32 relocation which is the 32-bit 
> > > relative displacement of the target.
> > >
> > > On Windows ARM (swiftc -c -target i686-windows -parse-pas-library 
> > > -parse-stdlib -module-name Swift -o Swift.obj reduced.swift) it will 
> > > generate similar assembly:
> > >
> > > _TMPCs23_ContiguousArrayStorage:
> > >   ...
> > >   .long 
> > > _TMnCs23_ContiguousArrayStorage-(_MPCs23_ContiguousArrayStorage+128)
> > >   ...
> > >
> > > However, this generates an IMAGE_REL_ARM_ADDR32 relocation which is the 
> > > 32-bit VA of the target.  If the symbol are in the same section, it is 
> > > possible to get a relative value.  However, I don't really see a way to 
> > > generate a relative offset across sections.  There is no relocation in 
> > > the COFF ARM specification which provides the 32-bit relative 
> > > displacement of the target.  There are 20, 23, and 24 bit relative 
> > > displacements designed specifically for branch instructions, but none 
> > > that would operate on generic data.
> > >
> > > Is there a good way to address this ABI issue?  Or perhaps do we need 
> > > something more invasive to support such targets?  Now, I might be 
> > > completely overlooking something simple that I didn't consider, so 
> > > pointing that out would be greatly appreciated as well.
> >
> > That's unfortunate. One possibly-crazy solution would be to use a different 
> > object format that does support the necessary relocations, such as LLVM's 
> > win32-macho target. That would forgo interoperability with non-LLVM 
> > toolchains, of course
> >
> > Yeah, it would make interoperability harder.  But, is there a loader for 
> > macho on Windows?
> 
> Sorry, if it wasn't clear, I meant that you could use mach-o (or ELF, or any 
> object format really) for .o and .a files. You'd still link them into PE 
> executables and DLLs.
> 
> -Joe
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (swift-3.0-preview-1) #102

[Joe Groff via swift-dev]

These failures should clear up once https://github.com/apple/swift/pull/2650 
gets approved and merged.

-Joe

> On May 23, 2016, at 1:25 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-3.0-preview-1-incremental-RA-osx [#102]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.0-preview-1-incremental-RA-osx/102/
> Project:  oss-swift-3.0-preview-1-incremental-RA-osx
> Date of build:Mon, 23 May 2016 12:50:29 -0700
> Build duration:   34 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
> Tests: 
> 
> Name: Swift
> Failed: 3 test(s), Passed: 7901 test(s), Total: 7904 test(s)
>   • Failed: Swift.ClangModules.attr-swift_name_renaming.swift
>   • Failed: Swift.IDE.dump_swift_lookup_tables.swift
>   • Failed: Swift.IDE.import_as_member.swift
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 351 test(s), Total: 351 test(s)
> 
> Changes
> 
>   • Commit 10c854a489eec1e22fbafb306d9e8b45656d9fde by jgroff:
> Tighten up validation of swift_name for properties and subscripts.
> 
>   • edit: include/clang/Basic/DiagnosticIDs.h
>   • edit: lib/Sema/SemaDeclAttr.cpp
>   • edit: test/SemaObjC/attr-swift.m
>   • edit: include/clang/Basic/DiagnosticSemaKinds.td
> 
>   • Commit 247d1ec514cd3d6fe388d62579d77646ec7ee8d2 by jgroff:
> Only allow swift_name attributes on prototyped declarations.
> 
>   • edit: include/clang/Basic/DiagnosticSemaKinds.td
>   • edit: test/SemaObjC/attr-swift.m
>   • edit: lib/Sema/SemaDeclAttr.cpp
> 
>   • Commit 151224d09a657759fb0fb1692675d1b7161d0fc8 by jgroff:
> Validate swift_names that come from API notes.
> 
>   • edit: include/clang/Sema/Sema.h
>   • edit: test/SemaObjC/attr-swift.m
>   • edit: lib/Sema/SemaDeclAttr.cpp
>   • edit: lib/Sema/SemaAPINotes.cpp
>   • edit: include/clang/Basic/DiagnosticSemaKinds.td
> 
>   • Commit 6a04995c4cf751c0c9d395535f03ff8716864e73 by jgroff:
> Collect swift_name warnings under a swift-name-attribute warning group.
> 
>   • edit: include/clang/Basic/DiagnosticGroups.td
>   • edit: include/clang/Basic/DiagnosticSemaKinds.td
> 
>   • Commit fd5852165856a5a34cf2e837fdfa85dee5a6105d by friss:
> Update identifiers as needed when loading macros from serialized ASTs.
> 
>   • edit: lib/Serialization/ASTReader.cpp
> 
>   • Commit 2080eea7abdb79812a6e9f5f3be3a41078044466 by friss:
> Fixed a bug where the ASTImporter didn't propagate builtin IDs at all.
> 
>   • edit: lib/AST/ASTImporter.cpp

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

Re: [swift-dev] Please remove your Swift build directory

[Joe Groff via swift-dev]

> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev 
>  wrote:
> 
> Hi,
> 
> We have merged a CMake and build-script refactoring that requires a
> from-scratch build.  Trying to use an existing build directory will
> result in strange errors in the middle of the build.
> 
> Excuse me for the inconvenience.

This seems to have broken Xcode project generation, which in the default 
configuration now fails with:

-- 
CMake Error at CMakeLists.txt:702 (message):
  Unknown SDKs:
  IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATOR

Probably easy to work around by manually configuring out those SDKs, since 
Xcode projects don't support cross-building to begin with, but this used to 
just work.

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

Re: [swift-dev] Please remove your Swift build directory

[Joe Groff via swift-dev]

> On May 31, 2016, at 10:20 AM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev 
>>  wrote:
>> 
>> Hi,
>> 
>> We have merged a CMake and build-script refactoring that requires a
>> from-scratch build.  Trying to use an existing build directory will
>> result in strange errors in the middle of the build.
>> 
>> Excuse me for the inconvenience.
> 
> This seems to have broken Xcode project generation, which in the default 
> configuration now fails with:
> 
>   -- 
>   CMake Error at CMakeLists.txt:702 (message):
> Unknown SDKs:
> IOS;IOS_SIMULATOR;TVOS;TVOS_SIMULATOR;WATCHOS;WATCHOS_SIMULATOR
> 
> Probably easy to work around by manually configuring out those SDKs, since 
> Xcode projects don't support cross-building to begin with, but this used to 
> just work.

New build-script also appears to pass some CMake variables that aren't used in 
the ninja configuration:

-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

SWIFT_BUILD_EXAMPLES
SWIFT_HOST_TRIPLE

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

Re: [swift-dev] NSProxy dynamic casting to Swift or ObjC class behaves differently

[Joe Groff via swift-dev]

> On Jun 8, 2016, at 12:44 AM, Yavuz Nuzumlalı via swift-dev 
>  wrote:
> 
> Hi all,
> 
> swift_dynamicCastClassUnconditional and 
> swift_dynamicCastObjCClassUnconditional methods behave differently while 
> verifying casting.
> 
> swift_dynamicCastObjCClassUnconditional method calls -isKindOfClass: method 
> before falling back to object_getClass function.
> 
> swift_dynamicCastClassUnconditional method calls swift_dynamicCastClass 
> method which calls _swift_getClassOfAllocated method which calls directly 
> object_getClass function.
> 
> This causes problems if underlying object is an NSProxy subclass.
> 
> NSProxy class does not implement -isKindOfClass: method, so calls to this 
> method are forwarded to the real object through -forwardInvocation: method, 
> which causes -isKindOfClass: method to return answer according to the real 
> object's class.
> 
> However, object_getClass function directly accesses to the metadata of the 
> given object, so it returns NSProxy subclass.
> 
> I think this is a conflicting behavior, and I think 
> swift_dynamicCastClassUnconditional method should also verify first using 
> -isKindOfClass: method, in order to provide consistency.

This is intentional, since NSProxy instances are generally expected to be 
standins for the proxied object. Important Cocoa idioms break down if the 
"real" class is exposed instead of the class a proxy pretends to be.

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

Re: [swift-dev] Help needed: Removing inout shadow copy from SILGen

[Joe Groff via swift-dev]

> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev  
> wrote:
> 
> Hi all,
> 
> I'm resuming work on removing the SILGen for the inout shadow copy. Making
> this change involes quite a bit of tests updates.  I'd love some one to review
> this commit in SILGenProlog.cpp before I dive back into the deep end:
> 
> https://github.com/dduan/swift/commit/e56d73c065bec7bdde7c0ffee42b808d1bb52d74
> 
> (It's +5, -12, a small patch).
> 
> Is this on the right track?

The variable binding looks great. We might need to coordinate with the debugger 
to ensure we still emit debug info the way lldb expects it; cc'ing Adrian and 
Enrico.

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

Re: [swift-dev] Help needed: Removing inout shadow copy from SILGen

[Joe Groff via swift-dev]

> On Jun 9, 2016, at 10:01 AM, Adrian Prantl  wrote:
> 
> On Jun 9, 2016, at 9:55 AM, Joe Groff  wrote:
>> 
>> 
>>> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm resuming work on removing the SILGen for the inout shadow copy. Making
>>> this change involes quite a bit of tests updates.  I'd love some one to 
>>> review
>>> this commit in SILGenProlog.cpp before I dive back into the deep end:
>>> 
>>> https://github.com/dduan/swift/commit/e56d73c065bec7bdde7c0ffee42b808d1bb52d74
>>> 
>>> (It's +5, -12, a small patch).
>>> 
>>> Is this on the right track?
>> 
>> The variable binding looks great. We might need to coordinate with the 
>> debugger to ensure we still emit debug info the way lldb expects it; cc'ing 
>> Adrian and Enrico.
>> 
>> -Joe
> 
> The diff looks generally reasonable to me. You will probably have to update a 
> bunch of debug info testcases along with this change.
> 
> You can run the LLDB test suite with by running
>  $ build-script -r -l -t -- --skip-test-cmark --skip-test-swift 
> --lldb-test-with-curses --lldb-use-system-debugserver
> 
> Since I missed the original discussion, I’m curious about the context though: 
> under what circumstances is an inout argument be passed by value and can it 
> ever be a let binding?

An inout can never be a 'let' binding. It's always passed by-reference, but 
previously, we would inject a shadow copy with writeback on the callee side to 
allow captures to reference the inout without extending the original argument's 
lifetime. We no longer allow this, so inouts are always simply passed by 
reference now.

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

Re: [swift-dev] Problem in parsing SIL

[Joe Groff via swift-dev]

> On Jun 21, 2016, at 2:03 PM, Slava Pestov via swift-dev  
> wrote:
> 
> Hi Mikio,
> 
> Try this:
> 
> swiftc -frontend -emit-silgen classdecl.swift > classdecl.sil
> swiftc -parse-sil classdecl.sil
> 
> I'm not sure why -emit-silgen sometimes emits type declarations and other 
> times not. The only difference I can see is what without the -frontend flag, 
> the driver passes in -primary-file, whereas with -frontend, it does not.
> 
> Perhaps Joe or Jordan can chime in.

This is clearly a bug, but SIL's parser and printer quality generally doesn't 
have much pressure on it beyond what's minimally necessary to enable optimizer 
and codegen debugging.

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

Re: [swift-dev] Requiring blocks (universally)

[Joe Groff via swift-dev]

> On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev 
>  wrote:
> 
> Hi,
> 
> The blocks runtime itself is pretty tiny, and works across various targets 
> already, so including it is not too onerous.  As such, Id like to propose 
> enabling blocks across all the targets.
> 
> This make it easier to then import code on targets which have optional blocks 
> support.  For most users, this would be a transparent change, but would mean 
> that the clang importer goes through a more similar path across the various 
> targets.

It's a little trickier than that. We only support Swift refcounting object 
headers on non-Darwin platforms, since there's no universal objc_retain 
implementation to fall back to. Blocks don't use Swift-compatible refcounting 
with the current runtime.

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

Re: [swift-dev] SE-0095: SIL syntax and Any.self problem

[Joe Groff via swift-dev]

> On Jul 4, 2016, at 9:29 AM, Josef Willsher via swift-dev 
>  wrote:
> 
> Hi everyone,
> 
> I’ve been implementing SE-0095 (here) and have hit an issue around how 
> Any.self is treated.
> 
> When in the type position, I parse Any like any other type, and resolve it to 
> be an empty protocol composition in the constraint system, in 
> resolveTopLevelTypeComponent. 
> 
> This does not work for metatype lookup, where the lookup is unconstrained and 
> I need to find a ValueDecl for the Any type. Currently I have kept the 
> stdlib’s typealias Any = protocol<> so the type system can look to the stdlib 
> through getAnyDecl to find it. Does anyone have an idea about how this could 
> be done without this; there are no other keywords that need this sort of 
> unconstrained lookup and are implicitly declared?

A ValueDecl for a type shouldn't be required for a metatype expression, since 
something like (Int, String).self or (() -> ()).self ought to work too. Type 
resolution ought to handle this by turning the subexpression into a TypeExpr 
before we do type checking; see PreCheckExpression::simplifyTypeExpr.

> Another question I had: does SE-0095 extend to SIL syntax? The proposal 
> does’t mention it, but I think it would seem out of place to keep the 
> protocol<> pattern in .sil if we are replacing it in .swift, the AST, and the 
> demangler.

SIL mostly reuses Swift's type syntax, so this should fall out. You will want 
to ensure the demangler and the runtime use the new syntax when printing 
metatype values.

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

Re: [swift-dev] Fixits

[Joe Groff via swift-dev]

> On Jul 7, 2016, at 10:19 AM, Erica Sadun via swift-dev  
> wrote:
> 
> Where is the best place to request fixits? bugs.swift.org or on this list?
> 
> I've been porting a lot of code to Swift 3 and finding a lot of issue and no 
> before you ask, I stupidly did not write them down as I went and I now wish I 
> had -- I just was on a deadline and needed the code ported and working.
> 
> Do fixits need to be proposed?

I would say that a bug report is an adequate proposal for most fixits.

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

Re: [swift-dev] id-as-Any and ObjC generic parameters

[Joe Groff via swift-dev]

> On Jul 7, 2016, at 5:26 PM, John McCall  wrote:
> 
> Suppose we are calling a function that is generic over T, where T: AnyObject. 
>  This comes up when e.g. calling an initializer for an ObjC generic class.
> 
> Today we allow conversions from [String] to [NSString], String to NSString, 
> and [String] to [T], but we do not allow a conversion from String to T.  The 
> concrete conversions are allowed because there is a bridging conversion from 
> String to NSString.  The generic "scalar" conversion is not allowed because 
> the type-checker's enumeration of possible supertypes does not consider 
> bridged types.  The generic array conversion is allowed because the 
> special-case code that governs collection up-casting in the type-checker 
> immediately turns the generic argument into its bridged type and so bypasses 
> that flaw.
> 
> One goal of the id-as-Any import change is to remove the implicit bridging 
> conversions and the widespread use of AnyObject constraints.  As part of 
> this, [U] will convert to [V] only when U is convertible to V.  This implies 
> that both of the generic conversions above would be rejected.
> 
> With no other changes, this means that when calling an ObjC generic 
> initializer, e.g.:
>  @interface Generic
>  - (id) initWithArray: (NSArray *) array;
>  @end
> it will not be possible to pass a [String] (inferring T == NSObject).  This 
> is technically a regression.
> 
> Well, maybe we don't care.
> 
> If we do care, one option is to try to bridge generic parameters and their 
> constraints.  Effectively, this would mean removing the implicitly AnyObject 
> constraint on all ObjC generic parameters.  If we did this, it would be 
> possible to pass a [String] to the initializer of Generic, and inferring T == 
> String; SILGen would then recognize the need to bridge to NSArray 
> when passing the argument.  But this is a fair amount of work that I think is 
> new to the plan.
> 
> Thoughts?

I tried to subset handling generic parameters out. While it's definitely a 
possibility, it seems like something we could tackle in an additive fashion 
later, since removing the 'AnyObject' constraint from generics is "just" 
removing requirements. I think we can live with the lack of conversion in ObjC 
generics. It's already the case that ObjC generic covariance doesn't carry over 
to Swift, and I don't think we have bandwidth to make that work for this 
release either.

-Joe
___
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.0-preview-5) #8

[Joe Groff via swift-dev]

Should be fixed by https://github.com/apple/swift/pull/3786.

-Joe

> On Jul 26, 2016, at 4:40 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-3.0-preview-5-incremental-RA-osx [#8]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.0-preview-5-incremental-RA-osx/8/
> Project:  oss-swift-3.0-preview-5-incremental-RA-osx
> Date of build:Tue, 26 Jul 2016 16:34:15 -0700
> Build duration:   6 min 25 sec
> Identified problems:
> 
>   • Assertion failure: This build failed because of an assertion failure. 
> Below is a list of all errors in the build log:
>   • Indication 1
> 
> Changes
> 
>   • Commit 372f315e19fb9437a920d3815c1d1e14e8f14b16 by jgroff:
> Allow single-element tuples in SIL mode.
> 
>   • edit: lib/Sema/TypeCheckType.cpp
> 
>   • Commit 5bd4d8e536e3ffc3d417bdfc27db697d375f9ad6 by jgroff:
> Foundation: Make AnyHashable bridge to NSObject.
> 
>   • edit: stdlib/public/SDK/Foundation/Foundation.swift
>   • edit: lib/AST/ASTContext.cpp
> 
>   • Commit 199062a26efe9b04cafdfde48ed6a90eb7e960bf by jgroff:
> ClangImporter: Import unbounded NSSets and NSDictionaries using
> 
>   • edit: test/1_stdlib/NSError.swift
>   • edit: test/DebugInfo/test-foundation.swift
>   • edit: stdlib/public/SDK/Foundation/NSStringAPI.swift
>   • edit: include/swift/AST/ASTContext.h
>   • edit: stdlib/public/SDK/Foundation/NSError.swift
>   • edit: test/1_stdlib/NSEnumeratorAPI.swift
>   • edit: test/IDE/print_clang_foundation.swift
>   • edit: stdlib/public/SDK/CoreImage/CoreImage.swift
>   • edit: stdlib/public/SDK/Foundation/Foundation.swift
>   • edit: test/1_stdlib/ErrorBridged.swift
>   • edit: test/SILGen/objc_bridged_results.swift
>   • edit: lib/ClangImporter/ImporterImpl.h
>   • edit: test/ClangModules/objc_bridging_generics.swift
>   • edit: test/ClangModules/objc_bridging.swift
>   • edit: test/IDE/print_omit_needless_words.swift
>   • edit: lib/ClangImporter/ImportType.cpp
>   • edit: lib/AST/ASTContext.cpp
>   • edit: test/SILGen/Inputs/Foundation.swift
> 
>   • Commit 58cbe78f87085302a990dbad2d6dcc48732f0441 by jgroff:
> SIL: Relax linkage assertion in SILModule::getOrCreateFunction.
> 
>   • edit: lib/SIL/SILModule.cpp
> 
>   • Commit 5ff808628faeb5973a47c6b0edc0ff9e8ba7ca68 by jgroff:
> Update changelog for SE-0131.
> 
>   • edit: CHANGELOG.md
> 
>   • Commit 240bf2e640af639c0e6fe138515cc3ee061ac1ab by jgroff:
> Disable cast optimization for address-only types.
> 
>   • edit: lib/SILOptimizer/Utils/Local.cpp
> 
>   • Commit 177a029cf0094012a9cb755f29be3eabe5baab76 by jgroff:
> Make all _toAnyHashable() implements @nonobjc.
> 
>   • edit: stdlib/public/SDK/Foundation/PersonNameComponents.swift
>   • edit: stdlib/public/SDK/Foundation/CharacterSet.swift
>   • edit: stdlib/public/SDK/Foundation/Calendar.swift
>   • edit: stdlib/public/SDK/Foundation/IndexPath.swift
>   • edit: stdlib/public/SDK/Foundation/IndexSet.swift
>   • edit: stdlib/public/SDK/Foundation/Locale.swift
>   • edit: stdlib/public/SDK/Foundation/UUID.swift
>   • edit: stdlib/public/SDK/Foundation/URLComponents.swift
>   • edit: stdlib/public/SDK/Foundation/Data.swift
>   • edit: stdlib/public/SDK/Foundation/AffineTransform.swift
>   • edit: stdlib/public/SDK/Foundation/Date.swift
>   • edit: stdlib/public/SDK/Foundation/Foundation.swift
>   • edit: stdlib/public/SDK/Foundation/TimeZone.swift
>   • edit: stdlib/public/SDK/Foundation/URLRequest.swift
>   • edit: stdlib/public/SDK/Foundation/DateInterval.swift
>   • edit: stdlib/public/SDK/Foundation/DateComponents.swift
>   • edit: stdlib/public/SDK/Foundation/Measurement.swift
>   • edit: stdlib/public/SDK/Foundation/Notification.swift
>   • edit: stdlib/public/SDK/Foundation/URL.swift
> 
>   • Commit 11a5c71160d604766f2e36ec87484bf0af5d0d84 by aschwaighofer:
> Fix ASTContext::getBridgedToObjC to not return None under id-as-any
> 
>   • edit: lib/SIL/DynamicCasts.cpp
>   • edit: test/SILOptimizer/cast_folding_objc.swift
>   • edit: lib/SILOptimizer/Utils/Local.cpp
>   • edit: lib/AST/ASTContext.cpp
>   • edit: 
> test/SILOptimizer/specialize_unconditional_checked_cast.swift
> 
>   • Commit f821c1e80edc0e805d6287cf0fc75f8d41d24c7c by Mishal Shah:
> [uitls] Add support for swift-3.0-preview-5-branch to update checkout
> 
>   • edit: utils/update-checkout-config.json

___
swift-dev mailing list
swi

Re: [swift-dev] Is developer snapshot 2016-07-29 broken?

[Joe Groff via swift-dev]

> On Jul 31, 2016, at 5:12 AM, Charles Lane via swift-dev  
> wrote:
> 
> I get a segmentation fault 11 at compile time with the 07/29 toolchain & 
> Xcode 8 beta 3. Can anyone point me in right direction to fix this?

Should be addressed by https://github.com/apple/swift/pull/3918.

-Joe

> 
> MergeSwiftModule normal x86_64 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/FoodPin.swiftmodule
> cd 
> /Users/charleslane/Documents/SWDevelopment/SwiftStuff/AppCoda_Starter/FoodPin
> 
> /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-07-29-a.xctoolchain/usr/bin/swift
>  -frontend -emit-module 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/AddRestaurantController~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/RestaurantTableViewController~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/SAConfettiView~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/ReviewViewController~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/RestaurantTableViewCell~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/GlobalHelpers~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/RestaurantDetailTableViewCell~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/RestaurantDetailViewController~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/AppDelegate~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/AddRestaurantExtensions~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/MapViewController~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/Restaurant+CoreDataClass~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/Restaurant+CoreDataProperties~partial.swiftmodule
>  
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/Objects-normal/x86_64/FoodPin+CoreDataModel~partial.swiftmodule
>  -parse-as-library -target x86_64-apple-ios10.0 -enable-objc-interop -sdk 
> /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.0.sdk
>  -I 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Products/Debug-iphonesimulator
>  -F 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Products/Debug-iphonesimulator
>  -enable-testing -g -module-cache-path 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/ModuleCache 
> -serialize-debugging-options -Xcc 
> -I/Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/FoodPin.build/swift-overrides.hmap
>  -Xcc -iquote -Xcc 
> /Users/charleslane/Library/Developer/Xcode/DerivedData/FoodPin-dxwmvlsjauworxcjhxialmqbjmnw/Build/Intermediates/FoodPin.build/Debug-iphonesimulator/F

Re: [swift-dev] swift-corelibs-foundation failing in object conversion when building on Darwin host

[Joe Groff via swift-dev]

> On Aug 4, 2016, at 1:21 PM, Philippe Hausler via swift-dev 
>  wrote:
> 
> With a freshly built toolchain from ToT swift, building ToT 
> swift-corelibs-foundation I am getting some very strange failures in the unit 
> tests:
> 
> Test Suite 'TestNSKeyedArchiver' started at 13:15:01.843
> Test Case 'TestNSKeyedArchiver.test_archive_array' started at 13:15:01.843
> assertion failed: file 
> /Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
>  line 23
> 2016-08-04 13:15:07.650689 TestFoundation[47395:4939580] assertion failed: 
> file 
> /Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
>  line 23
> Current stack trace:
> 
> this is being caused by the line:
> 
> let classReference = innerDecodingContext.dict["$class"] as? 
> CFKeyedArchiverUID
> 
> CFKeyedArchiverUID being AnyObject
> 
> and 
> 
> class DecodingContext {
>fileprivate var dict : Dictionary
>   …
> }
> 
> It claims a conditional cast from Any? to AnyObject always succeeds but it is 
> giving me an unexpected type later on
> 
> Changing to:
> 
> let classReference = innerDecodingContext.dict["$class"] as 
> CFKeyedArchiverUID?

This is the same problem you raised recently on 
https://bugs.swift.org/browse/SR-2287. Coercing something to AnyObject on 
Darwin will bridge it, by boxing if there is no corresponding bridged type. 
Since you're coercing an Optional, and Optional doesn't bridge, you end up with 
a boxed Optional. To work around this, you could do 'dict["$class"].map { $0 as 
AnyObject }'.

-Joe

> 
> Then makes the process no longer crash, however it then fails in an even more 
> strange way:
> 
> 
> guard let root = try unarchiver.decodeTopLevelObjectOfClasses(classes,
>forKey: NSKeyedArchiveRootObjectKey) as? NSObject else 
> {
> 
> by expanding that out the decoded object is a NSArray (expected), but that 
> cannot be represented as an NSObject?! This isn’t Swift, this is madness!
> 
> Perhaps there is some other failure that I am not seeing underpinning this?
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] Swift's handling of function types

[Joe Groff via swift-dev]

> On Aug 27, 2016, at 9:28 AM, Jens Persson via swift-dev  
> wrote:
> 
> IMHO Swift's handling of function types violate the principle of least 
> surprise.
> 
> In the example program below, are `a` and `b` really of the same function 
> type?
> 
> I searched but couldn't find any proposal or discussion addressing this.
> 
> 
> // (Xcode 8 beta 6, toolchain: development snapshot 2016-08-26)
> 
> let a:  (Int, Int)  -> Int = { (a, b) in a + b }
> let b: ((Int, Int)) -> Int = a
> // So `a` can be casted to `b`'s type, OK.

This is no longer intended to be the case in Swift 3. The former has two 
arguments, the latter has one argument. The implementation has not fully caught 
up with this change, though.

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