Optionals in swift-clang


(Seth Friedman) #1

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The compiler
has special knowledge of Optional<Wrapped>, 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


(Jordan Rose) #2

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 <swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The compiler has special knowledge of Optional<Wrapped>, 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


(Seth Friedman) #3

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If anyone
could let me know of any good resources you know of, that would be great.
I'm sure this would also be of use to people in my boat that want to help
but don't know how to start.

Thanks,
Seth

···

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> wrote:

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 < > swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The compiler
has special knowledge of Optional<Wrapped>, 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


(Jordan Rose) #4

Hi, Seth. Sorry for not getting back to you sooner! I don't think we have anything exactly like this, but there's sort of a sequence diagram in Chris and Joe's talk at the LLVM conference, "Swift's High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing to a .o file)

…with the last two handled pretty much completely by LLVM <http://llvm.org/> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals <http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully better), which lays out the major concepts in each library. As it is we have various concepts that are documented very well, either in docs/ or in header comments, and others which are just arcane knowledge in the heads of the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the website lists a handful of ways to get involved; another one we're still bringing up is issues with the "StarterBug" label in JIRA. These are intended to be bugs that a newcomer could use as a goal-oriented way to learn about one part of the project.

Of course, we're happy to answer any specific questions you might have (and this list is probably the right place for them). It's the general ones that are hard. :slight_smile:

Jordan

···

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in contributing to the project, but given that I don't have a ton of experience with compilers, I'm having a really hard time following the flow of the program. I understand that the high level flow is lexing, parsing, sema, and building the AST. However, tracing through the actual functions in the compiler prove much more difficult due to the amount of indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If anyone could let me know of any good resources you know of, that would be great. I'm sure this would also be of use to people in my boat that want to help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
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 <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The compiler has special knowledge of Optional<Wrapped>, 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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(Seth Friedman) #5

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this is
just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to understand
and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would make
a great start to a Swift internals manual (which I agree with you would be
a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth

···

On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we have
anything exactly like this, but there's *sort* of a sequence diagram in
Chris and Joe's talk at the LLVM conference, "Swift's High-Level IR
<https://youtu.be/Ntj8ab-5cvE>". I'd say it looks something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing to a
.o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the website
lists a handful of ways to get involved; another one we're still bringing
up is issues with the "StarterBug" label in JIRA. These are intended to be
bugs that a newcomer could use as a goal-oriented way to learn about one
part of the project.

Of course, we're happy to answer any specific questions you might have
(and this list is probably the right place for them). It's the general ones
that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> wrote:

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 < >> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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


(Seth Friedman) #6

Changing the subject of this thread since it's now an entirely different
question than what I originally asked. Hopefully this will result in better
visibility in getting an answer as well.

Thanks,
Seth

···

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this is
just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would
make a great start to a Swift internals manual (which I agree with you
would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we have
anything exactly like this, but there's *sort* of a sequence diagram in
Chris and Joe's talk at the LLVM conference, "Swift's High-Level IR
<https://youtu.be/Ntj8ab-5cvE>". I'd say it looks something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing to
a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the website
lists a handful of ways to get involved; another one we're still bringing
up is issues with the "StarterBug" label in JIRA. These are intended to be
bugs that a newcomer could use as a goal-oriented way to learn about one
part of the project.

Of course, we're happy to answer any specific questions you might have
(and this list is probably the right place for them). It's the general ones
that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> wrote:

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 < >>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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


(Seth Friedman) #7

Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

···

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com> wrote:

Changing the subject of this thread since it's now an entirely different
question than what I originally asked. Hopefully this will result in better
visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this is
just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would
make a great start to a Swift internals manual (which I agree with you
would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> >> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we
have anything exactly like this, but there's *sort* of a sequence
diagram in Chris and Joe's talk at the LLVM conference, "Swift's
High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks
something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing to
a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the
website lists a handful of ways to get involved; another one we're still
bringing up is issues with the "StarterBug" label in JIRA. These are
intended to be bugs that a newcomer could use as a goal-oriented way to
learn about one part of the project.

Of course, we're happy to answer any specific questions you might have
(and this list is probably the right place for them). It's the general ones
that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> >>> wrote:

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 < >>>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*


(Svein Halvor Halvorsen) #8

Can't you just make your SuperInt conform to IntergerLiteralConvertible and
initialise it like so:

let superIntExample: SuperInt = 100

sv.

···

2016-01-18 1:13 GMT+01:00 Seth Friedman via swift-dev <swift-dev@swift.org>:

Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com> wrote:

Changing the subject of this thread since it's now an entirely different
question than what I originally asked. Hopefully this will result in better
visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this
is just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would
make a great start to a Swift internals manual (which I agree with you
would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> >>> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we
have anything exactly like this, but there's *sort* of a sequence
diagram in Chris and Joe's talk at the LLVM conference, "Swift's
High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks
something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing
to a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the
website lists a handful of ways to get involved; another one we're still
bringing up is issues with the "StarterBug" label in JIRA. These are
intended to be bugs that a newcomer could use as a goal-oriented way to
learn about one part of the project.

Of course, we're happy to answer any specific questions you might have
(and this list is probably the right place for them). It's the general ones
that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> >>>> wrote:

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 < >>>>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

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


(Seth Friedman) #9

Sure, but this is a completely arbitrary, simple example designed to
illustrate how to add new syntax to Swift. Conforming to
IntegerLiteralConvertible would defeat the point of the exercise.

Thanks,
Seth

···

On Mon, Jan 18, 2016 at 8:55 AM Svein Halvor Halvorsen < svein.h@lvor.halvorsen.cc> wrote:

Can't you just make your SuperInt conform to IntergerLiteralConvertible
and initialise it like so:

let superIntExample: SuperInt = 100

sv.

2016-01-18 1:13 GMT+01:00 Seth Friedman via swift-dev <swift-dev@swift.org
>:

Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com> wrote:

Changing the subject of this thread since it's now an entirely different
question than what I originally asked. Hopefully this will result in better
visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this
is just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would
make a great start to a Swift internals manual (which I agree with you
would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> >>>> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we
have anything exactly like this, but there's *sort* of a sequence
diagram in Chris and Joe's talk at the LLVM conference, "Swift's
High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks
something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing
to a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the
website lists a handful of ways to get involved; another one we're still
bringing up is issues with the "StarterBug" label in JIRA. These are
intended to be bugs that a newcomer could use as a goal-oriented way to
learn about one part of the project.

Of course, we're happy to answer any specific questions you might have
(and this list is probably the right place for them). It's the general ones
that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> >>>>> wrote:

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 < >>>>>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

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


(Svein Halvor Halvorsen) #10

So you want a completely new kind of literal, that is neither a string,
integer, float, etc.
Kinda like the special array and dictionary literals?

···

2016-01-18 18:10 GMT+01:00 Seth Friedman <sethfri@gmail.com>:

Sure, but this is a completely arbitrary, simple example designed to
illustrate how to add new syntax to Swift. Conforming to
IntegerLiteralConvertible would defeat the point of the exercise.

Thanks,
Seth
On Mon, Jan 18, 2016 at 8:55 AM Svein Halvor Halvorsen < > svein.h@lvor.halvorsen.cc> wrote:

Can't you just make your SuperInt conform to IntergerLiteralConvertible
and initialise it like so:

let superIntExample: SuperInt = 100

sv.

2016-01-18 1:13 GMT+01:00 Seth Friedman via swift-dev <
swift-dev@swift.org>:

Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com> >>> wrote:

Changing the subject of this thread since it's now an entirely
different question than what I originally asked. Hopefully this will result
in better visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> >>>> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this
is just a wild example that would help me better understand parts of the
compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would
make a great start to a Swift internals manual (which I agree with you
would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> >>>>> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we
have anything exactly like this, but there's *sort* of a sequence
diagram in Chris and Joe's talk at the LLVM conference, "Swift's
High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks
something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing
to a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully
better), which lays out the major concepts in each library. As it is we
have various concepts that are documented very well, either in docs/ or in
header comments, and others which are just arcane knowledge in the heads of
the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the
website lists a handful of ways to get involved; another one we're still
bringing up is issues with the "StarterBug" label in JIRA. These are
intended to be bugs that a newcomer could use as a goal-oriented way to
learn about one part of the project.

Of course, we're happy to answer any specific questions you might
have (and this list is probably the right place for them). It's the general
ones that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> >>>>>> wrote:

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 < >>>>>>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

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


(Seth Friedman) #11

Exactly. I'm just trying to understand how someone would go about adding
new syntax to the language

···

On Mon, Jan 18, 2016 at 9:13 AM Svein Halvor Halvorsen < svein.h@lvor.halvorsen.cc> wrote:

So you want a completely new kind of literal, that is neither a string,
integer, float, etc.
Kinda like the special array and dictionary literals?

2016-01-18 18:10 GMT+01:00 Seth Friedman <sethfri@gmail.com>:

Sure, but this is a completely arbitrary, simple example designed to
illustrate how to add new syntax to Swift. Conforming to
IntegerLiteralConvertible would defeat the point of the exercise.

Thanks,
Seth
On Mon, Jan 18, 2016 at 8:55 AM Svein Halvor Halvorsen < >> svein.h@lvor.halvorsen.cc> wrote:

Can't you just make your SuperInt conform to IntergerLiteralConvertible
and initialise it like so:

let superIntExample: SuperInt = 100

sv.

2016-01-18 1:13 GMT+01:00 Seth Friedman via swift-dev <
swift-dev@swift.org>:

Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com> >>>> wrote:

Changing the subject of this thread since it's now an entirely
different question than what I originally asked. Hopefully this will result
in better visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com> >>>>> wrote:

Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that
this is just a wild example that would help me better understand parts of
the compiler I'm interested in rather than any sort of proposal for the
language.

Let's say I have a type called SuperInt that has some cool integer
operations that would be applicable and useful to everyone writing Swift.
It's a given that this makes sense to be in the Swift language, and people
are going to be using it so often that it makes sense to create a new
literal syntax for this type. I'd like users to be able to instantiate a
SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not
something that's already in Swift. In this example, my SuperInt would be
instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to
understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it
would make a great start to a Swift internals manual (which I agree with
you would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com> >>>>>> wrote:

Hi, Seth. Sorry for not getting back to you sooner! I don't think we
have anything exactly like this, but there's *sort* of a sequence
diagram in Chris and Joe's talk at the LLVM conference, "Swift's
High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks
something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and
writing to a .o file)

…with the last two handled pretty much completely by LLVM
<http://llvm.org> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals
<http://clang.llvm.org/docs/InternalsManual.html>" manual
(hopefully better), which lays out the major concepts in each library. As
it is we have various concepts that are documented very well, either in
docs/ or in header comments, and others which are just arcane knowledge in
the heads of the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the
website lists a handful of ways to get involved; another one we're still
bringing up is issues with the "StarterBug" label in JIRA. These are
intended to be bugs that a newcomer could use as a goal-oriented way to
learn about one part of the project.

Of course, we're happy to answer any specific questions you might
have (and this list is probably the right place for them). It's the general
ones that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in
contributing to the project, but given that I don't have a ton of
experience with compilers, I'm having a really hard time following the flow
of the program. I understand that the high level flow is lexing, parsing,
sema, and building the AST. However, tracing through the actual functions
in the compiler prove much more difficult due to the amount of
indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If
anyone could let me know of any good resources you know of, that would be
great. I'm sure this would also be of use to people in my boat that want to
help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com> >>>>>>> wrote:

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 < >>>>>>>> swift-dev@swift.org> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The
compiler has special knowledge of Optional<Wrapped>, 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

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

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


(Douglas Gregor) #12

Exactly. I'm just trying to understand how someone would go about adding new syntax to the language

It’s a bunch of steps… roughly:

1) Teach the parser to recognize your syntax in one of the parseExpr* routines
2) Add a new node kind to include/swift/AST/ExprNodes.def and add its implementation in include/swift/AST/Expr.h. If you build, you’ll get warnings or errors for all of the places in the compiler that need to be updated, which includes...
3) Add type checking support (lib/Sema/CS*.cpp), mapping to a completely type-checked expression
4) Add SILGen support (lib/SILGen/SILGenRValue.cpp) to map your expression down to SIL

  - Doug

···

On Jan 18, 2016, at 9:18 AM, Seth Friedman via swift-dev <swift-dev@swift.org> wrote:

On Mon, Jan 18, 2016 at 9:13 AM Svein Halvor Halvorsen <svein.h@lvor.halvorsen.cc <mailto:svein.h@lvor.halvorsen.cc>> wrote:
So you want a completely new kind of literal, that is neither a string, integer, float, etc.
Kinda like the special array and dictionary literals?

2016-01-18 18:10 GMT+01:00 Seth Friedman <sethfri@gmail.com <mailto:sethfri@gmail.com>>:
Sure, but this is a completely arbitrary, simple example designed to illustrate how to add new syntax to Swift. Conforming to IntegerLiteralConvertible would defeat the point of the exercise.

Thanks,
Seth
On Mon, Jan 18, 2016 at 8:55 AM Svein Halvor Halvorsen <svein.h@lvor.halvorsen.cc <mailto:svein.h@lvor.halvorsen.cc>> wrote:
Can't you just make your SuperInt conform to IntergerLiteralConvertible and initialise it like so:

let superIntExample: SuperInt = 100

sv.

2016-01-18 1:13 GMT+01:00 Seth Friedman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>>:
Created SR-569 <https://bugs.swift.org/browse/SR-569> to track this

Thanks!

Seth

On Sun, Jan 10, 2016 at 4:18 PM, Seth Friedman <sethfri@gmail.com <mailto:sethfri@gmail.com>> wrote:
Changing the subject of this thread since it's now an entirely different question than what I originally asked. Hopefully this will result in better visibility in getting an answer as well.

Thanks,
Seth

On Sun, Jan 10, 2016 at 4:16 PM Seth Friedman <sethfri@gmail.com <mailto:sethfri@gmail.com>> wrote:
Thanks Jordan!

Here's a specific flow I'm interested in understanding. Note that this is just a wild example that would help me better understand parts of the compiler I'm interested in rather than any sort of proposal for the language.

Let's say I have a type called SuperInt that has some cool integer operations that would be applicable and useful to everyone writing Swift. It's a given that this makes sense to be in the Swift language, and people are going to be using it so often that it makes sense to create a new literal syntax for this type. I'd like users to be able to instantiate a SuperInt with the following:

let superIntExample = %^100^%

Crazy syntax for a crazy example, but I wanted to make sure it's not something that's already in Swift. In this example, my SuperInt would be instantiated with a value of 100.

I'd like to know the parts of the Swift compiler I would need to understand and change to implement this new type with its new syntax.

I really this question requires a lengthy answer, but I think it would make a great start to a Swift internals manual (which I agree with you would be a fantastic idea).

Anyone's help would be much appreciated!

Thanks,
Seth
On Fri, Dec 18, 2015 at 5:25 PM Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
Hi, Seth. Sorry for not getting back to you sooner! I don't think we have anything exactly like this, but there's sort of a sequence diagram in Chris and Joe's talk at the LLVM conference, "Swift's High-Level IR <https://youtu.be/Ntj8ab-5cvE>". I'd say it looks something like this:

1. Parsing
2. Semantic analysis, including type-checking
3. SIL generation
4. Mandatory SIL passes
5. SIL optimization
6. LLVM IR generation
7. LLVM optimization
8. LLVM output (usually including machine code generation and writing to a .o file)

…with the last two handled pretty much completely by LLVM <http://llvm.org/> itself, and not customized by Swift.

We probably ought to have something like Clang's "Internals <http://clang.llvm.org/docs/InternalsManual.html>" manual (hopefully better), which lays out the major concepts in each library. As it is we have various concepts that are documented very well, either in docs/ or in header comments, and others which are just arcane knowledge in the heads of the implementers. This is not a good thing.

The "Contributing <https://swift.org/contributing/>" page on the website lists a handful of ways to get involved; another one we're still bringing up is issues with the "StarterBug" label in JIRA. These are intended to be bugs that a newcomer could use as a goal-oriented way to learn about one part of the project.

Of course, we're happy to answer any specific questions you might have (and this list is probably the right place for them). It's the general ones that are hard. :slight_smile:

Jordan

On Dec 16, 2015, at 2:36, Seth Friedman <sethfri@gmail.com <mailto:sethfri@gmail.com>> wrote:

Thanks Jordan!

Another question if anyone has some time: I'm really interested in contributing to the project, but given that I don't have a ton of experience with compilers, I'm having a really hard time following the flow of the program. I understand that the high level flow is lexing, parsing, sema, and building the AST. However, tracing through the actual functions in the compiler prove much more difficult due to the amount of indirection/metaprogramming.

Are there any sort of sequence diagrams that I haven't found yet? If anyone could let me know of any good resources you know of, that would be great. I'm sure this would also be of use to people in my boat that want to help but don't know how to start.

Thanks,
Seth

On Tue, Dec 8, 2015 at 9:04 PM Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:
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 <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Hi all,

In Optional.swift in the stdlib, there's a comment that says "The compiler has special knowledge of Optional<Wrapped>, 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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

--
Seth Friedman
Software Development Engineer II
Amazon.com

_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto: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