luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
sbt/sbt-app/src/sbt-test/actions/multi-command/test

41 lines
1022 B
Plaintext
Raw Normal View History

Support braces in multi command parser We run into issues if we naively split the command input on ';' and treat each part as a separate command unless the ';' is inside of a string because it is also valid to have ';'s inside of braced expressions, e.g. `set foo := { val x = 1; x + 1 }`. There was no parser for expressions enclosed in braces. I add one that should parse any expression wrapped in braces so long as each opening brace is matched by a closing brace. The parser returns the original expression. This allows the multi parser to ignore ';' inside of '{...}'. I had to rework the scripted tests to individually run 'reload' and 'setUpScripted' because the new parser rejects setUpScripted because it isn't a valid command until reload has run.
2019-06-14 08:48:51 +02:00
> ;set dynamicTask := { println("1"); println("2") }; dynamicTask
-> ; set dynamicTask := { throw new IllegalStateException("fail") }; dynamicTask
> set dynamicTask := { println("1"); println("2") }; dynamicTask
-> set dynamicTask := { throw new IllegalStateException("fail") }; dynamicTask
Refactor multi parser Prior to this commit, there was no unit testing of the parser for multiple commands. I wanted to make some improvements to the parser, so I reworked the implementation to be testable. This change also allows the multiParserImpl method to be shared with Watched.watch, which I will also update in a subsequent commit. There also were no explicit scripted tests for multiple commands, so I added one that I will augment in later commits.
2018-11-19 16:55:14 +01:00
> ; setStringValue baz
> ; checkStringValue baz
> ; setStringValue foo; setStringValue bar
> checkStringValue bar
> ; setStringValue foo; setStringValue bar; setStringValue baz; checkStringValue baz
Do not require leading semicolon for multi command It has long been a frustration of mine that it is necessary to prepend multiple commands with a ';'. In this commit, I relax that restriction. I had to reorder the command definitions so that multi comes before act. This was because if the multi command did not have a leading semicolon, then it would be handled by the action parser before the multi command parser had a shot at it. Sadness ensued.
2018-11-19 17:36:58 +01:00
> setStringValue foo; setStringValue bar
> checkStringValue bar
> setStringValue foo; setStringValue bar; setStringValue baz
> checkStringValue baz
-> setStringValue foo; taskThatFails; setStringValue bar
> checkStringValue foo
Validate commands in multiparser It was reported in https://github.com/sbt/sbt/issues/4808 that compared to 1.2.8, sbt 1.3.0-RC2 will truncate the command args of an input task that contains semicolons. This is actually intentional, but not completely robust. For sbt >= 1.3.0, we are making ';' syntactically meaningful. This means that it always represents a command separator _unless_ it is inside of a quoted string. To enforce this, the multi parser will effectively split the input on ';', it will then validate that each command that it extracted is valid. If not, it throws an exception. If the input is not a multi command, then parsing fails with a normal failure. I removed the multi command from the state's defined commands and reworked State.combinedParser to explicitly first try multi parsing and fall back to the regular combined parser if it is a regular command. If the multi parser throws an uncaught exception, parsing fails even if the regular parser could have successfully parsed the command. The reason is so that we do not ever allow the user to evaluate, say 'run a;b'. Otherwise the behavior would be inconsitent when the user runs 'compile; run a;b'
2019-06-14 01:31:35 +02:00
# this fails even though the checkInput parser would parse the input into Seq("foo", "bar")
-> checkInput foo; bar
> checkInput foo
> compile; checkInput foo
Improve multi parser performance The multi parser had very poor performance if there were many commands. Evaluating the expansion of something like "compile;" * 30 could cause sbt to hang indefinitely. I believe this was due to excessive backtracking due to the optional `(parser <~ semi.?).?` part of the parser in the non-leading semicolon case. I also reworked the implementation so that the multi command now has a name. This allows us to partition the commands into multi and non-multi commands more easily in State while still having multi in the command list. With this change, builds and plugins can exclude the multi parser if they wish. Using the partitioned parsers, I removed the high/priority low priority distinction. Instead, I made it so that the multi command will actually check if the first command is a named command, like '~'. If it is, it will pass the raw command argument with the named command stripped out into the parser for the named command. If that is parseable, then we directly apply the effect. Otherwise we prefix each multi command to the state.
2019-06-25 06:28:58 +02:00
> ++ 2.11.12 compile; setStringValue bar; checkStringValue bar
Scala 2.12.20 (was .19)
2024-09-02 19:41:09 +02:00
> ++2.12.20 compile; setStringValue foo; checkStringValue foo