Code Generator: treat abi.encodeCall as no-op when referenced as a bare member

[genisis0x]

Description

Fixes #16612.

solc --bin panics with an internal compiler error when abi.encodeCall is referenced as a bare member expression (not called):

contract C { function f() public { abi.encodeCall; } }

Internal compiler error:
libsolidity/codegen/ExpressionCompiler.cpp(2058): Throw in function ... visit(MemberAccess&)
Unknown magic member.

The abi.* member access branch in ExpressionCompiler::visit(MemberAccess const&) carries a hard-coded set of members that are silently dropped when referenced without a call: encode, encodePacked, encodeWithSelector, encodeWithSignature, decode. encodeCall is missing from this set, so its bare reference falls through to the solAssert(false, "Unknown magic member.") guard. The other members in the same family already no-op without bytecode side effects; this change adds encodeCall to match.

The TypeChecker continues to flag the bare reference with Warning 6133 ("Statement has no effect"), preserving the existing user-visible diagnostic surface.

Tests

• New test/libsolidity/syntaxTests/specialFunctions/abi_encodeCall_member_access.sol exercises the bare abi.encodeCall; reference and asserts the expected Warning 6133 instead of the prior ICE.
• Existing test/libsolidity/semanticTests/specialFunctions/abi_functions_member_access.sol extended to include abi.encodeCall; so the codegen no-op branch is exercised as part of the same semantic round-trip that already covers the rest of the family.

Checklist

• I have read the contributing guidelines and the review checklist
• I have personally reviewed, understood, and tested every change in this PR

AI Disclosure

• No AI tools were used
• AI tools were used (details below)

[cameel]

You are opening a lot of new pull requests while previous ones are still pending (you have 10 now). In some cases (#16710) even for issues that already had a pending fix (#16520).

Unfortunately we have limited bandwidth for reviewing contributions and as you can see there are a lot of PRs pending. ICEs specifically are also quite low priority compared to other things we need to focus on (security issues, SSA CFG, ethdebug, optimizer). Even when the fix seems straightforward, there is a lot of complexity in the compiler and the review effort is not an insignificant portion of the work that goes into it (#16509 is a good example of that). Some of them just have to wait for their turn and flooding us with PRs that will get stale is not helpful.

Can I ask you to limit yourself to one PR at a time? We are not going to be reviewing them all at once anyway. Also, I encourage you to first post about your proposed solution in the issue before you start working on a fix. Very often there are nuances that need to be taken into account and the most straightforward solution may not be the right one. Working them out through a high-level discussion is easier for us than than being forced to deal with all the details in the code immediately.

[genisis0x]

Fair feedback, and apologies — the volume was on me. I got into a habit of opening a PR per ICE / typechecker edge as I worked through them, without weighing the review cost on your side. That's not the right shape for this codebase, especially with the priorities you listed (security, SSA CFG, ethdebug, optimizer) needing the real bandwidth.

I'll do three things:

1. Close Parser: reject invalid UTF-8 in NatSpec doc comments #16710 now — it duplicates the pending Fix crash on invalid UTF-8 bytes in NatSpec comments. ALSO fix missing Token::Illegal handling in switch, giving misleading error to users #16520, which I should have searched for first.
2. Pause on opening anything new. The other nine will wait their turn; I won't bump them, and I won't pile more on top.
3. For any future contribution: post the proposed approach on the issue first and wait for a signal before opening a PR.

Sorry for the noise on your queue.