Cleanups

[oowekyala]

These are a couple of cleanups:

• using Result instead of bool to not hide errors.
• remove a some clones and simplify some things. For instance I removed the CodeGenerator struct because it is not useful to create a struct just to hold some function parameters and then directly call the function. It causes extra clones because the struct contains not references but owned objects.

I moved my cargo-related changes out of this PR for later.

[oowekyala]

This is how you use result: if the function run_and_capture returns an error result, then the question mark operator here causes the current function to return the same error result. That way in the rest of this function you can assume that the call succeeded.

[tanneberger]

I did some minor clean up and this is now ready to merge.

[tanneberger]

This looks fine to me

[erlingrj]

These look like good changes to me! I saw some TODO regarding the purpose of different structs. I think we would benefit from some discussion about how we should structure this program into different structs, traits and their relationship. Would be great with a class diagram or something. I am still a little confused by the App vs AppFile and Config vs ConfigFile.

Also, I am little confused by the to introduce the lifetime specifiers <'a>. It seems it is used to make sure a reference to the struct doesn't outlive references to its members. I would have guessed this to be the default and that you should essentially annotate all your structs with this

[oowekyala]

These look like good changes to me! I saw some TODO regarding the purpose of different structs. I think we would benefit from some discussion about how we should structure this program into different structs, traits and their relationship. Would be great with a class diagram or something. I am still a little confused by the App vs AppFile and Config vs ConfigFile.

Ideally I think the structs used for CLI args should not make it past main, and eg not be passed to the backend. I have some local changes where I refactored the backend interface in that direction, but probably we should have a broader discussion.

Also, I am little confused by the to introduce the lifetime specifiers <'a>. It seems it is used to make sure a reference to the struct doesn't outlive references to its members. I would have guessed this to be the default and that you should essentially annotate all your structs with this

You only need lifetime parameters for structs that have reference fields. The lifetime of all references in a struct must be quantified by such a parameter, so that the type checker can know where in the program the contained references are valid. The type checker requires that the contained references outlive the struct instance, it's not just about references to members.