[swift-dev] Swift path

[Piero Sabino via swift-dev]

I must type the following line in .bashrc
/Home/Downloads/swift/usr/bin/swift

Inviato da iPhone
 Piero Sabino
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Brent Royal-Gordon via swift-dev]

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? 

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] Swift Path

[Piero Sabino via swift-dev]

So the path saved in my .bashrc is wrong.
What would be the correct one?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Starter project: Initializers for converting UnsafePointers to integers

[Michael Buckley via swift-dev]

I'm looking for a good starter project, so normally I would be interested
in taking this, but I'm not sure I can think of a good motivation for it.
UnsafePointer's advanceBy and distanceTo functions take care of pointer
arithmetic more safely than converting to int would, and the
debugDescription property can get you the address for debugging purposes.

Considering that everything that goes through the swift-evolution process
needs to have a motivation, is there a use case for this that I'm not
thinking of?

On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev <
swift-dev@swift.org> wrote:

> Hi everyone,
>
> The standard library has bitPattern initializers on pointers. But we
> are missing initializers to create integers from pointers.
>
> Someone needs to propose these APIs, walk them through
> swift-evolution, write a patch for the library and add tests.
>
> extension UInt {
>   init(bitPattern: UnsafePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
>
>   init(bitPattern: UnsafeMutablePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
>
> extension Int {
>   init(bitPattern: UnsafePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
>
>   init(bitPattern: UnsafeMutablePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
>
> https://bugs.swift.org/browse/SR-131
>
> Dmitri
>
> --
> 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
>
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Starter project: Initializers for converting UnsafePointers to integers

[Stephen Canon via swift-dev]

When writing high-performance code, it is fairly common to check the alignment 
of pointers so that initial elements can be processed until some suitable 
alignment is reached to use a faster implementation, or to verify that a fast 
algorithm can be used.

> On Dec 8, 2015, at 10:59 AM, Michael Buckley via swift-dev 
>  wrote:
> 
> I'm looking for a good starter project, so normally I would be interested in 
> taking this, but I'm not sure I can think of a good motivation for it. 
> UnsafePointer's advanceBy and distanceTo functions take care of pointer 
> arithmetic more safely than converting to int would, and the debugDescription 
> property can get you the address for debugging purposes.
> 
> Considering that everything that goes through the swift-evolution process 
> needs to have a motivation, is there a use case for this that I'm not 
> thinking of?
> 
> On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Hi everyone,
> 
> The standard library has bitPattern initializers on pointers. But we
> are missing initializers to create integers from pointers.
> 
> Someone needs to propose these APIs, walk them through
> swift-evolution, write a patch for the library and add tests.
> 
> extension UInt {
>   init(bitPattern: UnsafePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> 
>   init(bitPattern: UnsafeMutablePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
> 
> extension Int {
>   init(bitPattern: UnsafePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> 
>   init(bitPattern: UnsafeMutablePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
> 
> https://bugs.swift.org/browse/SR-131 
> 
> Dmitri
> 
> --
> 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 
> 
> 
>  ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] Starter project: Initializers for converting UnsafePointers to integers

[Michael Buckley via swift-dev]

Checking alignment good use case, which I did not consider. Not to turn
this into a swift-evolution topic, but couldn't this use case be covered by
adding functions to UnsafePointer? I'm thinking something like this.

func distanceToBoundary(_ boundary: Int) -> Distance {
return Builtin.ptrtoint_Word(self._rawValue) % boundary
}

func isAlignedToBoundary(_ boundary: Int) -> Boolean {
return distanceToBoundary(boundary) == 0
}

I'll admit I don't have a lot of experience working with algorithms which
check pointer alignment. If you need a check that requires a more
complicated equation, then yeah, converting UnsafePointers to Ints is
probably the best solution. But if possible, it's probably best to avoid
requiring users to convert to int and back. They not only need to write
less code if UnsafePointers can take care of this for them, but it also
prevents subtle bugs they may write. (E.g. Converting 2 UnsafePointers to
UInts and then subtracting them to find the distance, but subtracting the
larger pointer from the smaller one).

On Tue, Dec 8, 2015 at 8:45 AM, Stephen Canon  wrote:

> When writing high-performance code, it is fairly common to check the
> alignment of pointers so that initial elements can be processed until some
> suitable alignment is reached to use a faster implementation, or to verify
> that a fast algorithm can be used.
>
> On Dec 8, 2015, at 10:59 AM, Michael Buckley via swift-dev <
> swift-dev@swift.org> wrote:
>
> I'm looking for a good starter project, so normally I would be interested
> in taking this, but I'm not sure I can think of a good motivation for it.
> UnsafePointer's advanceBy and distanceTo functions take care of pointer
> arithmetic more safely than converting to int would, and the
> debugDescription property can get you the address for debugging purposes.
>
> Considering that everything that goes through the swift-evolution process
> needs to have a motivation, is there a use case for this that I'm not
> thinking of?
>
> On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Hi everyone,
>>
>> The standard library has bitPattern initializers on pointers. But we
>> are missing initializers to create integers from pointers.
>>
>> Someone needs to propose these APIs, walk them through
>> swift-evolution, write a patch for the library and add tests.
>>
>> extension UInt {
>>   init(bitPattern: UnsafePointer) {
>> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init(bitPattern: UnsafeMutablePointer) {
>> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> extension Int {
>>   init(bitPattern: UnsafePointer) {
>> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init(bitPattern: UnsafeMutablePointer) {
>> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> https://bugs.swift.org/browse/SR-131
>>
>> Dmitri
>>
>> --
>> 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
>>
>
> ___
> 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] Starter Project

[Sergey Bolshedvorsky via swift-dev]

Hi everyone,

I’m looking for a starter project on swift. Something what would be useful and 
what would allow me to dive into the code. I could take one of the JIRA 
tickets. Do not want to fix typos. :)

Sergey


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

Re: [swift-dev] Starter Project

[Meador Inge via swift-dev]

On Tue, Dec 8, 2015 at 1:03 PM, Sergey Bolshedvorsky via swift-dev <
swift-dev@swift.org> wrote:

Hi everyone,
>
> I’m looking for a starter project on swift. Something what would be useful
> and what would allow me to dive into the code. I could take one of the JIRA
> tickets. Do not want to fix typos. :)
>

Did you look at the unassigned start bugs?

https://bugs.swift.org/issues/?jql=labels%20%3D%20StarterBug%20AND%20assignee%20in%20(EMPTY)

You might want to cross check those with the mailing list and see if there
has been discussion about them already.

Cheers,

Meador
___
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

[swift-dev] Questions about _Reflectable and CustomReflectable

[Austin Zheng via swift-dev]

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)?

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?

Best regards,
Austin
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Starter Project

[Meador Inge via swift-dev]

(CC'd back the list)

On Tue, Dec 8, 2015 at 1:19 PM, Sergey Bolshedvorsky <
ser...@bolshedvorsky.com> wrote:

I could take this ticket: https://bugs.swift.org/browse/SR-125
>

Go for it!

I see where you already assigned it to yourself in JIRA.

Have fun :-)

Cheers,

Meador
___
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

[swift-dev] Starter project: 'swift-format' tool: Move the swift indentation mechanism from SourceKit to libIDE and utilize it for a command-line tool

[Argyrios Kyrtzidis via swift-dev]

Hi all,

If someone is looking for a starter project in our tooling support area, here’s 
one you can dig your teeth into:

SourceKit contains indentation logic that is not exposed in the libIDE library; 
this is not desirable, primarily because SourceKit is not cross-platform. Here 
are some steps to improve on this:

• Move the indentation logic from SourceKit to libIDE. Have SourceKit 
just expose the functionality contained in libIDE.
• Start a 'swift-format’ command-line tool that uses the indentation 
mechanism from libIDE; given a file and source range it auto-indents it.
• See prior work for 'clang-format' 
(http://clang.llvm.org/docs/ClangFormat.html) for investigation on how to 
specify and provide formatting options.

This is tracked via https://bugs.swift.org/browse/SR-146

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

Re: [swift-dev] Build error on OS X.

[Jordan Rose via swift-dev]

If you get the chance, please do file a bug at bugs.swift.org 
 about this. Spaces in paths should not cause problems 
in 2015!

Jordan

> On Dec 7, 2015, at 17:01, Alexandros Salazar via swift-dev 
>  wrote:
> 
> Ah. Silly me. Thank you.
> 
> On Mon, Dec 7, 2015 at 7:07 PM, Maxim Moiseev  > wrote:
> Looks like the name of the folder you chose is the problem: space in ‘Open 
> Source’ is not properly escaped.
> Please try to copy it to another folder and run the build script again.
> 
> max
> 
>> On Dec 7, 2015, at 12:29 PM, Alexandros Salazar via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> I am trying to build Swift on OS X and get the following error:
>> 
>> clang: error: no such file or directory: 
>> 'Source/swift/build/Ninja-ReleaseAssert/llvm-macosx-x86_64/lib/Transforms/Hello/LLVMHello.exports'
>> 
>> I have tried running ./swift/utils/build-script as well as 
>> ./swift/utils/build-script -R and the compilation ends at the same spot both 
>> times. I have checked, and the file exists, assuming "Source" represents the 
>> parent of the directory where all the repositories were cloned (per the 
>> README at ). 
>> 
>> Has anyone run into this? Am I missing something obvious? I have attached 
>> the log.
>> 
>> Thanks for the help.
>> Alex
>>  ___
>> 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] Starter project: Initializers for converting UnsafePointers to integers

[Jordan Rose via swift-dev]

The one I can think of is "sometimes a C API only lets you pass data as an Int 
(intptr_t) or as an UnsafeMutablePointer (void *), and you have the other kind 
of data". That said, it does seem to be sort of a niche use case.

Jordan

> On Dec 8, 2015, at 7:59, Michael Buckley via swift-dev  
> wrote:
> 
> I'm looking for a good starter project, so normally I would be interested in 
> taking this, but I'm not sure I can think of a good motivation for it. 
> UnsafePointer's advanceBy and distanceTo functions take care of pointer 
> arithmetic more safely than converting to int would, and the debugDescription 
> property can get you the address for debugging purposes.
> 
> Considering that everything that goes through the swift-evolution process 
> needs to have a motivation, is there a use case for this that I'm not 
> thinking of?
> 
> On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev 
> mailto:swift-dev@swift.org>> wrote:
> Hi everyone,
> 
> The standard library has bitPattern initializers on pointers. But we
> are missing initializers to create integers from pointers.
> 
> Someone needs to propose these APIs, walk them through
> swift-evolution, write a patch for the library and add tests.
> 
> extension UInt {
>   init(bitPattern: UnsafePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> 
>   init(bitPattern: UnsafeMutablePointer) {
> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
> 
> extension Int {
>   init(bitPattern: UnsafePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> 
>   init(bitPattern: UnsafeMutablePointer) {
> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>   }
> }
> 
> https://bugs.swift.org/browse/SR-131 
> 
> Dmitri
> 
> --
> 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 
> 
> 
>  ___
> 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] Optionals in swift-clang

[Jordan Rose via swift-dev]

Hi, Seth. I think you're getting Clang / swift-clang mixed up with swiftc / 
swift. Clang is not the Swift compiler; the Swift compiler lives in the "swift" 
repo. Swift depends on Clang for its interoperation with C and Objective-C.

A lot of the compiler encodes information about Optional, but most of it stems 
from ASTContext.h and ASTContext.cpp, which has dedicated entrypoints for 
getting Optional, Optional.None, and Optional.Some.

Hope this helps,
Jordan

> On Dec 8, 2015, at 17:59 , Seth Friedman via swift-dev  
> wrote:
> 
> Hi all,
> 
> In Optional.swift in the stdlib, there's a comment that says "The compiler 
> has special knowledge of Optional, including the fact that it is an 
> enum with cases named 'None' and 'Some'."
> 
> What I'm trying to understand is: If I wanted to implement the optional type 
> from scratch, what would be the process I would go through? I've scoured the 
> swift-clang project and can't seem to find any reference to optionals or even 
> Swift explicitly. I discovered nullability attributes and am hypothesizing 
> that an expression of something like "Type?" is somehow mapped to an 
> attribute, but I'm really just stumbling around in the dark.
> 
> In terms of what I've tried, I've gone through a lot of the source in the 
> swift-clang lib/Basic and lib/AST directories, and I've read through the 
> "Clang CFE Internals Manual" on the Clang website.
> 
> Help is much appreciated!
> 
> Thanks in advance,
> Seth
>  ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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

Re: [swift-dev] Starter project: Initializers for converting UnsafePointers to integers

[Michael Buckley via swift-dev]

Yeah, that makes sense. If your C API requires an intptr_t, you can't solve
that problem by adding more functions to UnsafePointer. I'll go ahead and
start a discussion over on swift-evolution. Thanks!

On Tue, Dec 8, 2015 at 3:07 PM, Jordan Rose  wrote:

> The one I can think of is "sometimes a C API only lets you pass data as an
> Int (intptr_t) or as an UnsafeMutablePointer (void *), and you have the
> other kind of data". That said, it does seem to be sort of a niche use case.
>
> Jordan
>
> On Dec 8, 2015, at 7:59, Michael Buckley via swift-dev <
> swift-dev@swift.org> wrote:
>
> I'm looking for a good starter project, so normally I would be interested
> in taking this, but I'm not sure I can think of a good motivation for it.
> UnsafePointer's advanceBy and distanceTo functions take care of pointer
> arithmetic more safely than converting to int would, and the
> debugDescription property can get you the address for debugging purposes.
>
> Considering that everything that goes through the swift-evolution process
> needs to have a motivation, is there a use case for this that I'm not
> thinking of?
>
> On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev <
> swift-dev@swift.org> wrote:
>
>> Hi everyone,
>>
>> The standard library has bitPattern initializers on pointers. But we
>> are missing initializers to create integers from pointers.
>>
>> Someone needs to propose these APIs, walk them through
>> swift-evolution, write a patch for the library and add tests.
>>
>> extension UInt {
>>   init(bitPattern: UnsafePointer) {
>> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init(bitPattern: UnsafeMutablePointer) {
>> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> extension Int {
>>   init(bitPattern: UnsafePointer) {
>> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init(bitPattern: UnsafeMutablePointer) {
>> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> https://bugs.swift.org/browse/SR-131
>>
>> Dmitri
>>
>> --
>> 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
>>
>
> ___
> 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] Inconsistent trapping for Bit

[Patrick Pijnappel via swift-dev]

Swift.Bit traps for Bit.One.successor(), but not for Bit.One.advancedBy(1).

The documentation suggest they should be equivalent.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Zhuowei Z via swift-dev]

Hello,
I'm currently working on adding support to the Swift compiler to allow it to 
target Android. Currently I've managed to get the stdlib to compile after 
hacking around/disabling a bunch of stuff (the custom linker script, the 
dl_iterate_phdr stuff, and the posix_spawn support), and managed to compile and 
run the simplest proof-of-concept  (import Glibc; exit(42)).
My fork is located at https://github.com/SwiftAndroid/swift and I would really 
appreciate any comments and suggestions.
In particular, I would like some help on the following issues:
- The current build system assumes that the host and the target has the same 
version of libicu. Android doesn't ship with libicu, so I had to point the 
build script to a copy of libicu manually. However, the same ICU include path 
is used to compile all target stdlibs,including the host one, so I had to make 
sure that my libicu headers matches the host one. Is there a way for me to 
specify in the build system to use a different libicu for one of the targets?
- The current stdlib build system also assumes that the host and the target are 
of the same OS family, so currently only Linux hosts can target Android. Is 
there anything I can do to allow Mac hosts to also target Android?
- 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?
- How should Swift integrate with the Android NDK?
- The version of Clang shipped with Ubuntu 15.10 can't seem to find the 
arm-linux-androideabi-ld linker even though I've pointed it to the Android 
NDK's copy via -gcc-toolchain. It only seems to check 
/usr/bin/armv7-none-linux-androideabi-ld before falling back to /usr/bin/ld. 
The Clang from the Android NDK can find the NDK ld fine. Is there a particular 
command line option I need to pass into the Ubuntu clang to make it look for 
the arm-linux-androideabi-ld in the gcc-toolchain folder?
Thank you for your help and for your work on Swift.
Zhuowei Zhang ___
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

[Dmitri Gribenko via swift-dev]

Hi William,

On Tue, Dec 8, 2015 at 8:00 PM, William Dillon via swift-dev <
swift-dev@swift.org> wrote:

> Hi all,
>
> I’ve been working on trying to get Swift to compile on ARMv7 (armv7l
> specifically, not sure if other variants will work as well).  I’ve gotten
> pretty far, but I ran a cross an issue that has me a little confused.  For
> convenience, here’s the bug that has some of my messages in the comments:
> https://bugs.swift.org/browse/SR-40 and here’s my Github fork if you want
> to play along at home: https://github.com/hpux735/swift  By the way, I’m
> compiling on an Nvidia tegra TK2 development board with 2GB of ram and a
> 25GB swapfile on an external SSD.  This brings native compile times down to
> reasonable levels.  I was compiling on the BeagleBone Black formerly, and
> that was painful (like over a day for LLVM).
>
> So far, cmark and llvm compile just fine (no surprise there), and swift
> gets pretty far along.  The weird issue, which will certainly expose my
> weakness in C++ and large build systems, is that the swift_ssize_t doesn’t
> match ssize_t.
>
> [6/61] Building CXX object
> stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/Stubs.cpp.o
> FAILED: /usr/bin/clang++   -DGTEST_HAS_RTTI=0 -D_DEBUG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -fno-stack-protector -fPIC -fvisibility-inlines-hidden -Wall -W
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor
> -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections
> -fdata-sections -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code
> -Woverloaded-virtual -O3  -Istdlib/public/stubs
> -I/home/wdillon/swift/stdlib/public/stubs -I/home/wdillon/swift/include
> -Iinclude
> -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/include
> -I/home/wdillon/llvm/include
> -I/home/wdillon/build/Ninja-ReleaseAssert/llvm-linux-armv7/tools/clang/include
> -I/home/wdillon/llvm/tools/clang/include -I/home/wdillon/cmark/src
> -I/home/wdillon/build/Ninja-ReleaseAssert/cmark-linux-armv7/src-UNDEBUG
>  -fno-exceptions -fno-rtti  -Wglobal-constructors -Wexit-time-destructors
> -target arm-unknown-linux-gnueabihf -isysroot / -O2 -g0 -UNDEBUG -MMD -MT
> stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o
> -MF
> "stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o.d"
> -o
> stdlib/public/stubs/CMakeFiles/swiftStdlibStubs-linux-armv7.dir/LibcShims.cpp.o
> -c /home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp
> /home/wdillon/swift/stdlib/public/stubs/LibcShims.cpp:24:1: error:
> static_assert failed "__swift_ssize_t is wrong"
> static_assert(std::is_same::value,
> ^ 
> 1 error generated.
>
> Now, the sizes match (4 bytes each), but the std::is_same() function says
> no.  I grep’d the clang codebase for the definition of ssize_t, and it
> seems like it’s a ‘long’ whereas the swift_ssize_t is a 'long int’.
>

'long' and 'long int' are the same type.

Try preprocessing the following program with 'clang -E' and check how the
type is defined:

#include 
#include 


> I looked into the LibcShims a bit, and the expectation is that the
> definition in the header is not universally correct, and will be checked:
>
> // This declaration is not universally correct.  We verify its correctness
> for
> // the current platform in the runtime code.
> typedef long int __swift_ssize_t;
>
> And it is thusly (in LibcShims.cpp):
>
> static_assert(std::is_same::value,
> "__swift_ssize_t is wrong”);
>
> What’s less clear is the mechanism with which I am to change this
> definition in a way that doesn’t mess-up other platforms.
>
>
Use #if:

#if defined(__linux__) && defined(__arm__)
...
#else
...
#endif

To find the specific macro names to check for, dump the predefines buffer
and find an appropriate one (although I think __linux__ and __arm__ are
correct):

echo "" | clang -x c++ -std=c++11 - -dM -E

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
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

[Chris Lattner via swift-dev]

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.

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

Re: [swift-dev] Starter project: Convert release notes into something useful

[Chris Lattner via swift-dev]

> On Dec 7, 2015, at 4:21 PM, joe via swift-dev  wrote:
> 
> Nm my question about the duplicated content, I just noticed after starting to 
> look into this that some of the notes in the Xcode release notes are the same 
> as in the CHANGELOG. I'll get started on adding the missing content.

Sounds great, thanks Joe.  Someone contributed a slightly modified version of 
the Xcode release notes, which helped round them out, but lots of details (and 
resolution on when things went in) are missing.

-Chris

> 
>> On Dec 7, 2015, at 4:21 PM, joe via swift-dev  wrote:
>> 
>> Now that the CHANGELOG.md file is in place, I can take a look at the 
>> "archeology exercise" bit. The updates to the Xcode release notes for 
>> official releases are online 
>> (https://developer.apple.com/library/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html),
>>  but Radek, if you have the beta release notes handy, those may be useful in 
>> creating more granular updates to the changelog.
>> 
>> It won't be too difficult to pull out the sections relevant to Swift from 
>> the Xcode release notes, but is that what we want in the CHANGELOG? I want 
>> to make sure it's ok to have the duplicated content added, or if the purpose 
>> of the CHANGELOG might be somewhat different than Xcode's release notes (at 
>> least the sections pertaining the Swift language itself).
>> 
>>> On Dec 6, 2015, at 5:53 AM, Radosław Pietruszewski via swift-dev 
>>>  wrote:
>>> 
>>> If someone wants to tackle the “archeology exercise”, those might help :)
>>> 
>>> - SwiftInFlux has Xcode 6.1/Swift 1.1 history pretty well preserved: 
>>> https://github.com/ksm/SwiftInFlux#changed-in-xcode-611 (unfortunately the 
>>> project died down before Swift 2 came around)
>>> - I have a copy of almost all Xcode 6—Xcode 7.1 Release Notes I can share 
>>> privately on request
>>> 
>>> — Radek
>>> 
 We have this document, which captures some of the evolution of swift over 
 time in the form of release notes:
 
 https://github.com/apple/swift/blob/master/utils/buildbot-release-notes.txt
 
 
 We’ve started updating it for behavior changes in Swift 2.2, and think 
 that something like it is important so that when we do a release, we have 
 a way to make sure that sometime important isn’t missed.  Users like to 
 know what’s new :-)
 
 That said, it has two pretty serious problems:
 - It is missing content on what happened between Oct 2014 and the start of 
 the Swift 2.2 cycle.
 - It is a weird little text file off in an undiscoverable place in the 
 source tree.
 
 Fixing the former problem is a bit of an archeology exercise, the later 
 problem is more of a content/design problem.  Is anyone interested in 
 tackling either of these?
 
 -Chris 
 
>>> 
>>> 
>>> ___
>>> swift-dev mailing list
>>> swift-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>> 
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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