Do not use wattr_set() if wattr_get() is unavailable

[shugo]

No description provided.

[Copilot]

Pull request overview

This PR adjusts the Curses::Window.color_set implementation/availability to avoid calling wattr_set() on platforms where wattr_get() is not available, preventing incorrect attribute handling and unsupported API usage.

Changes:

• Tighten the compile-time feature guard so the wattr_set()-based implementation is only used when both wattr_set() and wattr_get() are available.
• Remove the fallback branch that called wattr_set(..., attrs=0, ...) when wattr_get() was unavailable, using wcolor_set() instead when supported.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The compile-time guard for defining window_color_set was tightened to require HAVE_WATTR_GET when using HAVE_WATTR_SET, but the later rb_define_method(..., "color_set", window_color_set, ...) guard in this file still uses HAVE_WATTR_SET alone. On platforms where HAVE_WATTR_SET is defined but HAVE_WATTR_GET is not (and HAVE_WCOLOR_SET is also not defined), this will lead to a build failure because window_color_set is not compiled but is still referenced. Please update the rb_define_method guard to match this new condition (or otherwise ensure window_color_set is always available when referenced).

Suggested change

	#if defined(USE_COLOR) && ((defined(HAVE_WATTR_SET) && defined(HAVE_WATTR_GET)) || defined(HAVE_WCOLOR_SET))
	#if defined(USE_COLOR) && (defined(HAVE_WATTR_SET) || defined(HAVE_WCOLOR_SET))

[Copilot]

The #endif comment immediately after this function still reflects the old compile-time condition (HAVE_WCOLOR_SET || HAVE_WATTR_SET), but the opening #if now requires HAVE_WATTR_GET when using HAVE_WATTR_SET. Please update that trailing comment to match the new guard so future edits don't accidentally reintroduce the mismatch.