vincenzoarceri / rust-lisa Goto Github PK

Description
As of now, some example are compiling (in Rust) and some are not. Furthermore some of them are compiling without warnings, but most of them have some (usually due to their nature of being simple example). We should make sure that all rust examples can compile, with the least number of warning possible.

Description
In rust there are two main ways of returning from a function. Using the return statement or omitting the ; at the end of a statement. At the moment, none of them are supported.

Description
We should parse the enum types.

Motivation
Some of the most used types (like Option or Error) are enums.

Currently the code does not take the for statement into account. Please change this in the future.

The code currently does not implement any code regarding the while control structure. This should change in the near future.

Description
Currently there is no check for a field of a struct to be in the struct itself. This check can (and should) be done with static semantics.

For example, this code should raise an error:

enum Message {
    Move { x: i32, y: i32 },
}

fn main() {
    let m = Message::Move {x : 1, y : 2};
    if let Message::Move{ x: a, z: b} = m2{
        println!("{}", a);
        println!("{}", b);
    }
}

Description
During match statement we use the RustEqualExpression operator (== operator). We should check if this is the right operator to use, and if not we should change it / create a new one to use.

Suggested implementation
It is highly recommended that we create a new node that is capable of doing destructuring and correctly evaluates the guard.

Description
Functions with no statement inside makes rust-lisa crash

Reproducibility information
The bug is already present in 180aaa9 on master branch.

Actual behavior
Example:

fn main () {
}

This is a legit Rust function that we are not able to parse right now.
The error is the following:

Exception in thread "main" java.lang.NullPointerException: The source of an edge cannot be null
	at java.base/java.util.Objects.requireNonNull(Objects.java:246)
	at it.unive.lisa.program.cfg.edge.Edge.<init>(Edge.java:38)
	at it.unive.lisa.program.cfg.edge.SequentialEdge.<init>(SequentialEdge.java:25)
	at it.unipr.frontend.RustCodeMemberVisitor.visitFn_decl(RustCodeMemberVisitor.java:218)
	at it.unipr.frontend.RustFrontend.visitPub_item(RustFrontend.java:151)
	at it.unipr.frontend.RustFrontend.visitItem(RustFrontend.java:140)
	at it.unipr.frontend.RustFrontend.visitMod_body(RustFrontend.java:129)
	at it.unipr.frontend.RustFrontend.visitCrate(RustFrontend.java:122)
	at it.unipr.frontend.RustFrontend.toLiSAProgram(RustFrontend.java:113)
	at it.unipr.frontend.RustFrontend.processFile(RustFrontend.java:94)
	at it.unipr.RustLiSA.main(RustLiSA.java:26)

Expected behavior
The function to be parsed correctly.

Further content
The fix should be easy. This issue is here as a remainder.

Description
We should parse and create a CFG node for let statement.

Suggested implementation
For the moment, it could simply extend the Assignment class. Until we do not fix #1, we can just use Untyped type for any declared variable.

Description
Currently, there is no support for catch alla statement inside a match (i.e. _ guard inside a branch).

Expected behavior
This catch-all statement in match should be the entry of each statement if any other case in the match is descarded.

Suggested implementation
The problem needs further analysis but it is probably enough to simply rewrite the guard as a true statement evaluation.

Description
As of now, functions with primitive return type are parsed correctly but the ones with user-defined types are not.

Further content
Rust function return types are specified after an arrow (->).
Example (with primitive types):

fn func() -> i32 {
    42
}

As of now, the current code does not take into account the guards for if, else if, while, match and so on. The code should implement these feature.

Description
We should add support and create a CFG node for the match statement.

Motivation
match is a foundational statement of Rust. This should dramatically increase our support to the language.

Description
As in the other LiSA frontend, we split the visit of code member from the visit of Rust types, my means of a RustTypeVisitor class, implementing the RustBaseVisitor interface, and managing exclusively the type parsing.

Description
We should implement the if-let statement. The if let statement is used particularly for matching enums. This should increase our parsing capabilities.

Description
We should take into account that expression inside a block can return a value, so that the super-block can collect the value, and, for example, assign it to a variable

Description
As of now, the class RustMultipleExpression is used a replacer for a List<Expression>, but it is probably useless and can be removed from the code (so that it will be cleaner). We could try to replace every instance of it with the above mentioned list and see if the behavior expected is the same.

Description
A proper README.md describing RustLiSA requirements and how to build and import in Eclipse RustLiSA is needed.

Description
In the grammar files, there are two non-terminal symbols for expressions: the ones that do not parse structs (they end with no_struct) and the ones that parse structs (e.g., prim_expr). We already have an implementation for the visit of the struct rules, the visit for the no_struct rules seems pretty similar. It seems they differ in post_expr and prim_expr. Just as an example, I report below the prim_expr and prim_expr_no_struct rules.

prim_expr
   : prim_expr_no_struct
   | path '{' expr_inner_attrs? fields? '}'
   ;

prim_expr_no_struct
   : lit
   | 'self'
   | path macro_tail?

We should add all the built-in types of Rust. [link]

Description
Add parsing for continue and break statements.

Motivation
We should implement those statements to allow, respectively, to skip to the next iteration (for eg. in a for statement) and exiting from a loop.

Currently, we are modeling just the assignment statement. We should model also the statements that modify the control structure of a program (e.g., if, while, for)

Description
Currently, macros are skipped during parsing, so to avoid conflicts. We should start treating macros and parse their calls

Suggested implementation
We can start by thinking of treating them as UnresolvedCall

Description
Currently, when we are parsing the code, unreachable statement are considered a hard errors and LiSA throws an exception.

Reproducibility information
A programma like the following can produce the error:

fn func() -> i32 {
	let x = 2;
	if x == 2 {
		return 1;
	} else {
		return 3;
	}
	
	return 4;
}

Expected behavior
We should remove the unreachable statements during parsing, or make sure in some ways that LiSA does not give a ProgramValidationException: Unreachable node that is not marked as entrypoint.

Description
We should add support for calling methods of rust's struct. Note that in Rust methods can be somewhat static (they do not use the &self as parameter).

There is no implementation for the empty statement. An empty statement is composed only by a semicolon (;). We should take that statement also into account.