Previously, the Parser and BranchStmt typedef-ed ExprStmtOrDecl as a pointer union. Using typedef made the objects compatible, but did not allow us to extend the type with helper methods, such as getSourceRange(), which is something you can get on all of the AST objects. This patch introduces ASTNode that subclasses from PointerUnion and is used by both parser and BranchStmt.
Swift SVN r9971
This little "find the context where the generic parameters could be"
idiom was copy-pasted in a few places, which is ugly. And if we get
generic subscripts (or some other generic value decl), we'll be sorry.
Swift SVN r9927
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
This addresses the bulk of <rdar://problem/15344950>, which involes us
not being able to find local variable declarations in expressions when
the parser didn't pre-bind them for us.
The fix to name lookup itself insures that a case such as
case (var a, a)
doesn't allow the second 'a' to find the first.
Swift SVN r9858
Similar to the T -> U? conversion, allow T? to be converted to U? through a bind-convert-inject chain. Naively adding this conversion creates ambiguities in the type checker, opening up multiple paths to the same solution in certain cases, so add a a special case to the solver that avoids introducing the conversion if a solution is already available by other means. (Doug figured out that part; thanks Doug!)
This still introduces a regression in test/Constraints/optional.swift, rendering a call ambiguous when overloaded on argument types. <rdar://problem/15367036>
Swift SVN r9857
All other interface types for type declarations were already
metatypes, as they should be; this oddity crept in. Kill it before it
causes more confusion.
Swift SVN r9826
This required moving a gross hack from the old archetype-based
type-opening code over to the new, generic type parameter-based
type-opening code. We need the ability to build conformances for types
involving type variables to address this case properly.
Swift SVN r9821
implicit, we should not verify source locations with this patch.
LLDB creates ASTs that contain some pieces of AST that came from the parser,
and some other pieces that were synthesized. AST Verifier complains about this
strange mix while checking source ranges.
rdar://15320934
Swift SVN r9819
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
And, properly treat imports as per-file: when looking up decls through the
TU module, don't pick up every other source file's imports.
This implements our resolution rules:
1. Check the current source file.
2. Check the current module.
3. Check imported modules.
Currently, "import Foo" is treated as a file-private import and
"@reexported import Foo" is treated as a public /and/ module-wide import.
This further suggests that access control is the right tool for re-export
control:
(private) import Foo // current file only
package import Foo // whole module
public import Foo // whole world
Swift SVN r9682
This allows us to say roughly what generic type we want without having
to specify all of the details, e.g.,
var dict : Dictionary = ["Hello" : 1, "World" : 2]
// infers Dictionary<String, Int>
Fixes <rdar://problem/14238814>.
Swift SVN r9678
Eliminate the annoying, rarely-firing "while converting 'var' initial
value to declared type" note. We'll eventually have better ways to
deal with this. Otherwise, no functionality change.
Swift SVN r9677
The keying and auto-incrementing logic need some patching up to correctly track and build negative IntegerLiteralExprs. Fixes <rdar://problem/15315340>.
Swift SVN r9676
Anywhere that assumes a single input file per TU now has to do so explicitly.
Parsing still puts all files in a single SourceFile instance; that's next on
the list.
There are a lot of issues still to go, but the design is now in place.
Swift SVN r9669
The operator lookup cache already lived in SourceFile, but we need to be
able to look up operators on a per-SourceFile basis. Different files can
have different imports. The interface previously distinguished between
"no operator found" and "error", but none of the call sites were making
use of this distinction, and indeed some were misusing the return value
(Optional<SomeOperatorDecl *>). Now the lookup functions just return
operator decl pointers, which may be null.
Swift SVN r9668
