This reverts commit r22829, because reverting r22828 depends on it.
Reverting r22828 because it
was apparently causing an assertion on the bot:
Swift SVN r22830
Add a set of _preconditionOptionalHasValue intrinsics that merely test that an optional has a case. Emit an lvalue ForceValueExpr as a physical lvalue, first asserting the precondition then projecting out the Some payload.
Swift SVN r20188
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
This reverts commit r14488, since we're demoting 'type' back to a plain old identifier.
We could consider reallowing 'type' as a contextual keyword here, but from talking to Jordan he was OK with just reverting this functionality.
Swift SVN r14931
This means that we accept type attributes in a much broader
range of places where we previously required a <type>. <type>
was already a production that demanded a grammatically
unconstrained context because of all the possible continuations;
reducing the number of independent productions makes it easier
to choose one and thus not accidentally limit the range of
possible types parsed.
In particular, we want to be able to parse @unchecked T? pretty
much anywhere you can write a type.
Swift SVN r14912
Previously this was spelled "import typealias", and that spelling will
continue to be allowed (since someone may specifically be importing a
typealias and want that to match), but now that 'type' is a keyword,
"import type" is the right way to spell the generic "import any type"
scoped import.
Swift SVN r14488
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
1) Document that a series of '.' are operators.
2) '@' was dropped as an operator in r5019.
3) Move some commentary into the main documentation.
4) Better cross-referencing.
5) Tuple dot expressions use integer literals, not $identifiers.
Swift SVN r13694
- purge @inout from comments in the compiler except for places talking about
the SIL argument convention.
- change diagnostics to not refer to @inout
- Change the astprinter to print InoutType without the @, so it doesn't show
up in diagnostics or in closure argument types in code completion.
- Implement type parsing support for the new inout syntax (before we just
handled patterns).
- Switch the last couple of uses in the stdlib (in types) to inout.
- Various testcase updates (more to come).
Swift SVN r13564
There were a lot of instances of "Enumerable" that really should have
been changed already. Along the way, I also
* Moved the adaptor that allows a Stream to be used as a Sequence into
CompilerProtocols.swift; it's just an affordance to work around
temporary inability to express the Stream protocol properly
* Made a trivial simplification in Algorithm.swift
Swift SVN r11946
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
