[BUG] @Setter not processed when a setX(Y y) exists

[onacit]

Describe the bug @Setter seems not processed when a setX method with alien type exists.

To Reproduce

@Setter
public class TestBean {

    //public void setError(final String error) {
    //    this.error = error;
    //}

    // compilation error!
    public void setError(final Throwable thrown) {
        setError(Optional.ofNullable(thrown).map(Object::toString).orElse(null));
    }

    private String error;
}

Expected behavior @Setter shouldn't take the setError(Throwable) method as an existing setter for the error property of String type.

Version info (please complete the following information):

• Lombok version: 1.18.22
• Platform

  
  ------------------------------------------------------------
  Gradle 7.4
  ------------------------------------------------------------

Build time: 2022-02-08 09:58:38 UTC Revision: f0d9291c04b90b59445041eaa75b2ee744162586

Kotlin: 1.5.31 Groovy: 3.0.9 Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021 JVM: 11.0.14.1 (Eclipse Adoptium 11.0.14.1+1) OS: Mac OS X 12.2.1 x86_64

**Additional context**
Add any other context about the problem here.

[rzwitserloot]

Wontfix - this is Intentional behaviour.

• Use @Tolerate on your explicit setter to tell lombok that you don't want it to consider this method.
• If you put @Setter on the field, you'd get a warning (telling you that Setter does nothing here). However, you don't get this (again intentional behaviour) when you put it on a class. I don't know how to avoid the confusion here, unfortunately.

The reason this is intentional and we won't be changing it: It's actually rather difficult to attempt to 'figure out' if we should make that setter or not. For two reasons:

• If you have a supertype, say, setError(Object o), you probably don't want lombok to generate a setter as well. Or maybe you do - I bet if I interview 1000 java developers, about 500 of them will be adamant that there is a clear answer to this question, but they won't all agree. Hence, picking a side is highly likely the wrong answer. If you disagree, note that we can't write code for this case in the first place without involving resolution. Which is not an option.
• If you use type bounds, then this gets even more complicated. Is public <T extends String> void setError(T err) reason for lombok not to generate it? I sure hope so, because if we do, that's a compiler error - those 2 signatures clash.
• Now I'm dipping into academics, but, public void setError(String... x) {} - if that exists, should lombok generate one or not? We could legally (it's not a signature clash), but it'd be rather confusing if we did.
• What if, specifically for booleans, there is public void setSomeBool() {this.someBool = true;} - I'm not so sure someone would expect lombok to also make setSomeBool(boolean v). Less of a case, but it doesn't help.

The first 2 bullets on their own are enough, let alone all 4.

For all these reasons, there is no right answer, so we choose not to play: Existence of any method named setFoo regardless of arguments means we don't generate a setter. @Tolerate exists to work around this.