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

Don't generate semanticdb files if there are missing #1376

Merged
merged 1 commit into from
Apr 22, 2021

Conversation

mlachkar
Copy link
Collaborator

  • instead we report an error of semanticdb files missing

- Stop compiling when semanticdb file is missing
@tgodzik
Copy link
Contributor

tgodzik commented Apr 21, 2021

In this case, would it be possible to be able to provide semanticdb via Array[Byte] in the API? Not neccessarily in this PR and I know we discussed it previously, but this would be amazing to have as it would enable us to make it work in a bunch of places.

@mlachkar
Copy link
Collaborator Author

We need to think and design this solution. Metals uses scalafix to fix only one file, by the api takes multiple files and in this case how do we differentiate between semanticdb files.
Maybe we need a new api that fixes only one file and in this case we can provide the semantic file.

@tgodzik
Copy link
Contributor

tgodzik commented Apr 21, 2021

We need to think and design this solution. Metals uses scalafix to fix only one file, by the api takes multiple files and in this case how do we differentiate between semanticdb files.
Maybe we need a new api that fixes only one file and in this case we can provide the semantic file.

Maybe we could have an additional Map[String, Array[Byte] ? Or Path instead of string, I am not sure exactly what is currently used 😅

Copy link
Collaborator

@bjaglin bjaglin left a comment

Choose a reason for hiding this comment

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

Limiting the usage of the compiler to advanced semantic rules (for the presentation compiler) and for scalafix-reflect to compile source rule is probably a step in the right direction.

As already discussed in #1348 (review), this ondemand, transparent compilation causes a lot of confusion when the compiler kicks in in 2.12 (default loaded by most clients) against 2.13 classfiles (we had a few gitter questions / github tickets about that), so it's doing more harm than good in my opinion. When it works, it's so silent that the user might not realize there is something wrong with its semanticdb setup and could end up blaming scalafix for the very long run time.

@bjaglin
Copy link
Collaborator

bjaglin commented Apr 21, 2021

We need to think and design this solution. Metals uses scalafix to fix only one file, by the api takes multiple files and in this case how do we differentiate between semanticdb files.
Maybe we need a new api that fixes only one file and in this case we can provide the semantic file.

Maybe we could have an additional Map[String, Array[Byte] ? Or Path instead of string, I am not sure exactly what is currently used sweat_smile

Makes sense, maybe let's follow up on #1236 for this?

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.

None yet

3 participants