At least one of the case is the following:
A Function or Sub doesn't compile and the developer is not aware of that when running the VBA project because the Sub is never called.
Solution:
This "junk" code can be spotted in Trace-level logs of Rubberduck.
For exemple in my case:
Sub CleanSheetOut()
Worksheets(sheetOut).Range("A1:XFD10485576").Clear
Worksheets(sheetOut).Range("A1:XFD10485576").Interior
.Pattern = xlNone
.TintAndShade = 0
.PatternTintAndShade = 0
End Sub
...was incorrect (didn't compile) but was never called, so the project was running fine but Rubberduck couldn't resolve.
The correct code :
Sub CleanSheetOut()
Worksheets(sheetOut).Range("A1:XFD10485576").Clear
With Worksheets(sheetOut).Range("A1:XFD10485576").Interior
.Pattern = xlNone
.TintAndShade = 0
.PatternTintAndShade = 0
End With
End Sub
...compiles and lets Rubberduck parse and resolve normally.
The logs:
... showed the faulty Sub and in which module I could find it.
Insight from the Rubberduck development team:
Whether the VBE compiles on the fly depends on the compile settings in
the bottom right of the Editor tab of the Tools->Options menu.
We actually try to compile the project and warn the user that the
project does not compile. However, the forementioned VBE settings can
interfere with that. Moreover, compilation before refresh might be
deactivated in Rubberduck's own settings.
See this Github thread for more details.