sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: 'go list -m' wildcards don't work with version queries 
Labels: help wanted,NeedsInvestigation,GoCommand,modules

`go get` supports `...` wildcards, and supports version queries such as `@latest`, and allows the user to combine the two in the obvious way.

`go list -m` supports `...` wildcards, and supports version queries such as `@latest`. However, it errors out when both are used in the same argument. It should not — it should instead interpret those queries analogous to how `go get` does.

```
$ go version
go version devel go1.17-a7e16abb2 Thu Apr 8 07:33:58 2021 +0000 linux/amd64

$ go mod init example.com
go: creating new go.mod: module example.com

$ go get -d golang.org/x/tools/...@latest
go: downloading golang.org/x/tools v0.1.0
go: downloading golang.org/x/sys v0.0.0-20210119212857-b64e53b001e4
go: downloading golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1
go: downloading golang.org/x/net v0.0.0-20201021035429-f5854403a974
go: downloading golang.org/x/mod v0.3.0
go: downloading golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9
go: downloading github.com/yuin/goldmark v1.2.1
go get: added golang.org/x/tools v0.1.0

$ go list -m golang.org/x/tools/...
golang.org/x/tools v0.1.0

$ go list -m golang.org/x/tools@latest
golang.org/x/tools v0.1.0

$ go list -m golang.org/x/tools/...@latest
go list -m: golang.org/x/tools/...@latest: malformed module path "golang.org/x/tools/...": invalid path element "..."

$
```

I noticed this while updating `go list` for #36460.

CC @jayconrod @matloob
Repository: godot
Issue: stylebox visibility problem with expand_margin beyond screen border
Labels: bug,confirmed,topic:gui

**Godot version:**
3.2.3, but also verified in 3.3 (rc8?)


**OS/device including version:**
Windows 10, GLES3 (but I don't think it matters)

**Issue description:**
I noticed panels in my game disappearing when getting close to the edge of the screen. The cause is that I use expand_margin property in StyleBoxFlat, when the panel goes outside the screen border the object is culled, and no longer drawn, despite the fact that the expand_margin would put it still on screen.

This is similar to #34432, but distinct in that this can be reproduced without invoking shaders.

Are there any known workarounds for this?
I don't need the objects out of view to be hidden automatically since my scene is small, so if there's a way to disable the culling that'd be fine.

**Steps to reproduce:**
Place a panel outside of the camera view in a 2d scene. Add StyleBoxFlat, and give it a large expand margin so it should be visible. Observe it is not visible when playing the scene.

**Minimal reproduction project:**
[expand.zip](https://github.com/godotengine/godot/files/6289300/expand.zip)
In this example there are 5 panels that should be in view, but only the first 3 show up.
Repository: terminal
Issue: Launch log in process of Azure Cloud Shell when expiring the access token.
Labels: Help Wanted,Product-Terminal,Issue-Task,Area-AzureShell

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
When the access token for Azure Cloud Shell expires, showing log-in prompt is wanted.

Currently, only an error message which means the token is already expired is shown as the following screenshot if the token is expired.
So the user needs to remove the connection setting once.
![image](https://user-images.githubusercontent.com/4566555/114258890-e22bcc80-9a04-11eb-85c8-e770d126aeae.png)

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
If the token is expired, it's better that the login process restarts again instead of showing the current error message.
Or it's more appropriate that the messages indicate that the connection settings have to be deleted once.

Could you please consider that?

Thanks.
Repository: godot
Issue: Unable to bake lightmap with CSG due to the lack of ability to generate UV2 for CSG nodes
Labels: bug,topic:core,topic:rendering,regression,topic:3d

**Godot version:**
Godot 3.2.4-beta6 to Godot 3.3-rc8

**OS/device including version:**
Windows 10
NVIDIA GeForce GTX 750 Ti
GLES2/GLES3

**Issue description:**

BakedLightmap does not work with CSG nodes. As far as I can tell, this worked up to beta 5.

As far as I can tell the CSG node does not have a UV2 layer. *And I cannot use "Create Outline Mesh" + "Unwrap UV2 for Lightmap/AO" with it (The Mesh option in the toolbar does not appear for CSG nodes).*

**Steps to reproduce:**

- Create new Godot project (GLES2 or GLES3, does not matter).
- Create new Spatial scene.
- Save it, any name.
- Add CSGBox (or any other CSG node) to the scene. *Observe there is no Mesh icon in the bar when the CSG node is selected.*
- Set `use_in_baked_light = true` of the CSG node.
- Add BakedLightmap node (make sure the CGS node is inside).
- Click BakeLightmap, select any path, click "Save".

Result: Message appears "No meshes to bake. Make sure they contain UV2 channel and `Bake Light` flag is on."

Expected Result: The light is baked (which is no light, since we didn't add any, and thus the CSG should appear dark).

**Minimal reproduction project:**
[BakeMeUp.zip](https://github.com/godotengine/godot/files/6289322/BakeMeUp.zip)
Repository: rust
Issue: [ER] After Vec::resize LLVM seems to lose slice length knowledge
Labels: A-LLVM,I-slow,T-compiler

Trying to persuade LLVM to avoid slice bound tests is fun. As usual perhaps I'm missing something. This is an example situation:

```rust
pub fn foo1(data: &mut Vec<u32>, new_len: usize) {
    data.resize(new_len, 0);
    let data = &mut data[.. new_len];
}
```
LLVM leaves a bound test in foo1:
```asm
.LBB2_10:
    lea     rdx, [rip + .L__unnamed_1]
    mov     rdi, r14
    mov     rsi, rbx
    call    qword ptr [rip + core::slice::index::slice_end_index_len_fail@GOTPCREL]
    ud2
```
Adding one assume allows LLVM to remove that slice_end_index_len_fail:
```rust
#![feature(core_intrinsics)]
use std::intrinsics::assume;
pub fn foo1b(data: &mut Vec<u32>, new_len: usize) {
    data.resize(new_len, 0);
    unsafe { assume(data.len() == new_len); }
    let data = &mut data[.. new_len];
}
```
So foo1b suggest us to add an assume at the end of (inside) the Vec::resize method.

Unfortunately it seems that assume isn't enough to allow LLVM to remove an array bound test in a very basic loop (and this prevents the vectorization of the increment of the slice items):
```rust
#![feature(core_intrinsics)]
use std::intrinsics::assume;
pub fn foo2(data: &mut Vec<u32>, new_len: usize) {
    data.resize(new_len, 0);
    unsafe { assume(data.len() == new_len); }
    let mut i = 0;
    while i < new_len {
        data[i] += 1;
        i += 1;
    }
}
```
Apparently beside adding the assume you also need to slice "data" before the loop:
```rust
#![feature(core_intrinsics)]
use std::intrinsics::assume;
pub fn foo2b(data: &mut Vec<u32>, new_len: usize) {
    data.resize(new_len, 0);
    unsafe { assume(data.len() == new_len); }
    let data = &mut data[.. new_len];
    let mut i = 0;
    while i < new_len {
        data[i] += 1;
        i += 1;
    }
}
```
Repository: transformers
Issue: Sequential constraints?
Labels: WIP

fairseq has an implementation of unordered and ordered multi-token constraints: see their [PR](https://github.com/pytorch/fairseq/pull/2402) and [example](https://github.com/pytorch/fairseq/tree/1bba712622b8ae4efb3eb793a8a40da386fe11d0/examples/constrained_decoding).

This is more advanced than the single-token constraints that have been occasionally [requested here](https://github.com/huggingface/transformers/issues/10485) mainly due to the bookkeeping involved; see the papers referenced in the fairseq PR.

Has anyone looked into porting this feature? fairseq's [constraint tracking logic](https://github.com/pytorch/fairseq/blob/master/fairseq/token_generation_constraints.py) looks to be well-factored and could probably be adopted verbatim, license permitting. The beam search modifications ([fairseq implementation](https://github.com/pytorch/fairseq/blob/ee0d5a0f65a25e5f5372776402aac5cb9c4adbf1/fairseq/search.py#L210)) may be able to be implemented as a `LogitsProcessor`, or maybe even just a `prefix_allowed_tokens_fn`, but the papers propose some additional logic around making sure that a partial constraint stays in the beam; I'm not sure whether those hooks are sufficient to implement that logic (or how essential it is to the functionality).

(I've found one [related issue](https://github.com/huggingface/transformers/issues/1163).)
Repository: godot
Issue: OptionButton Font Color Does Not Apply To OptionButton Arrows In Scene
Labels: bug,topic:editor,confirmed,topic:gui

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.2.3
<!-- Specify commit hash if using non-official build. -->

**OS/device including version:** Windows 10 PC (Fairly confident this isn't OS/hardware related, but I can dig up the info if deemed necessary. Quickly switching between GLES2 and GLES3 did nothing.)
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->

**Issue description:** Changing font color of the OptionButton node using a theme shows the arrow icons at the end of the dropdown as updating their color properly in the Theme Editor's preview window, but in when placed into scenes the OptionButton arrows retain their default colors. Expected OptionButton in scene to match OptionButton in the theme editor.

![image](https://user-images.githubusercontent.com/32081610/114273980-62910400-99ea-11eb-8642-1581c459b3e5.png)
![image](https://user-images.githubusercontent.com/32081610/114274003-7dfc0f00-99ea-11eb-9a14-44804f4d7ad6.png)

<!-- What happened, and what was expected. -->

**Steps to reproduce:**
Add a theme that changes font color to any OptionButton node. 

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[Test.zip](https://github.com/godotengine/godot/files/6290038/Test.zip)
Repository: godot
Issue: Class with a member variable with its own type causes a leak
Labels: bug,topic:gdscript

**Godot version:**
3.3.rc8
(master seems to be unaffected)


**Issue description:**
If a class references itself in a variable type, it causes a leak.
Probably related:
#16959
#45986
#46467


**Steps to reproduce:**
Attach the following script to a node and run.
```
extends Spatial

class A:
	var a: A
```

The log is as follows:
```
ERROR: ~List: Condition "_first != __null" is true.
   At: ./core/self_list.h:112
ERROR: ~List: Condition "_first != __null" is true.
   At: ./core/self_list.h:112
WARNING: cleanup: ObjectDB instances leaked at exit (run with --verbose for details).
     At: core/object.cpp:2132
Leaked instance: GDScript:1192 - Resource path:
Leaked instance: GDScriptNativeClass:550
Hint: Leaked instances typically happen when nodes are removed from the scene tree (with `remove_child()`) but not freed (with `free()` or `queue_free()`).
Orphan StringName: ::0::A._init
Orphan StringName: Reference
Orphan StringName: GDScriptNativeClass
Orphan StringName: a
Orphan StringName: res://scene.gd
Orphan StringName: _init
Orphan StringName: GDScript
StringName: 7 unclaimed string names at exit.
```


**Minimal reproduction project:**
[bug_unfreed.zip](https://github.com/godotengine/godot/files/6290097/bug_unfreed.zip)

Run, then close the running project.
Repository: godot
Issue: Theme with alpha value is drawn below inferior CanvasLayer
Labels: bug,needs testing,topic:gui,topic:2d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot Mono 3.2.2 x64
Godot 3.3 rc8 x64


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10 Pro 20H2 Build: 19042.928 x64 
GeForce GTX1050 Ti Driver 465.89


**Issue description:**
<!-- What happened, and what was expected. -->
I'm using a Node2D with a draw function to draw a grid on the screen. The Node2D is inside a CanvasLayer with a layer property set to 0. The GUI is inside a CanvasLayer with the layer set to 1. I intend to draw the grid in the background but when I play, the grid is drawn always above the GUI. I found that the problem occurs only when the Control nodes have a theme and a style with an alpha value below 255.


**Steps to reproduce:**
Run the minimal reproduction project or follow the steps below:

1 - Create a scene with the following structure:
```
Spatial
    MeshInstance
    Camera
    CanvasLayer1
        Button
    CanvasLayer2
       Node2D
```

2 - The CanvasLayer1 layer is set to 1 and the CanvasLayer2 layer is set to 0.
3 - Create a new theme with a button class item, set the normal style to StyleBoxFlat, and set some color with an alpha value less than 255.

4 - Add the following script to Node2D
https://github.com/GDQuest/godot-demos
MIT License

```
extends Node2D

var cell_quadrant_size: int
export var grid_size: Vector2 = Vector2(10, 10)
export var cell_size: Vector2 = Vector2(64, 64)


func _ready():
	modulate = Color( 1, 0.2, 0, 0.2 )
	grid_size = get_viewport_rect().size / 64
	cell_quadrant_size = int(round(grid_size.x))


func _draw():
	var LINE_COLOR = Color(255, 255, 255)
	var LINE_WIDTH = 2
#	var window_size = OS.get_window_size()

	for x in range(cell_quadrant_size + 1):
		var col_pos = x * cell_size.x
		var limit = grid_size.y * cell_size.y
		draw_line(Vector2(col_pos, 0), Vector2(col_pos, limit), LINE_COLOR, LINE_WIDTH)
	for y in range(cell_quadrant_size + 1):
		var row_pos = y * cell_size.y
		var limit = grid_size.x * cell_size.x
		draw_line(Vector2(0, row_pos), Vector2(limit, row_pos), LINE_COLOR, LINE_WIDTH)
```

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[CanvasLayer bug.zip](https://github.com/godotengine/godot/files/6290458/CanvasLayer.bug.zip)
Repository: flutter
Issue: [proposal] Provide a way to render inner shadow on Text
Labels: c: new feature,framework,engine,dependency: skia,a: typography,P3,team-engine,triaged-engine

Like the title, it would be awesome if `TextStyle`, allows handling Inner Shadow and not just for the background.
Repository: create-react-app
Issue: [eslint-config-react-app] mark eslint-plugin-flowtype as an optional dependency
Labels: needs triage,issue: bug report

I’m using `eslint-config-react-app` without `create-react-app`, but I guess this issue also affects users of CRA who have ejected and want to clean up their dependencies:

When using Yarn 2, it is mandatory to install all peer dependencies of modules you depend on. In particular, `eslint-config-react-app` [has a peer dependency](https://github.com/facebook/create-react-app/blob/master/packages/eslint-config-react-app/package.json) on `eslint-plugin-flowtype` which is not marked optional. So anyone using the former with Yarn 2 must install the latter, even if they are not using Flow.

A satisfactory solution would be to mark the peer dependency on `eslint-plugin-flowtype` as optional, so that it doesn’t need to be installed by this (albeit tiny) segment of users.

A temporary fix would be to include the following in `.yarnrc.yml`:

```yml
packageExtensions:
  # awaiting fix: https://github.com/facebook/create-react-app/issues/10809
  eslint-config-react-app@*:
    dependencies:
      eslint-plugin-flowtype: '*'
```
Repository: pytorch
Issue: [JIT] TorchScript to represent typed tensor annotations in IR graph
Labels: oncall: jit

## 🚀 Feature
For scripting tensor annotation, recently added typed tensors (e.g. torch.LongTensor) should be represented in the TorchScript IR with corresponding data type. We the similar request for FloatTensor, etc.

## Motivation
Typed tensor annotation is common in models, e.g.: HuggingFace transformer snippet
Aliasing with data type allows ONNX conversion of graphs for models where data type cannot be propagated from input types.

```
class Encoder(torch.nn.Module):
    def forward(
            self,
            src_tokens,
            hidden: Optional[torch.FloatTensor] = None
    ):
        if hidden is not None:
            src_tokens += hidden

        return src_tokens

script_module = torch.jit.script(Encoder())

graph(%self : __torch__.Encoder,
      %src_tokens.1 : Tensor,
      %hidden.1 : Tensor?):
  %11 : int = prim::Constant[value=1]()
  %4 : None = prim::Constant() # test_onnx.py:1529:29
  %5 : bool = aten::__isnot__(%hidden.1, %4) # test_onnx.py:1529:15
  %src_tokens : Tensor = prim::If(%5) # test_onnx.py:1529:12
    block0():
      %hidden.7 : Tensor = prim::unchecked_cast(%hidden.1)
      %src_tokens.5 : Tensor = aten::add_(%src_tokens.1, %hidden.7, %11) # test_onnx.py:1530:16
      -> (%src_tokens.5)
    block1():
      -> (%src_tokens.1)
  return (%src_tokens)

```
In the model above, if the data type for 'hidden' input is not known, ONNX could use the type annotation information if represented in the TorchScript graph replace %hidden.1 with %hidden.1 : FloatTensor? .

This request is **not** for type propagation.

cc @gmagogsfm
Repository: youtube-dl
Issue: https://mixch.tv/
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.04.07. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2021.04.07**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://mixch.tv/u/16074689/live
- Single video: https://mixch.tv/u/16065330/live



## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

I'm getting this when I'm trying to download.  It used to able to grab the live stream until it changed the interface last month
ERROR: Unsupported URL: https://mixch.tv/u/4963834/live
Repository: rust
Issue: Deleting enum variant unexpectedly changes behavior in match statement
Labels: C-enhancement,A-lints,A-diagnostics,T-compiler,A-patterns,L-unreachable_patterns

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

This came up when I was deleting some variants of a rather large enum. The variants were never used (indeed, the compiler warned me that they were unused), so deleting them should be safe. Much to my surprise, this caused test failures. 

Upon closer inspection, it turned out that although my code never _created_ those enum values, it did _match_ them in a `match` statement (which I had not cleaned up). This caused the reference to that variant in the pattern to turn into a variable, which matched everything.

Here's a simplified example where `B` represents the enum variant[s] deleted.

**I tried this code:**

[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=de11b31273e177377cc31a2466b669e9)

```rust
enum MyEnum {
    A,
    // B, // the assertion below works if B is uncommented
    C,
}

fn to_int(my_enum: MyEnum) -> i32 {
    use MyEnum::*;
    match my_enum {
        A => 1,
        B => 2,
        C => 3,
    }
}

fn main() {
    assert_eq!(3, to_int(MyEnum::C));
}
```

**I expected to see this happen:**

When removing the variant `B` of the enum, I expected the match statement to fail to compile because it still referenced `B`.

**Instead, this happened:**

It compiled with a warning that the `C` variant is unreachable because `B` matches any pattern.

----

This feels like Rust behaving correctly according to the indented behavior, but the intended behavior is confusing. 

I'm not sure if there is anything useful that could be done about this (perhaps disallow capitalized variables in patterns? or replace the warning with an error?).