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

infinite loop with implicit conversions #16830

Open
bertlebee opened this issue Feb 4, 2023 · 1 comment
Open

infinite loop with implicit conversions #16830

bertlebee opened this issue Feb 4, 2023 · 1 comment
Labels
area:implicits related to implicits area:reporting Error reporting including formatting, implicit suggestions, etc itype:enhancement

Comments

@bertlebee
Copy link

Compiler version

3.2.1

Minimized code

https://scastie.scala-lang.org/JBCQX6gXRuSizuzuT7Im9A

Prior work
#10947
#13542

Output

stack overflow, presentation compiler suggests invalid completions (presumably from using the implicit conversion

Expectation

Shouldn't compile, or should at least provide a warning?
completions from presentation compiler shouldn't use the implicit conversion being used

@bertlebee bertlebee added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Feb 4, 2023
@mbovel mbovel added area:implicits related to implicits and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Feb 5, 2023
@odersky
Copy link
Contributor

odersky commented Feb 11, 2023

Here's the code that gets generated:

    final lazy given val given_Conversion_Foo_Bar: Conversion[Foo, Bar] =
      {
        def $anonfun(foo: Foo): Bar =
          given_Conversion_Foo_Bar.apply(Foo.apply(foo.a))
        closure($anonfun:Conversion[Foo, Bar])
      }

So, it inserts a conversion again. This is as specified, and is a good demonstration what a footgun implicit conversions are. Now, with a lot of grunt work we could probably detect some cases where a conversion is certain to produce an infinite loop. But it's hard. There is a very high chance of false positives, so probably we need several iterations to get it right and would break some code in between.

I think a much better use of our energy is to continue our efforts to make implicit conversions legal only in certain cases, namely where they are used to transform an argument of an into parameter. See #14514.

@odersky odersky added itype:enhancement area:reporting Error reporting including formatting, implicit suggestions, etc and removed itype:bug labels Feb 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:implicits related to implicits area:reporting Error reporting including formatting, implicit suggestions, etc itype:enhancement
Projects
None yet
Development

No branches or pull requests

3 participants