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

Have a per-run time budget for import suggestions #9167

Merged
merged 5 commits into from
Jun 14, 2020

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 11, 2020

Keep a budget of import suggestions per run. The first timeout is 10sec.
Each successive timeout is the previous timeout reduced by the search time
of the previous suggestion search, but at least half the previous timeout.

Fixes #9160

Keep a budget of import suggestions per run. The first timeout is 10sec.
Each successive timeout is the previous timeout reduced by the search time
of the previous suggestion search, but at least half the previous timeout.
@odersky
Copy link
Contributor Author

odersky commented Jun 11, 2020

Can we still roll this into 0.25? It would address a problem several people have come across.

@smarter
Copy link
Member

smarter commented Jun 11, 2020

The first timeout is 10sec.

Can we make this configurable via a flag? An IDE for example might want to use a near-zero value or typecheck-as-you-type and increase it when idling. Additionally, is 10 seconds the right default? It seems quite high to me considering how many lines of code you could typecheck in that time.

@smarter
Copy link
Member

smarter commented Jun 11, 2020

Can we still roll this into 0.25?

0.25.0-RC1 is already on maven, but we could make an 0.25.0-RC2

That way we escape the problem that implicit timeouts are reduced too much
for later tests.
We now expose it as a var, which can be set by IDEs or other tools.
Copy link
Contributor

@anatoliykmetyuk anatoliykmetyuk left a comment

Choose a reason for hiding this comment

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

This is good as a fast fix. However, the heap still goes up to 1GB and dotty.tools.dotc.core.Types$CachedAppliedType count – to more than 4M on #9160:

Screenshots Screenshot 2020-06-12 at 10 48 16 Screenshot 2020-06-12 at 10 48 18

I find it hard to believe we really need 4M objects when typechecking all those implicits...

Avoid referring to config option before it is initialized
@odersky odersky merged commit b5b41b4 into scala:master Jun 14, 2020
@odersky odersky deleted the fix-#9160 branch June 14, 2020 12:38
@@ -87,6 +87,7 @@ class ScalaSettings extends Settings.SettingGroup {
val XfatalWarnings: Setting[Boolean] = BooleanSetting("-Xfatal-warnings", "Fail the compilation if there are any warnings.")
val XverifySignatures: Setting[Boolean] = BooleanSetting("-Xverify-signatures", "Verify generic signatures in generated bytecode.")
val XignoreScala2Macros: Setting[Boolean] = BooleanSetting("-Xignore-scala2-macros", "Ignore errors when compiling code that calls Scala2 macros, these will fail at runtime.")
val XimportSuggestionTimeout: Setting[Int] = IntSetting("-Ximport-suggestion-timeout", "Timeout (in ms) for searching for import suggestions when errors are reported.", 8000)
Copy link
Member

Choose a reason for hiding this comment

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

@tgodzik You may want to set this timeout to a very low or even zero value when using the compiler from metals.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the hint! I think we can set it to 0 now, since we don't use that information in the IDE currently.

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.

100 implicits eat heap and slow down error reporting
4 participants