Fix DEFPACKAGE, reader #:, APROPOS, and DISASSEMBLE ANSI test failures

[blakemcbride]

Fix DEFPACKAGE, reader #:, APROPOS, and DISASSEMBLE ANSI test failures

Summary

Four targeted ANSI-conformance fixes across the package, reader,
apropos, and disassemble subsystems. All originally-targeted tests
pass, and no previously-passing test regresses.

Test	Subsystem
DEFPACKAGE.2B	packages
SYNTAX.SHARP-COLON.ERROR.1	reader
APROPOS.ERROR.2	packages
APROPOS-LIST.ERROR.2	packages
DISASSEMBLE.ERROR.3	conditions

Changes

1. DEFPACKAGE :nicknames — accumulate instead of overwrite (defpackage.lisp)

CLHS specifies that multiple :nicknames options are merged
(defpackage "Syntax" under §11.1.2). The ABCL macro was using
setq, so only the last :nicknames clause survived:

(defpackage :foo (:nicknames :a) (:nicknames :b))  ; only :B seen

Fixed by appending the new names to the accumulator, matching the
handling of :shadow, :export, etc.

2. Reader #: token — signal on unescaped package markers (Stream.java)

CLHS 2.4.8.7 requires #:<token> to signal a reader error if the
token contains an unescaped package marker (a colon not preceded by
\ or inside a |…| escape). ABCL previously accepted #:foo:bar
silently and constructed a symbol whose name contained a colon.

Stream.readSymbol now scans the token post-_readToken, consulting
the per-character escape BitSet returned by the tokenizer, and
signals ReaderError on any unescaped :. The check is skipped
when *read-suppress* is true, so READ-SUPPRESS.SHARP-COLON.7
continues to pass (it reads "#::" with *read-suppress* = T and
expects NIL, no error).

3. APROPOS / APROPOS-LIST arity (apropos.lisp)

CLHS defines apropos and apropos-list with the lambda-list
(string-designator &optional package-designator) — two args max.
ABCL exposed a third external-only extension parameter, so the
conformance tests calling them with three arguments (expecting
PROGRAM-ERROR) failed.

Renamed the internal three-arg helper to %apropos-list and
reinstated CLHS-conforming two-arg signatures for the public
apropos and apropos-list. The external-only functionality is
retained for internal callers via %apropos-list.

4. DISASSEMBLE type-error on bad argument (disassemble.lisp)

CLHS specifies disassemble's argument as an extended function
designator — i.e. (or function symbol (cons (eql setf) (cons symbol null))) — and mandates a TYPE-ERROR otherwise.
DISASSEMBLE.ERROR.3 iterates the mini-universe expecting
TYPE-ERROR for everything outside that set, but ABCL accepted
arbitrary junk, often crashing inside disassemble-function.

Added an explicit typep guard that signals TYPE-ERROR with
:datum and :expected-type populated. The accepted type is widened
with (cons (eql lambda) t) so that DISASSEMBLE.3
((disassemble '(lambda (x y) (cons y x))), which expects success)
keeps passing.

Files changed

• src/org/armedbear/lisp/defpackage.lisp — :nicknames
  accumulate.
• src/org/armedbear/lisp/Stream.java — readSymbol unescaped-colon
  check, guarded by *read-suppress*.
• src/org/armedbear/lisp/apropos.lisp — public arity restored;
  internal helper renamed to %apropos-list.
• src/org/armedbear/lisp/disassemble.lisp — typep guard on
  disassemble arg, with lambda-expression allowance.

Test plan

• ant abcl builds cleanly.
• All five targeted tests pass:
  DEFPACKAGE.2B, SYNTAX.SHARP-COLON.ERROR.1,
  APROPOS.ERROR.2, APROPOS-LIST.ERROR.2,
  DISASSEMBLE.ERROR.3.
• Regression guards confirmed green:
  READ-SUPPRESS.SHARP-COLON.7 (reader),
  DISASSEMBLE.3 (lambda-expression acceptance).
• No new failures vs. the pre-change baseline on
  asdf:test-system :abcl/test/ansi/compiled.

Compatibility

No public API breakage. APROPOS/APROPOS-LIST become strictly
CLHS-conforming: callers relying on ABCL's undocumented three-arg
form should switch to SYS::%APROPOS-LIST or filter externally.
Reader behavior for well-formed #: tokens is unchanged; only the
previously-accepted malformed case now errors as CLHS requires.

[easye]

@blakemcbride Thanks for the rush of pull requests. One request though: if you have multiple pull requests outstanding that are not orthogonal (i.e. some add further changes that depend on previous requests) could you please close "older" pull requests possibly with a comment/link to the superseding one? This will help me understand the totality of what you are requesting much better.

Overall, the quality of the patches seems pretty decent. Given the sudden burst of requests, I presume you are using some computer-assisted augmentation? May I ask what sort?

[blakemcbride]

I apologize for the overlapping patches. Truth be told, I didn't realize I did that until after I submitted the pull request. I sort of ran out of time to fix it and submit new pull requests. Your help in untangling and using these pull requests is greatly appreciated. I'll be more careful in the future.

I used Claude Code. I have been using it a lot lately. Although it isn't perfect, it is as good as most developers I've worked with. It makes mistakes as developers do. You test it and give feedback rather than fire them because they're not infallible.

There have been many projects I have been interested in over many years. (See my GitHub repo.) I have wanted to do many things with these packages but just didn't have the time. Now, with Claude Code, I do.

My hope was to correct all ABCL ANSI Standard test issues. Collectively, the patches I provided fixed a good percentage of the issues. My plan is that if the patches are accepted, I will finish the project. It is basically up to your team if I continue. I have been using ABCL for many years as an extension language. I even paid a member of your team to make corrections in the system years ago. I think ABCL is a wonderful system. I would like to contribute to its success.

Thank you!

[easye]

Your help in untangling and using these pull requests is greatly appreciated.

So, if I see things overlapping, I will close with an appropriate comment. This won't necessarily mean rejection for the pull request, as we can debate, revise, and re-open as needed.

[blakemcbride]

I see what is going on. I will close the two pull requests that are duplicates. Thanks.

[blakemcbride]

I closed 741 and 742 since they both exist in 743. All should be straight now. Thanks!

[blakemcbride]

The descriptions in 741 & 742 contain descriptions of the earlier commits in this commit.

[blakemcbride]

I will wait on the merge of these commits in order to continue the work I was doing.

[easye]

3. APROPOS / APROPOS-LIST arity (apropos.lisp)

I think we should keep the current optional arity, documenting as an ABCL extension to ANSI, as the new version doesn't add anything. I will modify this commit.

[easye]

Superseded by #748

[easye]

@blakemcbride Spent some time today working through these changes; it's gonna take me a lot longer to review than I initially thought. I feel now like John Henry had a grudging respect for the steam engine.

It would be nice if you tried to urge your augmentation to make smaller commits that make atomic, testable changes. From quick reviews of what you opened today (Tue Apr 21), it seems like you are working on honing your requests in that manner.

Also, it would be great if you put the comments from the Github request into the commit message itself, as Github won't always be around but the commit messages will be. If you open a pull request for a single commit, Github automatically copies the commit message as the starting "Conversation" comments.

[blakemcbride]

I can certainly do that in the future. Are you requesting that I do that for the pull requests that I have already done?

Incidentally, taking all of my pull requests together makes ABCL pass 100% of the standard ANSI CL tests.

[blakemcbride]

You closed this pull request. Did you merge it?