This fix is long coming. For a long time due to the addition of a
global user cache, the on_member_update event would only have the
updated user in the very first dispatch due to a quirk in the reference
only being updated once.
In order to fix this issue two things had to change:
1. There had to be a new event, `on_user_update` to complement
the equivalent member event.
2. Unnecessary copies of User had to be removed to compensate for the
performance hit from the diffing.
While doing these two fixes I also re-evaluated some more unnecessary
copies done during the PRESENCE_UPDATE to add member case while
fetch_offline_members=False is set or due to chunking issues. The
number of copies was brought down from 2 to 1, discounting the original
Member creation. Unsure on the benefits of this one, however.
N.B: this doesn't change the pre-existing behaviour of on_member_update
Certain decorators and functions expect coroutines and raise an
exception when this is not met. Change these to raise the appropriate
TypeError since they can't actually be handled by the user gracefully
anyway.
This allows for URLs to be left alone since they can include markdown
characters and allows for total escaping of all markdown characters
by default to prevent some form of data manipulation.
Instead of raising a whole variety of exceptions, they are now wrapped
into ExtensionError derived classes.
* ExtensionAlreadyLoaded
* Raised when an extension is already loaded in Bot.load_extension
* ExtensionNotLoaded
* Raised when an extension is not loaded, e.g. Bot.unload_extension
* NoEntryPointError
* Raised when an extension does not have a `setup` function.
* ExtensionFailed
* Raised when an extension's `setup` function fails.
* ExtensionNotFound
* Raised when an extension's module import fails.
This causes them to be raised from a new exception named
ArgumentParsingError with 3 children for ease with i18n. This is
technically a breaking change since it no longer derives from
BadArgument, though catching UserInputError will prevent this change
from affecting the user.
This bug was kind of a long one to figure out, as per #1918 documents
the issue had to do with subcommands but the actual adventure in
finding this one was a long one.
The first problem was that Command.cog was for some reason None, which
indicated that a copy was happening somewhere along the way. After some
fiddling I discovered that due to the copies of `Cog.__cog_commands__`
the groups pointed to out-dated versions that got overriden by the new
copies.
The first attempt at fixing this was straightforward -- just remove the
subcommand from the parent and replace it with the newer reference that
we just received. However, this ended up not working due to a strange
mystery where the subcommand being invoked was neither the original
copy nor the new copy residing in `Cog.__cog_commands__`.
Some more investigation later pointed out to me that a copy occurs
during the `Group.copy` stage which calls `Command.copy` for all its
subcommands. After spotting this out I had realised where the
discrepancy comes from. As it turns out, the subcommand copy that was
being invoked was actually a stale one created from `Group.copy`.
The question remained, how come that one was being called? The problem
stemmed from the fact that when the subcommand was copied, the parent
reference pointed to the old parent. Since the old parent was the one
that was getting the new reference, it went practically untouched. This
is because the calling code fetches the child from the parent and the
old parent is nowhere in the call chain.
To fix this issue we needed to update the parent reference, and in
order to do that a temporary lookup table is required pointing to the
latest copies that we have made.
Thus ends a 3.5 hour bug hunting adventure.
Rapptz