Skip to content
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

Fix rendering of redefined Conversion error #8245

Merged
merged 19 commits into from
Nov 11, 2023
Merged

Conversation

radeusgd
Copy link
Member

@radeusgd radeusgd commented Nov 7, 2023

Pull Request Description

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@radeusgd radeusgd changed the title Fix ambiguous conversion definition Fix rendering of redefined Conversion in a module Nov 8, 2023
@radeusgd radeusgd changed the title Fix rendering of redefined Conversion in a module Fix rendering of redefined Conversion error Nov 8, 2023
s"Method overloads are not supported: ${targetType.map(_.name + ".").getOrElse("")}from " +
s"Ambiguous conversion: ${targetType.map(_.name + ".").getOrElse("")}from " +
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this error message may be clearer - conversions work a bit differently than method overloads - they do overload the from method, just with different types of that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if I accidentaly do something like this:

method x y = x + y
method x = x

Would the error message say "Ambiguous conversion" in that case as well? Isn't that misleading? What about trying to distinguish between those two cases - "Ambiguous conversion" VS "Method overload"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do distinguish these cases already.

The error message I have edited was only relevant for conversions, method overloads have a separate error class - I assume the error message for conversions was copy-pasted from overloads and that's why it used to say the same thing.

Copy link
Member Author

@radeusgd radeusgd Nov 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can see here a test verifying that the behaviour is exactly as you'd expect it to be.

the[InterpreterException] thrownBy eval(code) should have message
"Compilation aborted due to errors."
val diagnostics = consumeOut
diagnostics
.filterNot(isDiagnosticLine)
.toSet shouldEqual Set(
"Test:4:1: error: Method overloads are not supported: Nothing.foo is defined multiple times in this module."
)
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the above test was for member methods - so just to be comprehensive I added a test case like the one you mentioned:
2a37e54

@radeusgd radeusgd added the CI: No changelog needed Do not require a changelog entry for this PR. label Nov 8, 2023
@radeusgd radeusgd self-assigned this Nov 8, 2023
@radeusgd radeusgd marked this pull request as ready for review November 8, 2023 14:33
s"(Redefined (Conversion ${targetType.map(_.showCode() + ".").getOrElse("")}from $sourceType))"
s"(Redefined (Conversion ${targetType.map(_.showCode() + ".").getOrElse("")}from ${sourceType.showCode()}))"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small irrelevant fix - before printing the redefined conversion as code was leaking a lot of information by using toString instead of showCode for the sourceType. With that it is more compact and closer to what I think showCode is supposed to be.

@@ -32,6 +32,14 @@ protected static Context createDefaultContext() {
return context;
}

protected static Context createNonStrictContext(OutputStream out) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there only single usage of this method? Consider using createDefaultContext and apply the STRICT_ERRORS option to it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I apply options to a Context after it was constructed?

Comment on lines 89 to 90
// But we should still get the diagnostic!
MatcherAssert.assertThat(getStdOut(), Matchers.containsString("Unnamed:7:1: error: Ambiguous conversion: Foo.from Bar is defined multiple times in this module."));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to remove this check, because currently apparently the diagnostics are not reported at all in the non-strict mode.

e.g.

def runErrorHandling(
modules: List[Module]
): Unit = {
if (config.isStrictErrors) {
val diagnostics = modules.flatMap { module =>
val errors = gatherDiagnostics(module)
List((module, errors))
}
if (reportDiagnostics(diagnostics)) {
val count =
diagnostics.map(_._2.collect { case e: Error => e }.length).sum
val warnCount =
diagnostics.map(_._2.collect { case e: Warning => e }.length).sum
context.getErr.println(
s"Aborting due to ${count} errors and ${warnCount} warnings."
)
throw new CompilationAbortedException
}
}
}

cc: @JaroslavTulach @hubertp is this preferred for some reason? Do we not report the diagnostics, because non-strict mode is essentially interactive mode and these error messages are supposed to reach the IDE through 'other means' (i.e. errors baked in the IR)? Or is this just an oversight?

My intuition is that actually logging these kinds of diagnostics may make it easier to debug issues when IDE fails to execute something, so I'd be happy to enable them, but I first need to know if there is some reason for not-enabling them that I'm not aware of.

Copy link
Member

@Akirathan Akirathan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minors. Otherwise LGTM.

s"Method overloads are not supported: ${targetType.map(_.name + ".").getOrElse("")}from " +
s"Ambiguous conversion: ${targetType.map(_.name + ".").getOrElse("")}from " +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if I accidentaly do something like this:

method x y = x + y
method x = x

Would the error message say "Ambiguous conversion" in that case as well? Isn't that misleading? What about trying to distinguish between those two cases - "Ambiguous conversion" VS "Method overload"?

@radeusgd radeusgd added the CI: Ready to merge This PR is eligible for automatic merge label Nov 11, 2023
@mergify mergify bot merged commit f47ef0c into develop Nov 11, 2023
31 of 33 checks passed
@mergify mergify bot deleted the wip/radeusgd/fix-from-bug branch November 11, 2023 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler crash when ambiguous from conversions are encountered
3 participants