Create an option to reject partially parsed files

[NicolasAnquetil]

We could have a -strict option that would reject all files than could not be entirely parsed.
This would avoid putting garbage in the model and also it would be more clear to the user what is correct and what is an approximation.

I guess "partially parsed files" would be those with at least one entity not bound.
(Or may be JDT as some way to tell us before going through the AST ?)

What do you think @LABSARI @badetitou ?

[LABSARI]

We could have a -strict option that would reject all files than could not be entirely parsed.

If VerveineJ rejects corrupted files, Moose will never know about these files. Can we do something about corrupted files ? It would be nice to be able to point out these files from the Moose world.

I guess "partially parsed files" would be those with at least one entity not bound.

We should be careful about this, because some entites may have no bounds because of missing external dependencies.

(Or may be JDT as some way to tell us before going through the AST ?)

I don't know but we have a visitor (not used) that does some checks if some nodes of the AST have no bounds.

What do you think @LABSARI @badetitou ?

We definitely need this option.

[badetitou]

I really don't know.

There are two things if I well understood

1. Files that are out of the project classpath (e.g., files in the build directory)
2. Files that are potentially incorrect in Java but are inside the project classpath (a Java test class that does not compile but people don't care because it is not used for production compilation.

For the first case, people should better use the src option of VerveineJ. We can use multiple src actually, I do not see a scenario that creates a problem. It may not be the most convenient way, but it works for now. Still, if it is only an option and JDT already supports the filter, why not add it? But remember that we have such cases at BL and we can deal with them (maybe not with the docker version, but it is another issue)

For the 2. I would add in the metamodel, maybe in MooseObject itself attributes like: isPartial (to identify incomplete entities. We could imagine incremental parsing also with such a feature), and an attribute isUnbound or something like this for the case described by @LABSARI.