We don't sink open_existential_* instructions, because there may be some instructions depending on them, e.g. ametatype_inst, etc. But this kind of dependency cannot be expressed in SIL as a use yet. As a result, sinking open_existential may break the invariant that these instructions should dominate their uses.
When we see a string literal used to initializer a Selector, and that
string literal names the selector for the getter or setter of an
Objective-C property, suggest #selector(getter: ...) or
This completes SE-0064. Big thanks for Alex Hoppen (@ahoppen) for his
contributions here.
Implement basic code completion support for #selector with property
getters/setters. The vast majority of this implementation comes from
Alex Hoppen (@ahoppen), with only a handful of my own tweaks. Alex has
more interesting ideas on improving this that I wasn't quite ready to
commit to, so this is more basic than the overall goal.
This was easy with a bit of refactoring, but eventually I'd love to
converge override checking and witness checking logic a bit more.
Fixes <rdar://26183366>.
Implements almost all of SE-0067. There are a few outstanding features; this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
which require additions to the Builtin module. I can probably figure out how to do these, but I haven't had a chance to do so yet. Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes the existing tests locally (with the included changes). I'm working on additional tests for the new features.
Implements the core functionality of SE-0064 / SR-1239, which
introduces support for accessing the Objective-C selectors of the
getter and setter of an @objc property via #selector(getter:
propertyName) and #selector(setter: propertyName).
Introduce a bunch of QoI around mistakes using #selector to refer to a
property without the "getter:" or "setter:", using Fix-Its to help the
user get it right. There is more to do in this area, still, but we
have an end-to-end feature working.
Much of the implementation and nearly all of the test cases are from
Alex Hoppen (@ahoppen). I've done a bit of refactoring, simplified the
AST representation, and replaced Alex's custom
expression-to-declaration logic with an extension to the constraint
solver. The last bit might be short-lived, based on swift-evolution
PR280, which narrows the syntax of #selector considerably.
While we could bridge 'NSRange' to 'NSRange' and 'NSRange?' to
'NSValue * _Nullable', that (a) would be confusing, and (b) isn't
actually implemented at the moment. Fix my mistake in 477933b to
start accepting these.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
Previously, we were using backtrace_symbol and then parsing/modifying its
output. By just using dladdr directly, we have a cleaner and more robust
solution.
rdar://25064742
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
It's like LLVM's MergeFunctions pass, except that it can also merge functions which differ by some constants.
The intention is to merge specialized functions which only differ by metadata lookups. But it can also merge other types of functions.
It gives ~7% code size reducation for the stdlib.
There are still some open TODOs, e.g. to share common code with LLVM's MergeFunctions pass (currently much code is just copied).
- Remove stray newline
- Adjust wording when recommending backticks for a keyword identifier
- Provide fix-it when encountering a keyword as an identifier
rdar://problem/25761380
This at least emits notes when someone overrides something but
gets the types a little wrong (more than just mismatched optionals,
as handled in d669d152).
Part of rdar://problem/26183575
Judging from history, the original tests appear to just be attempts to
flesh out test coverage rather than specific regression tests, and the
features in question are well-covered by other tests.
We want inputs for function names to follow SE-0021 with the exception
that a function with no arguments is spelled `foo()` instead of `foo`,
because we have no type to disambiguate with and it's not ambiguous with
a call in this context.
Internally, we use a filter name without underscores because we don't
want to introduce spurious matches to the `_` character which might be
part of identifiers.
For now, continue to accept the old names to ease the transition.
rdar://problem/24350800
The filter name of a function should match the spelling of the function
name according to the language except that we don't insert _ for unnamed
parameters because underscores are legal inside identifiers and we don't
want to introduce spurious matches (also, we keep the () on a
parameterless function for disambiguation).
rdar://problem/26118915
