We generally don't want to override unavailable methods. We already
filter out unavailable decls when completing values, but that's in a
separate visible decl consumer.
rdar://problem/25058233
I wouldn't normally do a bulk reformat like this, but in this case I
think the benefits of consistently formatting the file outweigh the
costs, because (a) there is no substantive history to this file yet in
the swift repo, and (b) there are widespread and *distracting* style
differences like brace-placement and spaces before opening (.
Eventually all three of these should go away. I want to keep
ConstString around for now, because it makes it easier to audit where
you should consider using a StringRef. I'm hoping only a few of those
actually need std::string.
Except for nil literals, we don't want to look at the optional itself,
since the typechecker would implicitly look to the underlying type.
rdar://problem/24707210
We don't want to prioritize the type name for protocols, since they
can't be used (generally) to construct an instance of the type. Ideally
we would prioritize types that conform to the protocol.
For rdar://problem/24873625
I want to start using this for other things like function types and
attributes, so rename it to reflect the new scope. I'm not really happy
with "PrintStructureKind", etc. but haven't come up with anything
better so far.
Code like this:
public struct MyStruct {
private typealias IntegerType = Int
private func Foo(i : IntegerType)
{
var a = Dictionary<String, IntegerType>()
a["hello"] = 123
print("a = \(a)")
print("i = \(i)")
print("done");
}
}
func main() {
let s = MyStruct();
s.Foo(123)
}
main()
Will crash if we set a breakpoint on the 'print("done")' line and expand the "a" variable due to the IntegerType not
making it into the Swift module since it is private. Then we try to create the Dictionary generic type with type
list that has only "String" in it and boom.
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
The current approach of visiting the param decl won't work when we want
to visit the parameters of function *types*, or when visiting tuple
elements (which aren't themselves decls).
rdar://problem/24292226
As the initial step, we remove any synthesized extensions requiring a tuple's conforming to nominals, which
never happens. This will remove multiple useless synthesized extensions for Dictionary.
We can have multiple printDeclPre callbacks pending (e.g top-level-code
decls), so use a vector to ensure we don't lose the earlier callbacks.
We also may end up calling printDeclPost without forcing the
corresponding printDeclPre first if the decl doesn't actually print
anything (e.g. an if-config statement when skipping those). So add a
wrapper callPrintDeclPost that can check for this and skip both
callbacks. In theory, we could handle this case by instead making all
ast nodes go through something like shouldPrint() and making an
invariant that something will be printed if and only if shouldPrint
returns true. However, that is not an obvious win, because it forces us
to walk all the first-level statements and decls inside a top-level-code
decl to determine if anything will be printed, and it also means we can
never make local decisions about whether something will be printed. For
now, I've chosen to maintain flexibility by recovering from unprinted
decls.
Finally, add a bunch of assertions to try to keep callbacks sane.
... for the fully annotated declarations. More substructure more better.
This has to go through a callback mechanism similar to printDeclLoc and
printDeclPre since it should be scheduled after both of those are
printed.
rdar://problem/24292226
