But the implementation of expression parsing still does not propagate the code
completion bits because it uses NullablePtr for results.
Swift SVN r7425
line after a var decl with initializer would complete based on the initializer
expression.
These are technically valid completions, but confusing. Now this suggests
unqualified completions.
Swift SVN r7188
integration
Motivation: libIDE clients should be simple, and they should not have to
translate token-based SourceRanges to character locations.
This also allows us to remove the dependency of DiagnosticConsumer on the
Lexer. Now the DiagnosticEngine translates the diagnostics to CharSourceRanges
and passes character-based ranges to the DiagnosticConsumer.
Swift SVN r7173
Decouple splitting an interpolated string to segments, from encoding the string segments.
This allows us to tokenize or re-lex a string literal without having to allocate memory for
encoding the string segments when we don't need them encoded.
Swift SVN r6940
-Parse the expression using a begin/end state sub-Lexer instead of a general StringRef Lexer
-Introduce a Lexer constructor accepting a BufferID and a range inside the buffer, and use it for swift::tokenize.
Swift SVN r6938
We should probably accept this, or at least some variation of it, but
erroring out is still a strict improvement over crashing. However, this
does cause a regression for some properly typed recursive closures, like
'fib' in expressions.swift.
<rdar://problem/14583952> tracks the correct solution.
Swift SVN r6730
Currently, this includes cases where a variable of the same name is
available in an outer scope. We can change this later if desired.
<rdar://problem/14566648>
Swift SVN r6729
This makes long literals like 1_000_000_000 or 0x7FFF_FFFF_FFFF_FFFF much easier to read, and has precedent in Perl, OCaml, Python, Ruby, Rust, ... Fixes <rdar://problem/14247571>.
Swift SVN r6681
In this syntax, the closure signature (when present) is placed within
the braces and the 'in' keyword separates it from the body of the
closure, e.g.,
magic(42, { (x : Int, y : Int) -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
When types are omitted from the parameter list, one can also drop the
parentheses, e.g.,
magic(42, { x, y -> Bool in
print("Comparing \(x) to \(y).\n")
return y < x
})
The parsing is inefficient and recovers poorly (in part because 'in'
is a contextual keyword rather than a real keyword), but it should
handle the full grammar. A number of tests, along with the whitepaper
and related rational documents, still need to be updated. Still, this
is the core of <rdar://problem/14004323>.
Swift SVN r6105
When the name of a generic type is referenced, without any generic
arguments, within the definition of a generic type (or extensions of
that generic type), use the generic arguments provided by that
context. Thus, within the definition of X<T> below, one can simply use
'X' as a shorthand for 'X<T>':
class X<T> {
func swap(other : X) { /* ... */ } // same as "func swap(other : X<T>)"
}
This resolution provides essentially the same behavior as the
injected class name does in C++. Note that this rule overrides any
inference rules, such that (for example) the following is ill-formed
rather than inferring the generic arguments of 'X':
class X<T> {
func foo() {
var xi : X<Int> = X()
}
}
Note that name binding has changed slightly: when unqualified lookup
finds a type declaration within a nominal type, it is now treated as
a DeclRefExpr (or overloaded variant thereof) rather than as a member
access with an implicit 'this'.
Fixes <rdar://problem/14078437>.
Swift SVN r6049
When we are interpreting escape sequences in the lexer, we copy the string
literal bytes to ASTContext instead of storing a pointer to the source buffer.
But then we used to try to get a source location for that string in the heap,
which is not a valid source buffer. It succeeds during parsing, but breaks
when we try to print a diagnostic using this location.
Added a verifier check for this.
Also added a real source range for StringLiteralExpr, instead of a source range
with begin == end, produced from the beginning location.
Swift SVN r5961
