lleutch / sast Goto Github PK

So far we are throwing exception at runtime in following cases :

• When assertion not met
• when deserialization of labels/payloads is not possible (due to incorrect labels payload...)

Actual Behaviour

Currently, there is no infrastructure to ensure correctness of the TP.

Expected Behaviour

Need to have :

• Test implemented via Expecto test library
• CI solution binded to the project

The goal of this task is to provided a way to have statically parametrized method that verify some assertion constraint at compile-time.

Actual Behaviour

So far we have 2 files for the parsing :

• ScribbleParser.fs
• AsstScribbleParser.fs

AsstScribbleParser is equivalent to ScribbleParser but with Assertions on top (and Payloads that is properly defined).

As with the current re-Architecture work ( #8 ), this parsing is blocking #8 .

The modification shouldn't be blocking us from using the WebAPI.
As a matter of fact, ScribbleParser(WebAPI), is included in AsstScribbleParser

Expected Behaviour

Have a unique ScribbleParser with assertion and all, that should work for WebAPI, File, and LocalExecutable.

The goal with this task is to provide a way to emulate DU in erased fashion, for the branching part.
So far, we were generating types and type-test pattern on them.
2 main issues :

• Non-exhaustiveness of cases
• TP had to be Generative ( => no On-demand types, but rather fully generated)

This task is a taks which goal is to re-architecture the whole project, to be more modular, more type-safe with a proper Domain Model (not stringly-typed), more meaningfull.

This task might be split into multiple sub-task if this make sense in the future.

• CFSM
• Error Handling
• TypeGeneration.fs + ScribbleGenerativeTypeProvider.fs + Both ScribbleParser.fs AsstScribbleParser.fs (On going)
• Parsing as a separate project
• Communication Architecture as a separate project