github/semantic
1
1
Fork 0
mirror of https://github.com/github/semantic.git synced 2024-12-01 09:15:01 +03:00
Code Issues Projects Releases Wiki Activity
73ae9f85a1
semantic/test/Spec.hs

81 lines
3.5 KiB
Haskell
Raw Normal View History

Manual spec inclusion.
2016-01-05 19:27:37 +03:00
module Main where
Test out go import evaling
2018-03-13 21:14:55 +03:00
import qualified Analysis.Go.Spec
Write a small spec for evaluating PHP includes
2018-03-20 00:42:00 +03:00
import qualified Analysis.PHP.Spec
Test out rest of python imports, move to new dir
2018-03-10 02:16:07 +03:00
import qualified Analysis.Python.Spec
TDD FTW
2018-03-14 02:19:26 +03:00
import qualified Analysis.Ruby.Spec
Turn on the TypeScript analysis spec
2018-03-10 03:24:32 +03:00
import qualified Analysis.TypeScript.Spec
Rename the assignment spec.
2017-11-27 21:47:04 +03:00
import qualified Assigning.Assignment.Spec
Stub in a spec for Evaluator.
2018-05-07 21:21:05 +03:00
import qualified Control.Abstract.Evaluator.Spec
add spec file
2018-09-14 20:08:08 +03:00
import qualified Control.Rewriting.Spec
Rename the Diff spec.
2017-11-27 21:59:44 +03:00
import qualified Data.Diff.Spec
add Data/Abstract/Name/Spec
2018-10-31 20:19:43 +03:00
import qualified Data.Abstract.Name.Spec
Resolve module import paths that walk up directory structure (e.g. ../)
2018-04-18 00:13:01 +03:00
import qualified Data.Abstract.Path.Spec
Combine the generic Eq1, Ord1, & Show1 implementations into a single module.
2017-11-30 18:24:48 +03:00
import qualified Data.Functor.Classes.Generic.Spec
add Data/Graph/Spec
2018-10-31 19:20:38 +03:00
import qualified Data.Graph.Spec
add Data/Range/Spec
2018-10-31 19:46:52 +03:00
import qualified Data.Range.Spec
Standardize and fix floating-point parsing. The existence of #1705 showed me that it's time to remove the bandaid of a fix that was `normalizeFloatString` in #1537. This patch introduces a proper Attoparsec parser for Scientific values that handles the vaguaries of cross-language floating-point syntax. We already depended on Attoparsec indirectly, so adding it as an explicit dependency is fine. A unit test is included, with examples taken from the tree-sitter corpora.
2018-04-04 00:02:56 +03:00
import qualified Data.Scientific.Spec
Environment and App.
2018-10-31 22:47:30 +03:00
import qualified Data.Semigroup.App.Spec
Rename the Source spec.
2017-11-27 21:49:52 +03:00
import qualified Data.Source.Spec
Rename the Term spec.
2017-11-27 22:02:03 +03:00
import qualified Data.Term.Spec
Rename the RWS spec.
2017-11-27 21:48:43 +03:00
import qualified Diffing.Algorithm.RWS.Spec
Rename the SES spec.
2017-11-27 21:51:05 +03:00
import qualified Diffing.Algorithm.SES.Spec
Rename the Interpreter spec.
2017-11-27 22:03:45 +03:00
import qualified Diffing.Interpreter.Spec
Simplest test possible.
2018-07-16 18:07:40 +03:00
import qualified Graphing.Calls.Spec
Rename the Integration spec.
2017-11-27 22:06:12 +03:00
import qualified Integration.Spec
Introduce tree-automata DSL for filtering and matching ASTs. This patch adds the `Matcher` monad, which is capable of filtering any recursive data structure, bottom-up, yielding a list of (or an optional) result. These functions are probably going to be used over `Term` values, so API is provided to wrap common projection functions. The API was more or less copied directly from that of Clang's AST matching facilities. There are a lot of things we can do in the future: * Binding results yielded in matchers to associated names, for future transformation stages to look up and modify. * Actual transformation stages. * Optimizations. This is not very fast. A million thanks to @robrix, whose sage advice managed to turn my kooky idea for an API into something really special and exciting.
2018-03-27 23:14:30 +03:00
import qualified Matching.Go.Spec
Give Control.Matching API better ergonomics. Given that @tclem and I have found the matcher API frustrating, I've taken a stab at improving its ergonomics, and I've found some success in separating composition of matchers from predicate-based narrowing thereof. The biggest change here is the elimination of the old `match` combinator, which proved to be clumsy in that it complected narrowing and composition. Top-down matching combinators are now written with the `need` combinator and the `>>>` combinator, which is more readable and more versatile. Here's a matcher that accepts functions with Python docstrings: ```haskell docstringMatcher :: ( Decl.Function :< fs , [] :< fs , Lit.TextElement :< fs , term ~ Term (Sum fs) ann ) => Matcher term term docstringMatcher = target <* (need Decl.functionBody >>> narrow @[] >>> mhead >>> narrow @Lit.TextElement >>> ensure Lit.isTripleQuoted)) ``` Pretty readable, right? Each step of the tree regular expression - choosing function bodies, ensuring said bodies are lists, examining the first element, and choosing only TextElements containing triple-quoted strings - is made implicit. The old way would have looked something like this: ```haskell docstringMatcher = target <* match Decl.functionBody $ narrow $ matchM listToMaybe $ target <* ensure Lit.isTripleQuoted ``` which is a good deal more disorganized and less flexible in the quite-common case of applying functions during a matching pass. Separating the act of composition from function application is a big win here. Further comments are inline.
2018-11-03 02:25:29 +03:00
import qualified Matching.Python.Spec
Use a hand-written integer parser. Rather than relying on the `Read` instance for `Integer`, let's make our assumptions about the format explicit. This was mostly a matter of extracting internal functions from the `Scientific` parser.
2018-06-25 18:55:32 +03:00
import qualified Numeric.Spec
Rename the TOC spec.
2017-11-27 22:04:58 +03:00
import qualified Rendering.TOC.Spec
Extremely ad-hoc renderer to Docs
2018-07-31 19:44:20 +03:00
import qualified Reprinting.Spec
Introduce some symbol/tags tests
2018-11-02 23:55:30 +03:00
import qualified Tags.Spec
Rename the Semantic spec.
2017-11-27 22:00:53 +03:00
import qualified Semantic.Spec
Rename the CLI spec.
2017-11-27 21:57:25 +03:00
import qualified Semantic.CLI.Spec
Rename the IO spec.
2017-11-27 21:52:48 +03:00
import qualified Semantic.IO.Spec
Rename the Stat spec.
2017-11-27 21:58:23 +03:00
import qualified Semantic.Stat.Spec
Fix up the imports.
2018-07-10 21:17:56 +03:00
import Semantic.Config (defaultOptions)
import Semantic.Task (withOptions)
Move TaskConfig into Semantic.Util.
2018-07-10 21:09:02 +03:00
import Semantic.Util (TaskConfig(..))
actually run the specs
2018-06-05 19:51:23 +03:00
import qualified Proto3.Roundtrip
Manual spec inclusion.
2016-01-05 19:27:37 +03:00
import Test.Hspec
main :: IO ()
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
main = do
Use withOptions in the spec.
2018-07-10 21:16:51 +03:00
withOptions defaultOptions $ \ config logger statter -> hspec $ do
Pass the task config stuff around as a single datum.
2018-07-10 20:49:34 +03:00
let args = TaskConfig config logger statter
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Semantic.Stat" Semantic.Stat.Spec.spec
parallel $ do
Pass the configuration to the analysis specs.
2018-07-10 21:09:22 +03:00
describe "Analysis.Go" (Analysis.Go.Spec.spec args)
describe "Analysis.PHP" (Analysis.PHP.Spec.spec args)
describe "Analysis.Python" (Analysis.Python.Spec.spec args)
describe "Analysis.Ruby" (Analysis.Ruby.Spec.spec args)
describe "Analysis.TypeScript" (Analysis.TypeScript.Spec.spec args)
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Assigning.Assignment" Assigning.Assignment.Spec.spec
describe "Control.Abstract.Evaluator" Control.Abstract.Evaluator.Spec.spec
add spec file
2018-09-14 20:08:08 +03:00
describe "Control.Rewriting.Spec" Control.Rewriting.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Data.Diff" Data.Diff.Spec.spec
add Data/Graph/Spec
2018-10-31 19:20:38 +03:00
describe "Data.Graph" Data.Graph.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Data.Abstract.Path" Data.Abstract.Path.Spec.spec
add Data/Abstract/Name/Spec
2018-10-31 20:19:43 +03:00
describe "Data.Abstract.Name" Data.Abstract.Name.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Data.Functor.Classes.Generic" Data.Functor.Classes.Generic.Spec.spec
add Data/Range/Spec
2018-10-31 19:46:52 +03:00
describe "Data.Range" Data.Range.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Data.Scientific" Data.Scientific.Spec.spec
Environment and App.
2018-10-31 22:47:30 +03:00
describe "Data.Semigroup.App" Data.Semigroup.App.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Data.Source" Data.Source.Spec.spec
describe "Data.Term" Data.Term.Spec.spec
describe "Diffing.Algorithm.RWS" Diffing.Algorithm.RWS.Spec.spec
describe "Diffing.Algorithm.SES" Diffing.Algorithm.SES.Spec.spec
describe "Diffing.Interpreter" Diffing.Interpreter.Spec.spec
Simplest test possible.
2018-07-16 18:07:40 +03:00
describe "Graphing.Calls" Graphing.Calls.Spec.spec
Give Control.Matching API better ergonomics. Given that @tclem and I have found the matcher API frustrating, I've taken a stab at improving its ergonomics, and I've found some success in separating composition of matchers from predicate-based narrowing thereof. The biggest change here is the elimination of the old `match` combinator, which proved to be clumsy in that it complected narrowing and composition. Top-down matching combinators are now written with the `need` combinator and the `>>>` combinator, which is more readable and more versatile. Here's a matcher that accepts functions with Python docstrings: ```haskell docstringMatcher :: ( Decl.Function :< fs , [] :< fs , Lit.TextElement :< fs , term ~ Term (Sum fs) ann ) => Matcher term term docstringMatcher = target <* (need Decl.functionBody >>> narrow @[] >>> mhead >>> narrow @Lit.TextElement >>> ensure Lit.isTripleQuoted)) ``` Pretty readable, right? Each step of the tree regular expression - choosing function bodies, ensuring said bodies are lists, examining the first element, and choosing only TextElements containing triple-quoted strings - is made implicit. The old way would have looked something like this: ```haskell docstringMatcher = target <* match Decl.functionBody $ narrow $ matchM listToMaybe $ target <* ensure Lit.isTripleQuoted ``` which is a good deal more disorganized and less flexible in the quite-common case of applying functions during a matching pass. Separating the act of composition from function application is a big win here. Further comments are inline.
2018-11-03 02:25:29 +03:00
describe "Matching.Go" Matching.Go.Spec.spec
describe "Matching.Python" Matching.Python.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Numeric" Numeric.Spec.spec
describe "Rendering.TOC" Rendering.TOC.Spec.spec
Extremely ad-hoc renderer to Docs
2018-07-31 19:44:20 +03:00
describe "Reprinting.Spec" Reprinting.Spec.spec
Introduce some symbol/tags tests
2018-11-02 23:55:30 +03:00
describe "Tags.Spec" Tags.Spec.spec
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Semantic" Semantic.Spec.spec
describe "Semantic.CLI" Semantic.CLI.Spec.spec
describe "Semantic.IO" Semantic.IO.Spec.spec
Pass the task config stuff around as a single datum.
2018-07-10 20:49:34 +03:00
describe "Integration" (Integration.Spec.spec args)
Pass config & queues to the integration specs.
2018-07-09 21:26:15 +03:00
describe "Protobuf roundtripping" Proto3.Roundtrip.spec
Reference in New Issue Copy Permalink