Reject abstract members in non-abstract classes

[vinayakj592]

Fixes #1614.

Context

A non-abstract class (or module) was allowed to declare abstract properties and methods.
Because such an enclosing type is instantiable, an abstract member there can never be guaranteed
an implementation — so the contradiction surfaced only as a runtime error when the member was
accessed (Cannot invoke abstract method), or not at all.

This makes it a compile-time error to declare an abstract member unless its enclosing class or
module is also abstract. This is consistent with how Pkl already rejects instantiating an abstract
class, and mirrors how Java and Kotlin treat abstract members.

Before

class Foo {
  abstract bar: Int
}
res = new Foo { bar = 5 }   // evaluated successfully (should fail)

class Foo {
  abstract function bar(): Int
}
res = new Foo {}            // evaluated successfully; res.bar() failed only at runtime

After

–– Pkl Error ––
Cannot define an abstract member in a non-abstract class.

2 | abstract bar: Int
    ^^^^^^^^
at Foo

A member can only be `abstract` if its enclosing class is also `abstract`.

Implementation

• AstBuilder now validates, while building the AST, that a non-abstract class/module declares no
  abstract members. The check runs in both visitClass and visitModule, and the error points at
  the abstract keyword.
• Adds the abstractMemberInNonAbstractClass error message.

Scope: classes and modules

The issue describes classes; I applied the same rule to modules as well, since a module is a class
in Pkl and a non-abstract module is likewise directly evaluatable. Happy to narrow this to classes
only if you'd prefer — it's a one-line change either way.

The moduleMethodModifiers pkl-doc test fixture declared an abstract method at non-abstract module
level (relying on the old behavior); it's updated to an abstract module, and its expected
documentation output is regenerated.

Tests

• New LanguageSnippetTests error cases: abstract property in a class, abstract method in a class,
  and abstract member in a module.
• ./gradlew build passes (pkl-core and pkl-doc included).

[bioball]

Thanks! I think this solution makes sense. Another approach here could have been to defer the abstract check when the member is assigned to or accessed, but this feels more principled and catches obvious bugs earlier.

Note that this doesn't fully address #1614; this still works:

abstract class Foo {
  abstract bar: Int
}

class Qux extends Foo {}

qux: Qux = new {
  bar = 5
}

Waiting for eyes from @HT154 and @stackoverflow before merging this.

[HT154]

LGTM. Like @bioball said, this narrowly addresses #1614 but doesn't cover the related case from #1262, but that's fine to address as follow-up.

[vinayakj592]

Could you help me understand this? I understand your point that it doesn’t cover issue #1262, but I’m not clear on why it also doesn’t fully address issue #1614. Could you explain which parts of issue #1614 remain unresolved?
@HT154 @bioball

[bioball]

@vinayakj592 Class Qux still has an abstract member, because it did not override bar

[vinayakj592]

@vinayakj592 Class Qux still has an abstract member, because it did not override bar

@bioball I see what you're saying, I will cover that while working on #1262 , I think this can be merged irrespective of that.

[bioball]

Yes, agree!

[vinayakj592]

By the way, what does the typical review and merge cycle look like here? How long does it usually take for a PR to get reviewed and merged?

I’m planning to start contributing more actively, so I was also wondering if there are any discussion channels or community spaces apart from GitHub Discussions where contributors collaborate and ask questions.

@bioball

[bioball]

Feel free to join the Pkl community discord (see https://pkl.community/); us maintainers also hang out on there!

This PR is blocked on a review from @stackoverflow.

[vinayakj592]

Thanks @bioball

[stackoverflow]

Look good. Thanks for the contribution.

[bioball]

@vinayakj592 FYI: I explored a solution for #1262 in #1690. I think there's a couple interesting open questions to cover, though (see that PR's description)