Occasionally a reviewer will spot a bug. Occasionally there will be a false positive that turns out not to be a bug.
You really want to deliberately discard this bug-finding opportunity? Why?
Even if it's a false positive, doesn't that indicate that something bears commenting?
And most often of all, while explaining what they've done, the reviewee will say "and this does... oh crap, wait" and fix the mistake themselves. Among all their other virtues, a code reviewer is a level 2 debugging duck. (Although all of my code review experience is with buddy check-in style reviewing rather than sending it off to be reviewed. I can understand endless nitpicky questioning being annoying if you're doing it offline.)
That is, go over the diff and add commentary explaining to the reviewer why you made particular changes (not explaining what the changes do, that should be in comments in the source).
Isn't the code review generally pretty late, i.e. just prior to release? At that point, the code should be passing all unit tests and I'd expect obvious bugs to be pretty unlikely. Non-obvious bugs generally won't be spotted in a code review setting.
Also, lots of software houses don't have formal testing of all new code. Not unusual with GUI code, for instance.
Also, passing tests is meaningless if the tests are worthless or incomplete. So, those alone can't be used as a metric of code sanity; Meaning obvious bugs are still possible.
Tests and reviews are just to reduce the number of released bugs. and hopefully increase maintainability.
Also, what's obvious to one developer might not be to another.
> A code review ensures that [...] the implementation fits to the intent of the specification.
I don't see how both of these can be true.
> Functional correctness is typically "proven" by tests.
You can (and, in my view, should) review tests, too.
A code review ensures that the non-functional quality of the code is high. I.e. that the code is understandable/maintainable by someone other than the programmer himself, that there are no anti-patterns or dangerous-but-correct usages of language features, that the implementation fits to the intent of the specification etc.