sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Support font family picker in settings
Labels: feature-request,intellisense-config,settings-editor

Currently our font pickers don't know anything about system fonts:

![image](https://user-images.githubusercontent.com/2193314/125141339-a074f580-e0c9-11eb-98c6-f23020bde883.png)

![image](https://user-images.githubusercontent.com/2193314/125141359-b1be0200-e0c9-11eb-813c-06d1bd9b6f4a.png)

By enabling and using the font access API we can provide suggestions for this which is really nice:

![image](https://user-images.githubusercontent.com/2193314/125141432-e7fb8180-e0c9-11eb-9532-ca35f9ec7ae1.png)

![image](https://user-images.githubusercontent.com/2193314/125141389-d0bc9400-e0c9-11eb-8802-8b571aaab925.png)

Unfortunately this doesn't work well currently when syncing across machines and/or using font fallbacks as warnings will appear. For example this is valid on this machine but it throws an error:

![image](https://user-images.githubusercontent.com/2193314/125141523-1bd6a700-e0ca-11eb-8133-657ce4bdd1e2.png)

I've tried a few things but none of them work:

- The [`example` JSON schema property](http://json-schema.org/understanding-json-schema/reference/generic.html) is what we're after, optional suggestions, but we don't seem to support it.
- Using `pattern: '.*'` in combination with `enum` still warns about not matching an enum value.
- This works but is a bit hacky to avoid matching both `oneOf` values and it doesn't show up in the settings UI. `anyOf` doesn't work:
   ```
   oneOf: [
   	{
   		type: 'string',
   		enum: fontFamilies,
   		enumDescriptions: [`The system's default monospace font`],
   	},
   	{
   		type: 'string',
   		pattern: `^(?!(${fontFamilies.join('|')})).*`
   	}
   ]
   ```

Ideally any string value would be accepted and we would have a combobox in the settings editor to allow selecting from a dropdown or manual freeform entry.

@aeschli Am I interpreting `example` correctly and could we update the schema parsing to support it?
@roblourens @rzhao271 If we support `example` could we add a combobox renderer to the settings editor?
Repository: pytorch
Issue: Deprecate torch.(min|max|median|mode) to only return values and not indices
Labels: triaged,module: numpy,module: deprecation,needs design,module: reductions,module: python array api

`torch.min`, `torch.max`, `torch.median` and `torch.mode` return indices along with the values when reducing over one dimension. This is incompatible with the Python Array API Standard as described in the following issue https://github.com/pytorch/pytorch/issues/58745 and furthermore makes it difficult to support reducing over multiple dimensions.

## Alternatives
* a dedicated operator for computing the extra output such as `argmax` that only returns that extra output
* a variant of the function, e.g. `argmax_with_indices`, that returns all output tensors
* an optional parameter `return_indices=True` to explicitly ask for the extra output, although it is discouraged to have operators with multiple possible return types
* an optional out parameter on which to place the extra output, this avoids the return type changing and creating a combinatorial number of variants of the operator. We already support the out= keyword so it might be possible to extend the code to accept extra optional out tensors.

cc @mruberry @rgommers @heitorschueroff @pmeier @asmeurer @leofang @AnirudhDagar @asi1024 @emcastillo @kmaehashi
Repository: rust
Issue: Improve error messages for HashSet with non-Hash type
Labels: A-diagnostics,T-compiler,C-bug,D-newcomer-roadblock

<!--
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.
-->

I ran into a situation with confusing error messages constructing a `HashSet` with a type that doesn't inherit `Hash`.

I tried this code:

```rust
let mut live_in = HashSet::<Temp>::new();
live_in.extend(value.uses.iter())`
```

I expected to see this happen:

The values from `value.uses` to be inserted into the set `live_in`. Or, an error message letting me know what's wrong.

Instead, this happened:

I saw the following error:

```
error[E0599]: no method named `extend` found for struct `std::collections::HashSet<temp::Temp>` in the current scope
  --> src/liveness.rs:88:17
   |
88 |         live_in.extend(value.uses.iter());
   |                 ^^^^^^ method not found in `std::collections::HashSet<temp::Temp>`
```

This error message isn't terribly helpful. It was especially confusing because I had called `extend` on other sets without incident. After searching for a while to figure out what was going wrong, I decided to just try manually inserting the values:

```rust
for temp in &value.uses {
    live_in.insert(*temp);
}
```

This time, I received a considerably more helpful error message:

```
error[E0599]: the method `insert` exists for struct `std::collections::HashSet<temp::Temp>`, but its trait bounds were not satisfied
  --> src/liveness.rs:89:21
   |
89 |             live_in.insert(*temp);
   |                     ^^^^^^ method cannot be called on `std::collections::HashSet<temp::Temp>` due to unsatisfied trait bounds
   | 
  ::: src/temp.rs:14:1
   |
14 | pub struct Temp {
   | --------------- doesn't satisfy `temp::Temp: Hash`
   |
   = note: the following trait bounds were not satisfied:
           `temp::Temp: Hash`
```

Ultimately, the problem was I neglected to implement `Hash` for my `Temp` type. That's obviously a straightforward user error, but also one that I think is reasonably common. The reason I'm filing an issue is I think the error messages could be improved here to help out users better. I suppose what's most surprising to me is that the following line didn't error:

```rust
let mut live_in = HashSet::<Temp>::new();
```

I would have expected the bounds check to happen as the type was being constructed, rather than delaying it until an operation on the value. There's likely some reason to allow construction of `HashSet` with a non-`Hash` type, but the interaction leads to errors that I think are a bit removed from the source.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.53.0 (53cb7b09b 2021-06-17)
binary: rustc
commit-hash: 53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b
commit-date: 2021-06-17
host: x86_64-unknown-linux-gnu
release: 1.53.0
LLVM version: 12.0.1
```
Repository: flutter
Issue: devicelab tests fail when run with -j2 if they don't get to compile the tool
Labels: a: tests,team,team-infra,P2,triaged-infra

These steps fail pretty reliably:
```bash
cd ~/dev/flutter/dev/devicelab
../../bin/dart --version
../../bin/cache/dart-sdk/bin/pub get
../../bin/cache/dart-sdk/bin/pub run test -j2
```

However, if you add this line after the `pub get`, they pass reliably:

```bash
rm -f ../../bin/cache/flutter_tools.*
```
Repository: pytorch
Issue: UCI Data Sets
Labels: feature,module: dataloader,triaged

## 🚀 Feature
It would be very convenient if PyTorch offered UCI data sets (like Iris) similar to torchvision, which offers common data sets.
I just wrote Datasets for Iris, MONKs, BreastCancer, and Adult in the PyTorch / torchvision style. I also have a bunch of other UCI data loaders that I have written in the past and would to share.
Is there a place for them, or is it possible to create a place for such non-vision data sets in the PyTorch?


cc @SsnL @VitalyFedyunin @ejguan
Repository: godot
Issue: Godot forgets UV2 for lightmapping when using "Unwrap UV2 for Lightmap/AO" on an imported 3D scene that doesn't use the Gen Lightmaps setting
Labels: bug,topic:editor,confirmed,topic:import,topic:3d

### Godot version

3.3.2 Stable

### System information

Windows 10 v20H2, Intel i7 6700, Nvidia GTX1080, 16GB RAM

### Issue description

Godot will forget or delete the 2nd UV for lightmaps upon closing and relaunch. This only happens when the 2nd UV is created manually via "Mesh > Unwrap UV2 for Lightmap/AO" after the mesh has been imported.
If "Gen Lightmaps" is set on import, Godot will not forget and the UV2 will be intact on all meshes even after closing and relaunching.

This was only tested on a GLTF binary exported mesh. I am not sure if this occurs in other formats.

### Steps to reproduce

1. Import a GLTF Binary mesh w/ only one UV channel.
2. Do not set "Gen Lightmaps" on import. Keep this on "Disabled".
3. Create a new inherited scene for the mesh.
4. Unwrap UV2 for the mesh and set "Use in Baked Light" to "On".
4. Create a "main scene" with a basic light for the mesh scene to be placed into.
5. Place the mesh scene into the main scene and bake the lightmap. It will work.
6. Close Godot.
7. Reopen Godot and the main scene. Attempt to bake lightmaps, it will fail and say that no meshes in the scene are set up for lightmapping.
8. Reopen the mesh scene. Non of the meshes will have a UV2 anymore.

If "Gen Lightmaps" is on when the meshes are imported, Godot will remember UV2 on every mesh upon reopening.

### Minimal reproduction project

When this file was created, the cube mesh had UV2 unwrapped for baking inside Godot and a lightmap was created in the way detailed above. It was closed and reopened, and the UV2 was apparently deleted.
To test this file, create a 2nd UV for the cube mesh in the "Mesh_Scene.tscn". Save and bake a lightmap from "Main_Scene.tscn". Close and reopen Godot and attempt to bake again from Main_Scene.
[Godot UV2 Example.zip](https://github.com/godotengine/godot/files/6794624/Godot.UV2.Example.zip)
Repository: neovim
Issue: Vim `TRUE` is not Lua `true`
Labels: enhancement,documentation,lua

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: v0.5.0

Like the title says, VimL functions that return `TRUE` and `FALSE` are turned into numbers in Lua.  That would be fine in other languages but in this case, Lua treats `0` as true which makes it tedious to use said functions and also quite surprising and error-prone in case you forget.

At this point, I don't think this is fixable, there's a lot of code that checks against `1` and `0` that'd just instantly break.  However, I think there should at least be some warning in the docs.
Repository: node
Issue: http request will hang forever
Labels: https

### Version

v15.10.0

### Platform

Darwin Lis-iMac.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64

### Subsystem

macos catalina 10.15.7

### What steps will reproduce the bug?

```js
const https = require('https');

async function main() {
  const options = {
    hostname: 'www.dhgate.com',
    port: 443,
    path: '/product/magnetic-liquid-eyeliner-magnetic-false-eyelashes/481362313.html',
    method: 'GET',
    headers: {
      accept:
        'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9',
      'accept-language': 'en',
      'user-agent':
        'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36',
    },
  };
  const req = https.request(options, (res) => {
    console.log('statusCode:', res.statusCode);
    console.log('headers:', res.headers);

    res.on('data', (d) => {
      process.stdout.write(d);
    });
  });
  req.on('error', (e) => {
    console.error(e);
  });
  req.end();
}

main();

```

### How often does it reproduce? Is there a required condition?

No matter what system it will happen

### What is the expected behavior?

receive the information returned by the server normally

### What do you see instead?

hang forever

### Additional information

I have tried many versions of nodejs, but none of them are normal.
Repository: godot
Issue: Alignment issue for text selection with Tree
Labels: bug,topic:gui

### Godot version

3.3.2

### System information

Win

### Issue description

![image](https://user-images.githubusercontent.com/72134064/125160670-120a7d80-e176-11eb-896d-623b6434c3f6.png)

The selection box is not correctly aligned to the content, at least for the letter (a) there. The other letters are fine. As I haven't done any code for selections or fonts etc yet, this is godot defaults.

Edit: Only seems to happen on the first item. I suspect it's because the first cell isn't as wide because of the folding arrow. Even though I've disabled the folding arrow. (I've not implemented any code for cell/column sizes yet).

### Steps to reproduce

See Attached. It's just a basic table that I'm trying to hack up. There's no styling etc used; pretty much everything is still default.



### Minimal reproduction project

[align.zip](https://github.com/godotengine/godot/files/6795097/align.zip)
Repository: rust
Issue: rustdoc: Tracking issue for `--no-run`
Labels: T-rustdoc,C-tracking-issue,A-doctests

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Add the flag (https://github.com/rust-lang/rust/pull/83857)
- [x] Update libtest not to say "ok" for tests which aren't run (https://github.com/rust-lang/rust/pull/83857#discussion_r609784055)
- [x] Fix the flag to actually work (https://github.com/rust-lang/rust/issues/88110)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) - rustdoc's documentation lives in `src/doc/rustdoc`.
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

- [ ] Is `--no-run` the right name?

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- [x] Initial implementation (https://github.com/rust-lang/rust/pull/83857)

<details><summary>original issue text</summary>

The cargo issue here https://github.com/rust-lang/cargo/issues/6424 points out that we don't have a tracking issue on the librustdoc side for how we can make doc examples compile when we run `cargo check --all-targets` or `cargo build --all-targets`. By hook or by crook it would be great to remove this surprising edge case.

Also probably even more surprising `cargo test --no-run` also doesn't compile the doc tests.

Maybe we need a `cargo test --sligtly-run-doctests`?

</details>
Repository: godot
Issue: BakedLightmap ignores ShaderMaterial
Labels: topic:rendering,documentation,topic:3d

### Godot version

3.3.2.stable

### System information

Windows 10, GeForce GTX 950, Intel Core i3-6100, GLES3

### Issue description

BakedLightmap ignores ShaderMaterial and seemingly uses the default material instead

Two materials with red albedo (no red light is being reflected from ShaderMaterial):
![image](https://user-images.githubusercontent.com/33999931/125161288-235d8500-e18a-11eb-8fe4-28d79620365a.png)


Two emissive materials compared:
![image](https://user-images.githubusercontent.com/33999931/125161166-73881780-e189-11eb-8998-0543ed9bbdba.png)

Converting a SpatialMaterial to ShaderMaterial will still not work.

### Steps to reproduce

Create a mesh in an external program like blender, as the built in MeshInstance shapes cannot used for baking.

Create a ShaderMaterial or convert a SpatialMaterial with some color as the albedo/emission, put it on that mesh and bake lighting (in such a way as to see the reflected/emitted light on a nearby surface).

### Minimal reproduction project

[blism.zip](https://github.com/godotengine/godot/files/6795140/blism.zip)
Repository: pytorch
Issue: [feature request] Exact euclidean distance transform
Labels: triaged,function request,module: distance functions

## 🚀 Feature

A GPU based implementation of the exact euclidean distance transform (n-D). 

## Motivation

The CPU computation of this transform is slow and given the importance and wide use of the distance transform of binary images in various computer vision applications, including Hausdorff distance based loss, Boundary ... an pytorch version on GPU would be really helpful.

## Pitch

Similar to the [scipy](https://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.ndimage.morphology.distance_transform_edt.html)

cc @jbschlosser @bhosmer @cpuhrsch
Repository: flutter
Issue: How to use FlutterEngineGroup correctly in debug mode？
Labels: engine,d: examples,perf: speed,P2,team-engine,triaged-engine

take a look!
[#779](https://github.com/flutter/samples/issues/779)
Using FlutterEnginGroup in a debug environment is a torture.
Repository: godot
Issue: Output and Search Results panels aren't the same height when opened
Labels: bug,topic:editor

### Godot version

3.3.2.stable.official

### System information

Windows 10

### Issue description

The *Output* panel

![image](https://user-images.githubusercontent.com/87089854/125170892-2c118380-e1a9-11eb-8fac-e1fdf7c1fa0b.png)

and the *Search Results* panel

![image](https://user-images.githubusercontent.com/87089854/125170921-5a8f5e80-e1a9-11eb-873f-1148bc9aab91.png)

aren't the same height when opened because of their text areas' heights

![image](https://user-images.githubusercontent.com/87089854/125170958-81e62b80-e1a9-11eb-8292-3f2dd49c3786.png)

and their labels' heights

![image](https://user-images.githubusercontent.com/87089854/125171038-f02aee00-e1a9-11eb-96e0-774021170783.png)

This likely happens with other panels too.

### Steps to reproduce

In the Editor, open the *Output* panel, make sure it is at its default/minimum size, and then open the *Search Results* panel.

### Minimal reproduction project

_No response_
Repository: transformers
Issue: Add Flax Models to Pipelines
Labels: Feature request

# 🚀 Feature request

Hi y'all, I am trying a GPTNeo Flax model and am wanting to use it in the text generation pipeline. However, it is currently not supported. From looking at the current implementation of flax models and the text generation pipeline, it should be a relatively easy (famous last words) addition.

## Motivation

HF is heavily integrating Flax models (which I think is awesome!) into the library and has parroted many of the already existing parts of the transformers library to flax models, similar to what was done for TF models. The addition of the support of Flax models in the pipeline API will help those who are working with pure Flax models, especially for applications that will be use the model to accomplish some task.

## Your contribution

I would be willing to open a PR if one is not currently underway (I looked for one and didn't find any). However, I am new to flax so if the task is more difficult than I expect I probably will be not able to complete it.
Repository: pytorch
Issue: What is find_package(Torch REQUIRED) doing that a manual include/glob doesnt?
Labels: module: build,triaged

In my project, if i do 
```
set(CMAKE_PREFIX_PATH "...lib/python3.6/site-packages/torch/share/cmake/Torch")
find_package(Torch REQUIRED)
add_library(lib SHARED "lib.hpp" "lib.cpp")
target_link_libraries( lib  ${TORCH_LIBRARIES})
```
It all links and works great!

But, if I do the following manually, 

```
file(GLOB TORCH_LIBRARIES ".../lib/python3.6/site-packages/torch/lib/*.so")
include_directories(".../python3.6/site-packages/torch/include/torch/csrc/api/include/"
"...lib/python3.6/site-packages/torch/include")
add_library(lib SHARED "lib.hpp" "lib.cpp")
target_link_libraries( lib  ${TORCH_LIBRARIES})
```

It fails when i try to load the library with:
```
liblib.so: undefined reference to `c10::detail::torchInternalAssertFail(char const*, char const*, unsigned int, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
```

What is find_package(Torch) adding that i am missing?

EDIT:

So it appears that despite include torchlib.so on my own (which that glob command does), the linker doesnt include `libtorch.so`

cc @malfet @seemethere @walterddr
Repository: transformers
Issue: GPTNeo Error Attempting to Generate Text
Labels: WIP

## Environment info

- `transformers` version: 4.9.0.dev0
- Platform: Linux-5.4.0-1043-gcp-x86_64-with-glibc2.29
- Python version: 3.8.10
- PyTorch version (GPU?): 1.9.0+cpu (False)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): 0.3.4 (tpu)
- Jax version: 0.2.16
- JaxLib version: 0.1.68
- Using GPU in script?: no
- Using distributed or parallel set-up in script?: no
- Using TPU: Yes

### Who can help
@patil-suraj and @patrickvonplaten

Models:
GPTNeo

Library:

- flax transformers

 -->

## Information

Model I am using (Bert, XLNet ...): GPTNeo


## To reproduce

Steps to reproduce the behavior:

Here is a Google Colab for reproducing: https://colab.research.google.com/drive/1tba52h5t-BP3g13FMdPXVjKqpoLTlGvP?usp=sharing

For convenience here is the error msg:
```
TypeError: dynamic_update_slice update shape must be smaller than operand shape, got update shape (1, 45) for operand shape (1, 20).
```

I was originally getting the same error as #12081. However, when I attempted to implement the same fix as in that issue, I got the above error. The error might be because I am using the "ForCausalLM" version of GPTNeo. However, there is no LMHead version

## Expected behavior
Generate the output sequence
Repository: go
Issue: x/vuln/cmd/govulncheck: type propagation can produce confusing results
Labels: NeedsInvestigation,vulncheck or vulndb

Type propagation appears to taint some functions in the call graph, causing them to be reported as vulnerable, sometimes shadowing the actual results.

The example below is a quite basic example of this. Because `VulnerableImplementation` flows from `EntryB` through `EntryA`, the latter is reported as vulnerable, shadowing `EntryB`, since we try to only show a single finding per vulnerability. Removing `EntryB` causes nothing to be reported.

I suspect this will also lead to more confusing results, where it is less obvious how the type is being propagated, tainting a function.

cc @zpavlinovic

```
package example

import "vuln"

type OrdinaryInterface interface {
	F()
}

func EntryA(oi OrdinaryInterface) {
	oi.F()
}

func EntryB() {
	var oi OrdinaryInterface
	oi = &vuln.VulnerableImplementation{}
	EntryA(oi)
}
```

```
package vuln

type VulnerableImplementation struct {}

func (vi *VulnerableImplementation) F() {}
```

```
[
    {
        "id": "GO-EXAMPLE",
        "package": {
            "name": "vuln",
            "ecosystem": "Go"
        },
        "ecosystem_specific": {
            "symbols": [
                "VulnerableImplementation.F"
            ]
        }
    }
]
```

```
Trace:
vuln.VulnerableImplementation.F (/Users/roland/vulncheck-permissive/main.go:10:6)
example.OrdinaryInterface.F(...) [approx. resolved to (*vuln.VulnerableImplementation).F] (/Users/roland/vulncheck-permissive/main.go:10:6)
example.EntryA(...) (/Users/roland/vulncheck-permissive/main.go:9:6)

Vulnerabilities:
vuln ()
```