Stack traces and error messages in compiler output when using scaladoc #12081
Comments
|
Those are Tasty issues. We should minimise them and assign them to Nico. |
|
We could also just turn off warnings on unexpanded Scaladoc variables. It tickles me the wrong way, but judging from the amount of warnings we got in stdlib, convincing the community to properly escape all those variables will be a hard sell. Part of the issue is that staging macros make us emit warnings, and I'm not sure if there's much we can do aside from reworking how Scaladoc variables work. |
|
I'm not convinced they're tasty issues since I see |
|
Hm, that's actually correct, in this particular stack trace that's the first non-Dotty method called. |
|
I don't know what's going on here (somehow the parameter type of a method ends up being a MethodType itself?), but my guess is that it's related to extension methods and/or exports: in BasicSupport.scala where the crash is happening, there's an extension method |
Please yes, the current level of noise is unbearable. |
|
Related: the community-docs job is failing on many commits in https://github.com/lampepfl/dotty/commits/master currently, I tried to look in the log for the source of the problem, but I couldn't find it among all the noise. |
|
I think it's OOMing while trying to build the docs for the new version of ScalaTest.
|
|
Good catch, would you mind trying to increase the (already enormous) heap? (Long term, I hope we can fix the memory usage issue, I've been trying to implement something like scala/scala#2901 but it's a challenge to get working in dotty). |
|
I suspect we may be exhausting the RAM provided by the cloud runner, which says 7GB: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources The scalatest heap is set to 11GB |
|
Hmm, and the mac runners have 14 GB of ram, are those free too? |
It appears so! https://github.community/t/are-macos-actions-free-for-public-repositories/167315 I wonder if high usage is throttled or has long wait times in the queue. |
The type on which we lookup things needs to be the this-type of the class, otherwise it will not include members that only appear in the self-type, since these members can appear in the types of members of the current class, this could lead to a MissingType exception being thrown. Fixes scala#12081.
The type on which we lookup things needs to be the this-type of the class, otherwise it will not include members that only appear in the self-type, since these members can appear in the types of members of the current class, this could lead to a MissingType exception being thrown. Fixes scala#12081.
The type on which we lookup things needs to be the this-type of the class, otherwise it will not include members that only appear in the self-type, since these members can appear in the types of members of the current class, this could lead to a MissingType exception being thrown. Fixes scala#12081.
If I look at the output of a recent CI run like https://github.com/lampepfl/dotty/runs/2332692960, I see stuff like:
Not only does this make it hard to find actual errors in the output, it also probably means that there's some underlying problem that needs to be fixed here.
The text was updated successfully, but these errors were encountered: