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

Fixes for sbt-dotty #2690

Merged
merged 7 commits into from
Jun 7, 2017
Merged

Fixes for sbt-dotty #2690

merged 7 commits into from
Jun 7, 2017

Conversation

smarter
Copy link
Member

@smarter smarter commented Jun 6, 2017

No description provided.

In the next commit we'll extend configureIDE to work even when it needs
to update some settings to set the scalaVersion to Dotty. Since this
update takes some time and is discarded at the end of the task, it makes
sense to run the configuration and compilation steps in the same task to
avoid having to do the settings update twice.
// Not needed to generate the config, but this guarantees that the
// generated config is usable by an IDE without any extra compilation
// step.
val _ = compile.value
Copy link
Member

Choose a reason for hiding this comment

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

This is different from what prepareIDE did before. It called compileForIDE.value, not compile.value.

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, but all compileForIDE does is call compile on each dotty configuration, here we already are in a task run in every dotty configuration, so compile is fine.

Copy link
Member

Choose a reason for hiding this comment

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

OK but then, why is compileForIDE still necessary? It doesn't seem to be called by anything.

if (isDottyVersion(version))
Some((version, projRef))
else
crossScalaVersions.in(projRef).get(settings).get.filter(isDottyVersion).sorted.lastOption match {
Copy link
Member

Choose a reason for hiding this comment

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

I very much doubt sorted sorts in a meaningful way here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I had a FIXME before that we need a real ordering for version numbers, will add it back.

if (dottyVersions.isEmpty)
throw new FeedbackProvidedException {
override def toString = "No Dotty project detected"
}
Copy link
Member

Choose a reason for hiding this comment

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

Throwing a FeedbackProvidedException seems weird. I wouldn't expect that to be thrown if there isn't at least some error logging before that, otherwise the user won't see anything, right?

Consider throw new MessageOnlyException("No Dotty project detected") instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I thought FeedbackProvidedException displayed its toString in sbt? Will check.

Copy link
Member

Choose a reason for hiding this comment

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

MessageOnlyException is the "standard" one if you want to display a message and fail the task, but not display the stack trace of the exception.

override def toString = "No Dotty project detected"
}
else {
val dottyVersion = dottyVersions.sorted.last
Copy link
Member

Choose a reason for hiding this comment

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

Again, sorted probably does not do what you want.

// If different versions of Dotty are used by subprojects, choose the latest one
// FIXME: use a proper version number Ordering that knows that "0.1.1-M1" < "0.1.1"
val ideVersion = configs.map(_.compilerVersion).sorted.last
configureIDE := Def.taskDyn {
Copy link
Member

Choose a reason for hiding this comment

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

configureIDE should not be a Task anymore, if it's going to play with States, create new ones and run tasks within those modified States. It should definitely be a Command. Otherwise you expose yourself to race conditions if configureIDE is run in parallel with other tasks.

// FIXME: use a proper version number Ordering that knows that "0.1.1-M1" < "0.1.1"
val ideVersion = configs.map(_.compilerVersion).sorted.last
configureIDE := Def.taskDyn {
val origState = state.value
Copy link
Member

Choose a reason for hiding this comment

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

I expect this hackery that doesn't make sense to me not to be necessary with a Command.

val (dottyVersion, projRefs, dottyState) = dottySetup(origState)
val configs0 = runInAllConfigurations(projectConfig, projRefs, dottyState).flatten

// Drop configurations who do not define their own sources, but just
Copy link
Member

Choose a reason for hiding this comment

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

typo: who -> that

val pwArtifact = new PrintWriter(".dotty-ide-artifact")
pwArtifact.println(s"ch.epfl.lamp:dotty-language-server_0.1:${ideVersion}")
pwArtifact.println(s"ch.epfl.lamp:dotty-language-server_${dlsBinaryVersion}:${dlsVersion}")
pwArtifact.close()
Copy link
Member

Choose a reason for hiding this comment

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

er ... try/finally for the close()?

Copy link
Member Author

Choose a reason for hiding this comment

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

pwArtifact.println does not throw exception, so why would a try/finally help here?

Copy link
Member

@sjrd sjrd Jun 6, 2017

Choose a reason for hiding this comment

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

Idk, visceral reaction to seeing an allocation of a file stream and its close() without try/finally, I guess 😄. Right now it might not make a difference, but who knows what will happen in the future with that code, and someone will introduce a potentially-exception-throwing code and forget to add the try/finally.

Copy link
Member Author

Choose a reason for hiding this comment

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

Alright, will add. :)

runInAllConfigurations(compile, projRefs, dottyState)
()
}
}.value,
Copy link
Member

Choose a reason for hiding this comment

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

This is changed in this commit, but it appears not to be used whatsoever, due to the comment I made on the previous commit.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not used, but can be manually called by the user, e.g. you may want to run sbt ~compileForIDE in the background of the IDE. This is undocumented because it's likely to change.

Copy link
Member

Choose a reason for hiding this comment

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

Ah OK.

So far, configureIDE detected the dotty-compiled projects by looking at
`scalaVersion`, with this commit we now also look at
`crossScalaVersions`. This is considerably harder to do since extracting
the settings requires updating `scalaVersion` in all projects where it's
not set to a dotty version but `crossScalaVersion` is, moreover this
update needs to be temporary: once the `configureIDE` task is done, the
state should revert to the original one.
This makes sense since they deal with the state (even if they always
return the original state).
@smarter
Copy link
Member Author

smarter commented Jun 6, 2017

PR updated, thanks for the comments!

@olafurpg olafurpg mentioned this pull request Jun 7, 2017
@smarter smarter merged commit 6f8bc43 into scala:master Jun 7, 2017
@sjrd
Copy link
Member

sjrd commented Jun 7, 2017

👍

@olafurpg
Copy link
Member

olafurpg commented Jun 7, 2017

🎉 any chance to get a new sbt-dotty release out?

@smarter
Copy link
Member Author

smarter commented Jun 7, 2017

Only @felixmulder has the magic powers to do the release, he told me he would do it at 6 PM :).

@felixmulder
Copy link
Contributor

felixmulder commented Jun 7, 2017

The CI should do it henceforth: #2706
🎉

PS - I'm the only one with magic powers, because nobody else wants the powers XD

@allanrenucci allanrenucci deleted the ide-cross branch December 14, 2017 19:23
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

4 participants