[bugfix] Fixing linting error in macro_tests

[xtinec]

Getting master to green.
@mistercrunch @kristw

[john-bodley]

@mistercrunch it seems there may be merit in having this check enabled to prevent the master branch from failing the CI checks as people may merge PRs which previously passed CI but would fail if they rebased against master.

I realize that this creates some friction, i.e., PR merging becomes a sequential process and the need to rebase (and thus re-run the CI) may slow development, but it seems the safest option for ensuring that we don't have these types of regressions.

[williaster]

+1 for @john-bodley 's comment, broken builds cost a lot of people a significant amount of time so it'd be great to add that check even if it adds a marginal per-PR cost.

[xtinec]

Agree with @john-bodley and @williaster . I think the benefits outweigh the per-PR cost and it actually saves time for those of us in the habit of rebasing. :) Saw the lint error by chance this afternoon after I rebased in an unrelated change. :)

[mistercrunch]

Wait does that mean that every single PR out there needs to be rebased every time another one is merged? If that's the case it seems like a really bad idea. I'm not even sure Travis-CI could take the extra load.

It's pretty rare that stuff like this collide. [working build + working build ~= working build] 95%+ of the time. Picture if I merge this and all other PRs have to be rebased, and we have to wait for CI on all those other builds. This is a lot more time than fixing the very occasional master.

[mistercrunch]

Think about it, it means the merge button is almost never green on all PRs.

[mistercrunch]

Here's another idea to mitigate this. The problem here is "a broken build", which really in most cases the broken build is really just a lint issue related to a bad merge. Maybe the solution is that we should not break the build on lint errors, and instead warn on the PR, and have a policy (either hard or softly enforced) to not merge PRs with lint.

This way, when lint shows up as a byproduct or a merge, it wouldn't break the build, it would just generate a tiny bit of lint for anyone who rebases while in this state, and those who do would fix that one-liner. That would prevent the false-negative "broken build".

[mistercrunch]

@john-bodley @williaster @xtinec I'd love for you all to reconsider this thinking about the burden on all contributors and maintainers that this would involve, and how unscalable process-wise that is (the burden grows quadratically as contributions grows)