internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: Rapptz/discord.py

Issue:
Channel overwrites are not changed if the overwrite dictionary is empty
### Summary

Channel overwrites are not updated if the passed dictionary is empty.

### Reproduction Steps

1. Take a channel with no permissions, and add a permissions override for a specific member.
2. Create a command to remove that permission overwrite, like so:
```py
async def remove_overwrite(self, ctx, channel: discord.TextChannel, member: discord.Member):
    overwrites = channel.overwrites.copy()
    overwrites.pop(member) # overwrites would now be {}
    await channel.edit(overwrites=overwrites)
```
3. Run the command.

### Expected Results

The member overwrite is removed.

### Actual Results

Nothing changes.

### Checklist

<!-- Put an x inside [ ] to check it, like so: [x] -->

- [x] I have searched the open issues for duplicates.
- [x] I have shown the entire traceback, if possible.
- [x] I have removed my token from display, if visible.

### System Information

- Python v3.8.5-final
- discord.py v1.4.1-final
- aiohttp v3.6.2
- system info: Windows 10 10.0.19041



Discussion:

Resolving patch:
diff --git a/discord/abc.py b/discord/abc.py
--- a/discord/abc.py
+++ b/discord/abc.py
@@ -274,7 +274,7 @@ async def _edit(self, options, reason):
             await self._move(position, parent_id=parent_id, lock_permissions=lock_permissions, reason=reason)
 
         overwrites = options.get('overwrites', None)
-        if overwrites:
+        if overwrites is not None:
             perms = []
             for target, perm in overwrites.items():
                 if not isinstance(perm, PermissionOverwrite):


Test patch:
Repository: Rapptz/discord.py

Issue:
channel.permissions_synced is always False if any category overwrites are set
### Summary

`channel.permissions_synced` is always `False` if any permission overwrites are set in the channel's category, even if the channel's permissions are synced.

### Reproduction Steps

1. In Discord, create a new category and create a text channel within it.
2. Check the value of `channel.permissions_synced` for the text channel. (`True`)
3. In Discord, set any permission overwrite for the category and make sure the text channel's permissions are still synced.
4. Again, check the value of `channel.permissions_synced` for the text channel.

### Expected Results

In step 4, `channel.permissions_synced` should be `True`, because the permissions are still synced.

### Actual Results

`channel.permissions_synced` is `False`.

### Checklist

- [x] I have searched the open issues for duplicates.
- [x] I have shown the entire traceback, if possible.
- [x] I have removed my token from display, if visible.

### System Information

```
- Python v3.7.3-final
- discord.py v1.4.1-final
- aiohttp v3.6.2
- system info: Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26)
```


Discussion:

Resolving patch:
diff --git a/discord/abc.py b/discord/abc.py
--- a/discord/abc.py
+++ b/discord/abc.py
@@ -440,7 +440,7 @@ def permissions_synced(self):
         .. versionadded:: 1.3
         """
         category = self.guild.get_channel(self.category_id)
-        return bool(category and category._overwrites == self._overwrites)
+        return bool(category and category.overwrites == self.overwrites)
 
     def permissions_for(self, member):
         """Handles permission resolution for the current :class:`~discord.Member`.


Test patch:
Repository: Rapptz/discord.py

Issue:
"abc.Messageable.send" ignores "allowed_mentions" when "file" kwarg is specified
## Summary

"abc.Messageable.send" ignores "allowed_mentions" when "file" kwarg is specified

## Reproduction Steps

```py
file = discord.File(BytesIO())
await ctx.send(ctx.author.mention, file=file, allowed_mentions=discord.AllowedMentions(users=False))
```

## Expected Results

User was not mentioned

## Actual Results

User was mentioned


## Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.

## System Information

```
- Python v3.8.5-final
- discord.py v1.4.1-final
- aiohttp v3.6.2
- system info: Linux 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020
```



Discussion:
Are you sure that you are using discord.py v1.2.5? The ``allowed_mentions`` keyword was [not added until version 1.4](https://discordpy.readthedocs.io/en/latest/api.html#discord.abc.Messageable), which should raise a ``TypeError`` as you are passing an unexpected keyword argument if you were actually using v1.2.5.

It seems that in 1.4. and onwards ``abc.Messageable.send`` does indeed not handle ``allowed_mentions`` when passing a file. This persists through recent commits. [See line 880 in abc.py](https://github.com/Rapptz/discord.py/blob/master/discord/abc.py#L880).

Adding the ``allowed_mentions`` keyword to the line in question should fix this.

Resolving patch:
diff --git a/discord/abc.py b/discord/abc.py
--- a/discord/abc.py
+++ b/discord/abc.py
@@ -877,7 +877,7 @@ async def send(self, content=None, *, tts=False, embed=None, file=None,
                 raise InvalidArgument('file parameter must be File')
 
             try:
-                data = await state.http.send_files(channel.id, files=[file],
+                data = await state.http.send_files(channel.id, files=[file], allowed_mentions=allowed_mentions,
                                                    content=content, tts=tts, embed=embed, nonce=nonce)
             finally:
                 file.close()


Test patch:
Repository: Rapptz/discord.py

Issue:
Voice Client average latency issue
**Summary**

Voice Client average latency zero division error

**Reproduction Steps**

For the first 5~ seconds after joining a voice channel (until the first heartbeat ack), the `average_latency` property results in a `ZeroDivisionError`.

```py
async def join(ctx):
    voice_channel = ctx.author.voice.channel
    if voice_channel:
        await voice_channel.connect()
        print(ctx.guild.voice_client.average_latency)
```

**Expected Results**

Return `float('inf')` if there have been no heartbeat acks, just as it would if there was no heartbeat at all.

**Actual Results**

The bot attempts to calculate average -- `sum(recent_acks) / len(recent_acks)` -- resulting in `ZeroDivisionError`.

**Intents**

default intents

**System Information**

- Python v3.9.0-final
- discord.py v1.6.0-final
- aiohttp v3.6.3
- system info: Windows 10 10.0.19041

**Checklist**

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.




Discussion:
I could reproduce it

Resolving patch:
diff --git a/discord/gateway.py b/discord/gateway.py
--- a/discord/gateway.py
+++ b/discord/gateway.py
@@ -876,7 +876,7 @@ def latency(self):
     def average_latency(self):
         """:class:`list`: Average of last 20 HEARTBEAT latencies."""
         heartbeat = self._keep_alive
-        if heartbeat is None:
+        if heartbeat is None or not heartbeat.recent_ack_latencies:
             return float('inf')
 
         return sum(heartbeat.recent_ack_latencies) / len(heartbeat.recent_ack_latencies)


Test patch:
Repository: Rapptz/discord.py

Issue:
Add mutual guild method to user class
### There is no simple way to quickly get the servers you share with a Member

Bot which helps users identify people who they share lots in common with on a server.

### The Ideal Solution

Adding a method to the Member class:
https://discordpy.readthedocs.io/en/latest/api.html#discord.Member
This would be the best and most obvious place to put it.

### Summary

Add a method to a User object to return a list of guilds you share in common



Discussion:
Would be O(n) since the way to do this gets slower the more guilds the bot is connected to.
There's a couple things-
It's relatively easy to implement at a user level, `[g for g in client.guilds if g.get_member(id)]`, and it doesn't quite work when you introduce sharding beyond a single process. That could be considered an out of scope problem, but it's there. 

Resolving patch:
diff --git a/discord/user.py b/discord/user.py
--- a/discord/user.py
+++ b/discord/user.py
@@ -707,6 +707,18 @@ def dm_channel(self):
         """
         return self._state._get_private_channel_by_user(self.id)
 
+    @property
+    def mutual_guilds(self):
+        """List[:class:`Guild`]: The guilds that the user shares with the client.
+
+        .. note::
+
+            This will only return mutual guilds within the client's internal cache.
+
+        .. versionadded:: 1.7
+        """
+        return [guild for guild in self._state._guilds.values() if guild.get_member(self.id)]
+
     async def create_dm(self):
         """Creates a :class:`DMChannel` with this user.
 


Test patch:
Repository: Rapptz/discord.py

Issue:
HelpCommand.VerifyChecks Tribool - Always, only in guild context, never
### The Problem

I would like it so I can achieve the following without having to make my own help implementation if possible:

 - If a user triggers help from a guild, the bot will verify checks when generating help (send to DMs or context dependant on option still)
 - If a user triggers help from DMs, the bot will ignore checks and show all commands

### The Ideal Solution

Make [HelpCommand.verify_checks](https://discordpy.readthedocs.io/en/rewrite/ext/commands/api.html#discord.ext.commands.HelpCommand.verify_checks) a Tribool with the following occurring:

 - True: Always verify checks
 - None: Only verify in guild context
 - False: Never verify

### The Current Solution

I'm trying to avoid using guild only checks and instead, writing them as part of the command so that they will still show in help if triggered from DMs.

### Summary

HelpCommand.VerifyChecks Tribool - Always, only in guild context, never



Discussion:

Resolving patch:
diff --git a/discord/ext/commands/help.py b/discord/ext/commands/help.py
--- a/discord/ext/commands/help.py
+++ b/discord/ext/commands/help.py
@@ -272,9 +272,13 @@ class HelpCommand:
     show_hidden: :class:`bool`
         Specifies if hidden commands should be shown in the output.
         Defaults to ``False``.
-    verify_checks: :class:`bool`
+    verify_checks: Optional[:class:`bool`]
         Specifies if commands should have their :attr:`.Command.checks` called
-        and verified. Defaults to ``True``.
+        and verified. If ``True``, always calls :attr:`.Commands.checks`.
+        If ``None``, only calls :attr:`.Commands.checks` in a guild setting.
+        If ``False``, never calls :attr:`.Commands.checks`. Defaults to ``True``.
+
+        ..versionchanged:: 1.7
     command_attrs: :class:`dict`
         A dictionary of options to pass in for the construction of the help command.
         This allows you to change the command behaviour without actually changing
@@ -568,11 +572,15 @@ async def filter_commands(self, commands, *, sort=False, key=None):
 
         iterator = commands if self.show_hidden else filter(lambda c: not c.hidden, commands)
 
-        if not self.verify_checks:
+        if self.verify_checks is False:
             # if we do not need to verify the checks then we can just
             # run it straight through normally without using await.
             return sorted(iterator, key=key) if sort else list(iterator)
 
+        if self.verify_checks is None and not self.context.guild:
+            # if verify_checks is None and we're in a DM, don't verify
+            return sorted(iterator, key=key) if sort else list(iterator)
+
         # if we're here then we need to check every command if it can run
         async def predicate(cmd):
             try:


Test patch:
Repository: Rapptz/discord.py

Issue:
unexpected allowed_mentions when set on message.send but not on Client
## Summary

In `discord.Client` `allowed_mentions` is not set to anything by default. When a message is sent without specifying `allowed_mentions` but specifying `mention_author`, `allowed_mentions` gets set to an empty dict with `replied_user` set<sup>[1]</sup>.

To put it another way:
```python
if not client.allowed_mentions and not message.allowed_mentions:
    if message.mention_author is None:
        allowed_mentions = discord.AllowedMentions(everyone=True, users=True, roles=True, replied_user=False)
    else:
        allowed_mentions = discord.AllowedMentions(everyone=False, users=False, roles=False, replied_user=message.mention_author)
```
(note: that is pseudocode, not how it actually works)

## Reproduction Steps

Don't set `allowed_mentions` when creating a client. Send a message that has mentions in its text, set `mention_author` to anything other than `None`, and do not set `allowed_mentions`.

## Expected Results

The users mentioned in the message text will be pinged.

## Actual Results

The users mentioned in the message text are not pinged.

## Intents

```python
discord.Intents(guilds=True,members=True,messages=True,reactions=True)
```

## Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.
- [X] I have provided the intents that my bot is using.

## System Information

- Python v3.8.5-final
- discord.py v1.6.0-alpha
    - discord.py pkg_resources: v1.6.0a2705+geb11079
- aiohttp v3.6.2
- system info: Linux 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020

[1]: https://github.com/Rapptz/discord.py/blob/eb11079569570ce991d9468ca40eb8fcf129e0be/discord/abc.py#L889-L899


Discussion:

Resolving patch:
diff --git a/discord/abc.py b/discord/abc.py
--- a/discord/abc.py
+++ b/discord/abc.py
@@ -33,6 +33,7 @@
 from .context_managers import Typing
 from .enums import ChannelType
 from .errors import InvalidArgument, ClientException
+from .mentions import AllowedMentions
 from .permissions import PermissionOverwrite, Permissions
 from .role import Role
 from .invite import Invite
@@ -895,7 +896,7 @@ async def send(self, content=None, *, tts=False, embed=None, file=None,
             allowed_mentions = state.allowed_mentions and state.allowed_mentions.to_dict()
 
         if mention_author is not None:
-            allowed_mentions = allowed_mentions or {}
+            allowed_mentions = allowed_mentions or AllowedMentions().to_dict()
             allowed_mentions['replied_user'] = bool(mention_author)
 
         if reference is not None:


Test patch:
Repository: Rapptz/discord.py

Issue:
Context.channel
### Summary

The type for [Context.channel](https://discordpy.readthedocs.io/en/latest/api.html?highlight=message%20channel#discord.Message.channel) seems to be incorrect in the doc

### Reproduction Steps

See [Context.channel](https://discordpy.readthedocs.io/en/latest/ext/commands/api.html?highlight=context%20channel#discord.ext.commands.Context.channel)

The type shown here is `TextChannel`, although this could also be a `DMChannel`.

### Expected Results

The type for Context.channel should be the same as [Message.channel](https://discordpy.readthedocs.io/en/latest/api.html?highlight=message%20channel#discord.Message.channel) which is `Union[abc.Messageable]`


### Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.

I was unsure which template to use, so I picked this one.


Discussion:

Resolving patch:
diff --git a/discord/ext/commands/context.py b/discord/ext/commands/context.py
--- a/discord/ext/commands/context.py
+++ b/discord/ext/commands/context.py
@@ -229,8 +229,8 @@ def guild(self):
 
     @discord.utils.cached_property
     def channel(self):
-        """:class:`.TextChannel`:
-        Returns the channel associated with this context's command. Shorthand for :attr:`.Message.channel`.
+        """Union[:class:`.abc.Messageable`]: Returns the channel associated with this context's command.
+        Shorthand for :attr:`.Message.channel`.
         """
         return self.message.channel
 


Test patch:
Repository: Rapptz/discord.py

Issue:
Subcommand signature in default help formatter doesn't include group's args
### Summary

When a parent group has arguments, they aren't shown in subcommand's help

### Reproduction Steps

1. Use default help formatter (so just don't specify one at all)
2. Put
```py
class X(commands.Cog):
  @commands.group(invoke_without_command=True)
  async def cogname(self, ctx):
    pass

  @cogname.group()
  async def edit(self, ctx, channel: discord.TextChannel):
    pass

  @edit.group(name='name')
  async def edit_name(self, ctx):
    pass

  @edit_name.group(name='format')
  async def edit_name_format(self, ctx, option: str):
    pass
```
3. Start the bot
4. Try running `[p]help cogname edit name format` (`[p]` being bot's prefix)

### Expected Results

I expected the output to be:
```
[p]cogname edit <channel> name format <option>
```

### Actual Results

The output was:
```
[p]cogname edit name format <option>
```

### Intents

discord.Intents.all()

### System Information

```
- Python v3.8.8-final
- discord.py v1.6.0-final
- aiohttp v3.7.3
- system info: Windows 10 10.0.19041
```

### Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.

Note: When `invoke_without_command` is set to `True`, the signature should continue to not include the arguments of the parent as then, those arguments are not required to run subcommands.


Discussion:

Resolving patch:
diff --git a/discord/ext/commands/help.py b/discord/ext/commands/help.py
--- a/discord/ext/commands/help.py
+++ b/discord/ext/commands/help.py
@@ -437,15 +437,24 @@ def get_command_signature(self, command):
             The signature for the command.
         """
 
-        parent = command.full_parent_name
+        parent = command.parent
+        entries = []
+        while parent is not None:
+            if not parent.signature or parent.invoke_without_command:
+                entries.append(parent.name)
+            else:
+                entries.append(parent.name + ' ' + parent.signature)
+            parent = parent.parent
+        parent_sig = ' '.join(reversed(entries))
+
         if len(command.aliases) > 0:
             aliases = '|'.join(command.aliases)
             fmt = '[%s|%s]' % (command.name, aliases)
-            if parent:
-                fmt = parent + ' ' + fmt
+            if parent_sig:
+                fmt = parent_sig + ' ' + fmt
             alias = fmt
         else:
-            alias = command.name if not parent else parent + ' ' + command.name
+            alias = command.name if not parent_sig else parent_sig + ' ' + command.name
 
         return '%s%s %s' % (self.clean_prefix, alias, command.signature)
 


Test patch:
Repository: Rapptz/discord.py

Issue:
API Reference missing
### Summary

discord.Member.create_dm() is async def, but the API reference says def.

### Reproduction Steps

async def on_message(self, message):
        dmChannel = message.author.create_dm()
	print(type(dmChannel))

It can be reproduced by the user sending a message.

### Expected Results

<class 'discord.channel.DMChannel'> is output

### Actual Results

<class 'coroutine'> is output

### Intents

all intents.

### System Information

- Python v3.8.5-final
- discord.py v1.7.0-alpha
    - discord.py pkg_resources: v1.6.0
- aiohttp v3.7.4.post0
- system info: Linux 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020

### Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shown the entire traceback, if possible.
- [X] I have removed my token from display, if visible.

API Reference version : latest  

<img width="394" alt="discord-issue" src="https://user-images.githubusercontent.com/80200187/111898997-e6e80b00-8a6c-11eb-9543-a1a4d1ad2fd5.png">



Discussion:

Resolving patch:
diff --git a/discord/user.py b/discord/user.py
--- a/discord/user.py
+++ b/discord/user.py
@@ -744,7 +744,9 @@ def mutual_guilds(self):
         return [guild for guild in self._state._guilds.values() if guild.get_member(self.id)]
 
     async def create_dm(self):
-        """Creates a :class:`DMChannel` with this user.
+        """|coro|
+
+        Creates a :class:`DMChannel` with this user.
 
         This should be rarely called, as this is done transparently for most
         people.


Test patch:
Repository: Rapptz/discord.py

Issue:
If a Spotify song being listened to is longer than 128 characters, member.activity returns None instead
Another user was initially having this issue in the discord server, which I then was able to reproduce.

https://open.spotify.com/track/5YnS9oWrGcwf1tgode1F7z?si=bp0Zkk3qSF68yxSZjOuVzA

This song's name is exactly 128 characters long, and if you have it playing while connected to Discord, `member.activity` will correctly return a `discord.activity.Spotify` instance with the song details.

https://open.spotify.com/track/47dPsSo7cEDNkvIOSB4O2k?si=id9VCJHiSiWpedthzYQcUA

This song title, however, is 129 characters long, and if the user is listening to this song while connected to Discord, `member.activity` will always return `None`.

[activity.py](https://github.com/Rapptz/discord.py/blob/rewrite/discord/activity.py#L41) indicates that this may be an intentional limit. Is this a Discord API limitation or an issue with discord.py? If it's an API limitation, perhaps it should be noted in the documentation as this could be an unexpected surprise.


Discussion:
Right. This is an API limitation, not one that has to do with the library. The library just presents the information as-is.
Thanks for the answer! Since it's an API limitation, maybe a note should be added to the documentation somewhere warning of this behaviour?
Music said this well and I feel like it applies to this situation too.
https://github.com/Rapptz/discord.py/pull/1656#issuecomment-428910927

Resolving patch:
diff --git a/discord/member.py b/discord/member.py
--- a/discord/member.py
+++ b/discord/member.py
@@ -192,6 +192,13 @@ class Member(discord.abc.Messageable, _BaseUser):
         If the member left and rejoined the guild, this will be the latest date. In certain cases, this can be ``None``.
     activities: Tuple[Union[:class:`BaseActivity`, :class:`Spotify`]]
         The activities that the user is currently doing.
+
+        .. note::
+
+            Due to a Discord API limitation, a user's Spotify activity may not appear
+            if they are listening to a song with a title longer
+            than 128 characters. See :issue:`1738` for more information.
+
     guild: :class:`Guild`
         The guild that the member belongs to.
     nick: Optional[:class:`str`]
@@ -433,6 +440,12 @@ def activity(self):
         """Union[:class:`BaseActivity`, :class:`Spotify`]: Returns the primary
         activity the user is currently doing. Could be ``None`` if no activity is being done.
 
+        .. note::
+
+            Due to a Discord API limitation, this may be ``None`` if 
+            the user is listening to a song on Spotify with a title longer
+            than 128 characters. See :issue:`1738` for more information.
+
         .. note::
 
             A user may have multiple activities, these can be accessed under :attr:`activities`.


Test patch: