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
SI-4625 Recognize App in script #5169
Conversation
Cheap name test: if the script object extends "App", take it for a main-bearing parent. Note that if `-Xscript` is not `Main`, the default, then the source is taken as a snippet and there is no attempt to locate an existing `main` method.
@@ -380,11 +380,15 @@ self => | |||
case DefDef(_, nme.main, Nil, List(_), _, _) => true | |||
case _ => false | |||
} | |||
def isApp(t: Tree) = t match { | |||
case Template(ps, _, _) => ps.exists { case Ident(x) if x.decoded == "App" => true ; case _ => false } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x == tpnme.App
would be more idiomatic. That form avoids needless string creation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or even case Ident(tpnme.App) =>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx, I grepped for it but missed it, trying to beat the evening rush home. Unless you mean add it to names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I mean to add it.
LGTM, nitpick aside. |
Scope creep request: Would be great if we could detect Appy modules in files with more than one definition.
|
I considered a REPLish strategy, put the entire text in a package object. Edit: didn't do that here. But it now allows
|
Scripting knows it by name.
In an unwrapped script, where a `main` entry point is discovered in a top-level object, retain all top-level classes. Everything winds up in the default package.
It's pretty confusing when your script object becomes a local and then nothing happens. Such as when you're writing a test and it takes forever to figure out what's going on.
Fixed the warning when main module is accompanied by snippets. Minor clean-up so even I can follow what is returned.
I thought the scope creep was the guy with binoculars who peers in people's windows. |
} | ||
} | ||
|
||
if (mainModuleName == newTermName(ScriptRunner.defaultScriptMain)) | ||
searchForMain() foreach { return _ } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wow, never seen that pattern before..!
LGTM, too |
I just expected this to work, but I guess it hasn't been merged forward yet... |
Cheap name test: if the script object extends "App",
take it for a main-bearing parent.
Note that if
-Xscript
is notMain
, the default,then the source is taken as a snippet and there is
no attempt to locate an existing
main
method.