SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes#1480, #1529
This has three major changes to SourcePawn. First, the API now supports the concept of "exceptions". The exception state is a global property of an instance of the SourcePawn VM. Exceptions can be caught or suppressed. Many places in SourceMod have been updated to check exceptions instead of errors.
The new API obsoletes major parts of the embedder API - all but one method of invoking functions is obsoleted, and the debug interface has been scrapped. Extensions using the native API will not be affected, however, ThrowNativeError has been deprecated in favor of ReportError.
Second, the SourcePawn concept of a "stack" has been unified at the API level. A stack frame iterator now iterates over all SourcePawn invocations, rather than the topmost plugin. This makes error handling more consistent and removes another dependency on context-per-plugin.
Finally, the implementation of stack frames has been changed dramatically. Rather than maintain a complicated and expensive return pointer stack, we now rely on the implicit one provided by the CPU. The stack frame iterator now walks the JIT stack directly. This removes many unnecessary bookkeeping instructions from the generated code, in particular making the CALL instruction 40% faster.
These changes required some fair surgery to the JIT. Its error paths are now slightly more complicated, as they have to throw an exception rather than return an error code. In addition, any path that can throw an exception is now responsible for creating an "exit frame", which exists to tell the stack frame iterator about transitions from the JIT to the VM.
Various minor things done to project files
Updated sample extension project file and updated makefile to the new unified version (more changes likely on the way)
Updated regex project file and makefile
--HG--
extra : convert_revision : svn%3A39bc706e-5318-0410-9160-8a85361fbb7c/trunk%401971
