api: apply OIIO_NODISCARD to color.h

[luna-y-kim]

Description

Adds OIIO_NODISCARD and OIIO_NODISCARD_ERROR to color.h.
Deprecated functions are left unannotated.

Part of #4781

Assisted-by: Claude / Opus 4.7

Tests

No new tests, only attributes are added.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
  line in the pull request description above.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested in the testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: luna-y-kim / name: Luna Kim (583a325)

[lgritz]

Hi, @luna-y-kim ! The changes in color.h look good to me, but (assuming that you built it and tested it on your side before submitting) I think you got bit in CI by the fact that not all compilers (or versions thereof) actually catch using deprecated functions and issue the error that would stop the build. But others do! So what's happening in the failed tests is that it's finding all the places in our own codebase where we inadvertently failed to check the return results of a function. You'll need to track down those spots and do some appropriate error handling (or, if it really is a case where the result doesn't matter, dispose of it sanely).

[lgritz]

It looks like gcc is not catching the errors, but all the CI jobs that use clang do find them. So if you're using gcc on your own machine, that might be why you didn't see any problems when you did a build.

If you're up for addressing this as well, it seems that we're actually disabling this in src/cmake/compiler.cmake, line 188 (-Wno-unused-result). I think eliminating this line would make the discarded result warnings do the right thing for gcc... but I'm not sure what else it might break! There must be some reason why we put it there originally, but I don't remember why, and maybe it's something that isn't even relevant any more.

If you're up for also solving that mystery...

[luna-y-kim]

Hi, thanks for the explanation. I found all 11 failures are from the same spot ColorConfig::ColorConfig in color_ocio.cpp:810. As a first try, I've added a cast (void) because a constructor can't return the result. However, I see other spots also have the same problem. I'll try to track down those spots and do error handling.

Once I've handled all the discarded-result call sites, I might look at removing -Wno-unused-result from compiler.cmake:188 to see if it's still needed or if it's safe to remove.

[lgritz]

Sounds good. I really don't know what will happen when you remove the -Wno-unused-result. Will be interesting to see if there's still a relevant reason why that is there. It appears to have been there for many, many years, and that code has been through enough some movement and refactoring, so I'm not exactly sure when it was first introduced or why.

[lgritz]

If you are wondering whether to finish the work tonight, or meet the rest of us at the pub, definitely choose the pub! Fixing the last couple errors in the next couple days is fine.