Adding methods to access operand properties via OpOperands and mark outdated methods as deprecated.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This change is causing the following warning when building with clang:
/mnt/vss/_work/1/s/mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp:332:24: error: comparison of integers of different signs: 'std::size_t' (aka 'unsigned long') and 'int64_t' (aka 'long') [-Werror,-Wsign-compare] if (view.index() >= op.getNumInputs()) ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~
Changing the return type of a function is not generally considered a NFC.
It is from the point of view of the compiler: it won't affect its behavior in any way.
A good litmus test is: "do we need a test for this patch?" ; if not then it is likely NFC.
That is a good test, but I don't think it's sufficient. In this particular case, the change causes warnings to be produced by the compiler that previously weren't, so even if no new tests were needed, it is still not a NFC. If the return type is relied upon elsewhere in code, I would expect that is a functional change. If the code never tests the return type, then changing it would be NFC.
In general, I think using NFC less often than strictly possible is better than using it more often, because as someone who looks at relevant commits when I see a failure in my build/tests/etc., I would hope that I can ignore the NFC changes and just focus on changes that are considered functional.