The range operators (".." and someday "...") make constructs like .24...42
ambiguous. Therefore, we will enforce that programmers either place digits
on both sides of the decimal place, or use of exponent based notation.
Swift SVN r3989
If we're going to import C/C++/ObjC code, we ought to "just work" with
their escape patterns when reasonable. (No error-prone octal escapes or
trigraph support). Also, update LangRef to document what the escapes do.
This patch DOES fix a bug with lexing operators in the case of (already
warned about) embedded NUL bytes within a source file.
This patch DOES NOT change what we consider to be valid whitespace in
the language.
Swift SVN r3970
All of these sections need more organization and prioritization. We'll get there.
Hint: use Emacs' table.el when editing this monster table. You'll be happier that way.
Swift SVN r3954
APFloat's parser gives us the parsing for free. Unlike C99 we require at least one digit on both sides of the hexadecimal point in order to allow '0x1.method()' expressions, similar to Dave's proposed change to float lexing. Also, we were requiring a sign after 'e' in the exponent, which is inconsistent with C, C++, and the Java regex we claim to follow, so I made the exponent sign optional.
Swift SVN r3940
Add a mangling for 'block converter' functions and for [objc_block] function types. [objc_block] types also need their own HeapTypeInfo representation that uses ObjC retain/release. When we see a BridgeToBlockExpr, feed the function pointer and context from the Swift closure to the external conversion function and hope we get a block back.
Swift SVN r3899
Not all of us save email forever, nor is a long email thread the best
way to track our current thinking. This document drops the humorous but
ultimately strawman Unicode proposals.
Swift SVN r3885
In Swift the "in" keyword is really a form of punctuation, and highly
context specific punctuation at that. It never begins a statement, nor
does the grammar require it be statement keyword. The grammar also
doesn't use it outside of for-each loops, and its use within a for-each
loop is highly unambiguous.
Thanks to Chris for the performance related feedback. This improves the
performance of getter/setter parsing as well.
Swift SVN r3880
and non-deallocating destructors and allocating/non-allocating
constructors.
Non-deallocating destructors might not play well with ObjC
classes; we might have to limit them to pure-swift hierarchies.
No functionality change except that I decided to not force
destructors to have internal linkage unconditionally.
Swift SVN r3814
Previously, we were mangling [objc] class types as swift
classes (using the defining component in the mangling) and
imported class types as class types with empty contexts.
This could create an inconsistency between components which
disagree about whether an ObjC class is defined in swift or
not; this will not do. Also, an empty context creates an
invalid mangling.
Swift SVN r3812
Archetypes and projected existentials have the type %swift.opaque* and not i8*, so I need a corresponding SIL type to be able to model the ProjectExistential operation. We might also end up needing the builtin type for other low-level things down the line.
Swift SVN r3793
Conform to IRGen's curried calling convention by emitting param patterns in reverse order, with the indirect return argument (if any) coming first.
Swift SVN r3777
Consistently use "existential container" to refer to the protocol-typed container object and "concrete value" to refer to the subobject owned by the existential container. Simplify the example a bit by removing the extraneous function call.
Swift SVN r3711
Change the name of the implementation detail underlying protocol and protocol composition types to "existential container" while replacing references to "existential type" with "protocol or protocol composition type".
Swift SVN r3709
Loadable types are passed and returned at +1. Address-only arguments are passed by reference and callee-copied. Address-only return values are passed as an implicit argument to caller-owned uninitialized memory and are callee-initialized.
Swift SVN r3525
Also repaint the "existential" bikeshed since there's a loud preference for talking about existentials as existentials within the implementation.
Swift SVN r3523
Describe a `ref_element_addr` instruction for extracting elements from reference types and a `generalize` instruction for representation conversion of generic values.
Swift SVN r3432
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
