Rust frontend in development -- questions

[robinmaisch]

I am working on a Rust frontend for JPlag and came across macros in Rust. According to the Rust grammar specification, the contents of a macro template have very little defined structure to them; only the expanded macro needs to be syntactically and semantically correct. Thus, macro templates are parsed to a sequence of broadly classified tokens, as if they were only lexed, not parsed. The same goes for the arguments passed to macro invocations.

So, it seems that these parts are essentially hidden from JPlag. It is impossible to identify any syntactical structure in them.

From looking at some example code in Rust really quick, I'd say that it commonly contains rather few own macro rule definitions, but macro invocations are used quite frequently, maybe once for 5 regular method invocations. Most macro rules are imported from libraries or built-in, as for IO and exception handling. In the case of exercise assignments, macros could be used to wrap the complete solution or major parts of it, making the analysis by JPlag worthless.

So, thought I'd bring these points up early in development. Telling from your experience with JPlag and knowledge of Rust (if any),

• How much of a problem are macro rules, which essentially bypass the JPlag analysis? Will the frontend still be usable enough?
• Has a similar problem occurred elsewhere in the project? Is there any quick solution at hand that I'm missing?
• Since, in practice, the contents of macros still need to be syntactically correct, should an attempt be made to modify the grammar so that these parts are properly parsed? Is that even possible?

macroRule :		macroMatcher '=>' macroTranscriber ;
macroTranscriber : 	delimTokenTree ;
delimTokenTree : 	'(' tokenTree* ')' | '[' tokenTree* ']' | '{' tokenTree* '}' ;
tokenTree : 		tokenTreeToken+ | delimTokenTree ;
tokenTreeToken : 	macroIdentifierLikeToken | macroLiteralToken | macroPunctuationToken | macroRepOp | '$' ;
			// ^ no syntax here; only sequence of broadly classified tokens

macro_rules! give_me_struct {
    ($name:ident) => {
        #[allow(non_camel_case_types)]
        struct $name;
    }
}

[tsaglam]

@robinmaisch

So, thought I'd bring these points up early in development. Telling from your experience with JPlag and knowledge of Rust (if any),

No experience with rust so far.

How much of a problem are macro rules, which essentially bypass the JPlag analysis? Will the frontend still be usable enough?

I think we can still supply the frontend, its effectivity is something some would need to judge with real-world data

Has a similar problem occurred elsewhere in the project? Is there any quick solution at hand that I'm missing?

Some language features are hard to tokenize, e.g. streams. This means the resulting token sequence is not very detailed. But this is just something we have to live with.

Since, in practice, the contents of macros still need to be syntactically correct, should an attempt be made to modify the grammar so that these parts are properly parsed? Is that even possible?

Would be possible, but is it really worth the effort? I would say no. If the frontend is used a lot, people can provide their thoughts or create a PR with adaption.