Use tok::NUM_TOKENS instead. tok::unknown can easily appear in source code.
For instance `skipUntil(tok::eof)` did not work as expected, because that was
`skipUntil(tok::eof, tok::unknown)` hence does stop at error tokens such as
`0xG` (invalid hex number literal).
Revert 2abc92bbb5, since that was
accidental side-effect of 45118037cc.
Forward references are not allowed actually.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
"California": [
"population": 37_000_000,
"cities": ["Los Angeles", "San Diego", "San Jose"],
],
"Oregon": [
"population": 4_000_000,
"cities": ["Portland", "Salem", "Eugene"],
]
]
Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.
In various cases where we had global operators for non-generic
concrete types (such as String + String), move those operators into
the type. This should not affect the sources, but makes the exposition
of the library cleaner.
Plus, it's a good test for the compiler, which uncovered a few issues
where the compiler was coupled with the library.
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
Mostly this was just returning the ParserStatus bits that we got from
parseExprList from parseExprStringLiteral. The rest was just cleaning up
places that didn't handle EOF very well, which is important here because
the code completion token is buried in the string literal, so the
primary lexer will walk past it.
rdar://problem/17101944
When the LHS is an lvalue/assignable tuple and there is no leading
sequence of binary expressions.
It's a bit hacky right now since we don't have a good way to
differentiate general pattern completions from builtin operators.
rdar://problem/23209683
Global variables from the same source file are more like locals when
writing top-level code, particularly in Playgrounds. Other declarations
(types, global functions, etc.) are unaffected.
rdar://problem/22329905
Swift SVN r31992
They had already diverged even before my last commit. Let's not have that
happen again!
This re-fixes code completion for bindings declared in top-level guard
statements.
More rdar://problem/21928533
Swift SVN r30525
We always expect to get a pattern, but in top-level completion we forgot
to build the fallback AnyPattern to go in the error result.
rdar://21661308
Swift SVN r30078
First, fix a case of type checking an expression twice, which is against
the design of the type checker. We hit this because we can type check
the "context" in
let x = foo.#^COMPLETE^#
and then type check the "parsed expression", which is contained in the
context here.
Second, make the hack from rdar://20738314 more robust so that if we
*do* double typecheck for some reason we won't just choke on an
AutoClosureExpr. I filed rdar://21466394 to audit for other cases of
double typechecking and remove this hack.
Fixes rdar://21346928
Swift SVN r29527
We have an unreachable in the visitor for auto closures, so avoid
visiting it. It would be great to have a clearer picture of what needs
to happen for AutoClosure vs ClosureExpr. It's hard to tell exactly
where AutoClosure is supposed to be handled if at all.
Swift SVN r29037
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
if there's no parameter API name. This is for display purposes only.
Update all relevant tests accordingly.
This addresses <rdar://problem/16768768>.
For example:
class X {
func f(a: Int, b: Int) { }
}
Would previously display like this in code completion in Xcode:
f(<#Int#>, b: <#Int#>)
The local parameter name, while not API, often still conveys meaning
to the user. So it's now included like this:
f(<#a: Int#>, b: <#Int#>)
Swift SVN r18403
