Mull skips any potential mutations that are part of the macro invocations.
One of the reasons is that the debug information is kinda broken with macros, for the following code:

#define something(x) x
/// ...
something(a   b)

mull generates cxx_add_to_sub mutant for the a b, but the debug information for this expression points to the beginning of the macro:

something(a   b)
^

during the junk detection we cannot say for sure if the mutation is valid or not, so we discard it to be on the safe side.

I remember we touched this topic briefly while discussing AST mutations, but I don't recall the conclusion.
Maybe @stanislaw can add something? :)

Would it be possible/sensible to apply Mull to the preprocessed sources?

Would it be possible/sensible to apply Mull to the preprocessed sources?

There are two answers to this question:

1. It is one of the limitations of the IR-level mutations that we couldn't find a workaround for: imprecision of the debug information for the preprocessed parts.

(see Alex's answer above)

This was a state of the previous versions of LLVM and there is a small chance that this could improve. This is something that we could check.

2. On the AST level, it should be possible to implement this, but we simply haven't done it yet. It is a good idea to include the mutations in the preprocessed sources to the AST roadmap here: Roadmap: AST-level mutations #867 (done just now).

Hi @RobertoBagnara, it's certainly possible to run mull against preprocessed source code. As long as you can build an executable that has bitcode embedded in it you are good to go.

Though, you may get many more mutants that you want. As part of the normal run mull discards all the mutants that are coming from the "system" headers. I'm afraid in the case of a preprocessed file mull won't be able to distinguish between a "system" function and the "user" functions.