Skip to content

[Diagnostics] Diagnose extraneous argument(s) via fixes #27728

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Oct 18, 2019

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Oct 16, 2019

If there are more arguments than parameters, let's fix this by
ignoring (if possible) or removing extraneous arguments. Ignored
arguments could default to Any (be marked as a "hole") if they
don't get any other contextual type.

This also extends existing single extra argument to cover multiple
extraneous arguments.

Note that some of the diagnostics here regressed because of current
solver limitations, especially for name shadowing since it's impossible
to get access to outer overloads. I'm going to follow up with a
resolveDeclRefExpr refactoring to fix that problem.

Resolves: rdar://problem/23948031
Resolves: rdar://problem/38827329
Resolves: rdar://problem/43351035
Resolves: rdar://problem/43848865
Resolves: rdar://problem/50927327
Resolves: rdar://problem/55254498

xedin added 22 commits October 16, 2019 10:19
If there are more arguments than parameters, let's fix this by
ignoring (if possible) or removing extraneous arguments. Ignored
arguments could default to `Any` if they don't get any other
contextual type.
…CallArguments`

Helps diagnostics to avoid digging this type out from locator.
Most importantly - index, label, and type, which are useful for
diagnostics.
…tuple splat

Before recording a generic "extraneous arguments" fix, let's check
whether this is a tuple splat with a single parameter.
…missing/extra arguments

This makes it possible to find all of the problems related to a given
set of arguments and fix/score each overload candidate correctly.
In situations like:

```swift
func foo<T>(x: T) {}
foo(a; 0, x: 42)
```

Let's not try to fix call to `foo` as a tuple splat because match is
in a middle of the argument list, it should be considered a regular
extraneous argument instead.
Let's cover at least the most common cases - min/max. Fixing the
problem requires refactoring of `resolveDeclRefExpr`.
@xedin xedin requested review from DougGregor and hborla October 16, 2019 18:56
@xedin
Copy link
Contributor Author

xedin commented Oct 16, 2019

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Oct 16, 2019

@swift-ci please smoke test Linux platform

@xedin
Copy link
Contributor Author

xedin commented Oct 18, 2019

@swift-ci please smoke test

@xedin xedin merged commit 8d05192 into swiftlang:master Oct 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants