This brings in a few breaking changes.
One, INVALID_FUNCTION is now 0 instead of -1. This is long overdue.
Plugins should transparently work except in two cases:
1. Third-party extensions that have a hardcoded test for -1 will no
longer work. A new API has been provided for this,
GetFunctionByIdOrNull.
2. If a plugin "framework" uses INVALID_FUNCTION anywhere in its
exported API, then all plugins using that framework need to be
recompiled together, so they agree on the value of
INVALID_FUNCTION.
Hopefully the damage here is minimal. The core plugin version has been
bumped to 7 to try and limit conflicts.
Second, braceless functions are no longer supported. There wasn't really
any way around this and it's better to bite the bullet now. This affects
source compatibility, but not binary compatibility.
Third, the "using" keyword is no longer implemented. SourceMod now has a
Handle methodmap again. Plugins compiled against this new methodmap will
require a "Handle.~Handle" native, which 1.12 now provides.
This imports the brand new SourcePawn compiler. The new compiler is much
faster to compile and generates significantly improved code around
array generation and array access.
There are a number of compatibility changes in the new compiler. Most of
these are due to improved type checking and error detection. The full
list of notes can be found here:
https://github.com/alliedmodders/sourcepawn/blob/master/docs/upgrading-1.11.md
Additionally, .smx files generated by the new compiler will NOT load on
earlier versions of SourceMod, including earlier versions of 1.11. Old
plugins will continue to load as normal.
This bumps the handle bits to 20 and reduces the serial/cookie bits to
12. A warning is emitted if a single owner creates more than 100k
handles.
Tested on mock srcds with sm_dump_handles.
This is a pretty big diff because SourceMod had lots of multi-arch
workarounds that can now go away. I've also changed 'x64' to 'x86_64' in
many places since this is how AMBuild normalizes it, and it's far too
late to pick the shorter string, so we might as well suck it up.
The --target-archs parameter has been replaced with --targets. It works
the same way.
The default behavior for SDK inclusion is now "present" instead of
"all" since this lowers the burden of storing many SDKs. Official builds
will still be made with --sdks=all.
On SDKs which use protobufs, the engine has objects compiled against a specific
version of protobuf. Normally this is fine, we take care on Linux to use the
same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality,
whereas the protobuf library has been compiled with libstc++. These ABIs are
not compatible.
To address the problem, we introduce PbHandle. PbHandle is a wrapper around
protobuf::Message with two added pieces of state: whether or not the handle
"owns" the message (and can free it in its destructor), and whether or not
the handle was created by the engine (private) or created by SourceMod
(local).
Whenever we transfer a protobuf::Message pointer to SourceMod, we must take
care to convert it to a Local version first. Whenever we transfer a protobuf
pointer to the engine, we must convert it to a Private handle.
For platforms with no ABI differences (almost all of them), the handle is a
no-op. The private and local localities are compatible and no translation
takes place.
On macOS, CS:GO does require translation. SourceMod loads a tiny shim
library that contains a copy of the protobuf sources compiled against the
game's ABI. It then provides serialization and deserialization methods.
SourceMod must not interact with the game's protobuf objects without first
going through this proxy library.
Note that PbHandle is not quite like unique_ptr. It can be converted into a
PbHandle that does not destroy the underlying object. This is mainly because
UserMessages.cpp has rather complex state, so it is useful to track locality
without destroying an object. An unowned PbHandle must not outlive the
owning PbHandle.
It turns out this was already enabled on MSVC (due to /EHsc), but let's
enable it on other platforms as well.
Exception handling comes with a huge caveat: SourceMod and SourcePawn
are not exception safe. Not only do they predate usable STL (C++11),
they often predate C++03, and sometimes even C++ itself. There are many
places we do not use RAII, or where we accumulate state in a way that
cannot be interrupted.
By enabling exceptions, we are NOT inviting general try/catch. We are
still assuming that a `throw` anywhere within SourceMod will ultimately
result in a crash.
However, as we enable more and more STL, we are losing the ability to
gracefully handle constructor failures and malloc failures. So try-catch
is now enabled. It should only be used in the narrowest of
circumstances:
- When an exception can be thrown by a library call, and
- There is no way "a priori" to tell if an exception will be thrown
(for example, std::bad_alloc or std::system_error), and
- Handling the exception is meaningful.
Generally malloc failures should not be considered meaningful. Once
memory is exhausted, the program will crash or be OOM-killed, so there's
no point in handling the failure. However, cases where the allocation
amount is variable may be meaningful to handle. A simple example would
be CDataPack, where if a plugin leaks entries, it's better to handle
this gracefully given that vector growth is geometric. Another example
might be reads of a massive file or network request into a buffer.
These cases should be rare, given that memory pressure is usually
fatal to srcds anyway. But if you've decided to handle an exception,
the try-catch block should be as narrow as possible. For example,
the following is erroneous:
ke::Maybe<SomeGiganticThing> object;
try {
object.init();
} catch (const std::bad_alloc&) {
}
`ke::Maybe` is not threadsafe, and this can leak. Basically, do as
little as possible in try blocks, and use them sparingly, because
they're very difficult to audit.
We are also not inviting use of `throw`, as auditing it is even more
complex than try/catch. It is better to abort(), or use boolean
returns and two-stage object initialization.
Our official builds use clang-3.4 (for macOS) and clang-3.8 for Linux.
Linux uses libstdc++-4.9. Make sure these two compilers are being tested
and that libstdc++-4.9 is being used for STL.
Add a macOS builder to get coverage there. This will use a newer
clang than we actually use, but as opposed to the linux builder will
test the platform-specific bits.
Finally, use the latest GCC and clang versions from a bionic image, so
we have some coverage of a popular distribution.
This patch removes almost all of the existing platform-specific
ThreadSupport code, as well as code derived from it. It is now
implemented on top of C++11 threads and is much simpler.
This is the first inclusion of STL in SourceMod. Mac and Windows are
allowed to dynamically link to their respective implementations. On
Linux, libstdc++ is statically linked, except in the cases where it was
already dynamically linked (csgo, blade).
IEventSignal has been retained because sourcemod-curl-extension relies
on it. As written, it is impossible to use as a condition variable,
because the caller does not have access to the underlying mutex. There
is no way to make this API safe or non-racy, so extensions relying on
it should switch to C++11 threads.
ThreadWorker is now pared down and does not interact or inherit from
BaseWorker in any way. Basic functionality has been tested. Since it is
not used anywhere in SourceMod, or seemingly in any repository on
GitHub, it's unclear whether it should even exist. But it has been
tested in this patch.
This change bumps the minimum macOS version to OS X 10.7, and the
minimum C++ standard level to C++14.
David Anderson
