Reenable warning about unscheduled update definitions

[abadams]

and fix associated issues in the tests and apps.

This is an old warning that stopped triggering because it wasn't tested.
We should either remove it, fix the trigger conditions, or perhaps make
it an error. This PR fixes the trigger conditions and fixes all
instances of the warning in our tests and apps.

The warning triggers if you schedule some but not all of the update
definitions of a Func. It's to protect against the common error of only
scheduling the pure definition of something like a summation. The
warning can be suppressed by inserting a call to func.update(idx).

[steven-johnson]

Lots of broken stuff, removing approval

[abadams]

Looks like an llvm master breakage, and an uncovered bug in atomics. I'll investigate.

[steven-johnson]

Looks like an llvm master breakage, and an uncovered bug in atomics. I'll investigate.

Could bit be related to https://reviews.llvm.org/D115955 ? (It was reverted last night, I'm working on getting a repro case for them)

[alexreinking]

The warning can be suppressed by inserting a call to func.update(idx).

Seeing func.update(idx); as a single line in code looks like a discarded expression that shouldn't have a side-effect. I think it would be nicer to read something more like func.update(idx).schedule_default(); or some other verb (:bike: :derelict_house:) that clearly indicates what is happening.

[steven-johnson]

So where do we stand with this? Do we want to land it as-is and hope to do a proper linter tool in the future? Or what?

[alexreinking]

Up to Andrew, I guess. My suggestion was just a suggestion.

[alexreinking]

This looks great! Thanks for indulging me, @abadams 🙂

[steven-johnson]

The Windows failure appears to be a flake, although possibly a real bug (opened issue as #6621). OK to land.