sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Add nullable colors to Settings UI
Labels: Issue-Feature,Product-Terminal,Area-SettingsUI

# Description of the new feature/enhancement

The following settings are missing from the Profile > Appearance page in the Settings UI:
- `tabColor`
- `foreground`
- `background`
- `selectionBackground`
- `cursorColor`

This is because the color picker has no way to select "I don't have a color".

# Proposed technical implementation details (optional)

- [ ] Introduce a new control called "nullable color picker" containing...
  - a color picker
  - a checkbox (or toggle button) to inherit from the color scheme
  - (maybe) a dependency property to bind the color from the settings model to the control
- [ ] use that new control in the Profile > Appearance page under a new "Colors" grouping

A minor design is needed for this. Particularly, we need to think about how this should be represented along with inheritance (`SettingContainer`). We want to make sure we don't confuse users with "inherit value from color scheme" and "inherit value from base layer", for example.
Repository: pytorch
Issue: TorchScript can't wrap Python constants in current module
Labels: oncall: jit

## 🐛 Bug

TorchScript, in general, can [use constants defined in Python](https://pytorch.org/docs/stable/jit_language_reference.html#python-defined-constants). It can't, however, capture constants defined in the current module when defining script functions outside of modules.

## To Reproduce
I have `constmod.py`:
```python
from typing import Final

INT_CONST: Final[int] = 3
STR_CONST: Final[str] = "test"
```
And the following code works as expected:
```python
import torch
from typing import Dict
import constmod

@torch.jit.script
def int_func(x):
    return x * constmod.INT_CONST

@torch.jit.script
def str_func(d: Dict[str, torch.Tensor]):
    return d[constmod.STR_CONST] * 7

x = torch.ones(3, 4)
d = {'test': torch.ones(1, 3)}
print(int_func(x))
print(str_func(d))
```
giving:
```
tensor([[3., 3., 3., 3.],
        [3., 3., 3., 3.],
        [3., 3., 3., 3.]])
tensor([[7., 7., 7.]])
```

On the other hand, defining the constants in the same module fails:
```python
import torch
from typing import Final, Dict

INT_CONST: Final[int] = 3
STR_CONST: Final[str] = "test"

@torch.jit.script
def int_func(x):
    return x * INT_CONST

@torch.jit.script
def str_func(d: Dict[str, torch.Tensor]):
    return d[STR_CONST] * 7

x = torch.ones(3, 4)
d = {'test': torch.ones(1, 3)}

print(int_func(x))
print(str_func(d))
```
with the compiler error:
```
RuntimeError: 
python value of type 'int' cannot be used as a value. Perhaps it is a closed over global variable? If so, please consider passing it in as an argument or use a local varible instead.:
  File "torchscript-constants.py", line 9
@torch.jit.script
def int_func(x):
    return x * INT_CONST
               ~~~~~~~~~ <--- HERE
```

## Expected behavior

Since the constants have `Final[*]` annotations in both cases, the TorchScript compiler should recognize them as such and allow their use regardless of where they are defined.

## Environment

 - PyTorch Version (e.g., 1.0):  - OS (e.g., Linux): 1.7.1
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source): n/a
 - Python version: 3.8.5
 - CUDA/cuDNN version: n/a
 - GPU models and configuration: n/a
 - Any other relevant information: n/a

cc @gmagogsfm
Repository: pytorch
Issue: TorchConfig.cmake entries of if(ON) are not accepted by CMake as "true", to be replaced by if(1)
Labels: module: build,triaged

## 🐛 Bug

In TorchConfig.cmake found in libtorch-cxx11-abi-shared-with-deps-1.7.1+cu110.zip in zipped folder share/cmake/Torch entries of `if(ON)` are not accepted by CMake as "true", are parsed as "false". Should be replaced by `if(1)`

## To Reproduce

Steps to reproduce the behavior:

1. Run `cmake .` on a folder with a CMakeLists.txt with `find_package(Torch REQUIRED)`

```
CMake Warning (dev) at /home/dario/temp/libtorch/share/cmake/Torch/TorchConfig.cmake:39 (if):
  if given arguments:

    "ON"

  An argument named "ON" appears in a conditional statement.  Policy CMP0012
  is not set: if() recognizes numbers and boolean constants.  Run "cmake
  --help-policy CMP0012" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.
```

## Expected behavior

if(ON) statements in TorchConfig.cmake being evaluated to "true"

## Environment

```
PyTorch version: 1.7.0
Is debug build: True
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.4 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.17.1

Python version: 3.6 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce GTX 1080
Nvidia driver version: 450.102.04
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.18.5
[pip3] torch==1.7.0
[pip3] torchvision==0.8.1
[conda] Could not collect
```


cc @malfet @seemethere @walterddr
Repository: rust
Issue: Add Path::display_lossy() and display_escaped() methods
Labels: T-libs-api,C-feature-request,A-str

Currently `Path` has:
* a single `display()` method which converts any invalid UTF-8 bytes to REPLACEMENT CHARACTER (U+FFFD)
* a `Debug` impl that always adds quotes and escapes invalid UTF-8 bytes

This can result in some confusion because people that "just want to print a path" may end up inadvertently producing lossy output.

It would be great to:
* add a `display_escaped()` method which is similar to the `Debug` impl if there are invalid UTF-8 bytes, or the current `display()` impl if there aren't. In other words:
  * if there are invalid UTF-8 byte sequences, it adds quotes and escapes those byte sequences
  * if not, then it doesn't add quotes.
* rename `display()` to `display_lossy()` (and perhaps deprecate `display()` in a new Rust edition?)

cc @Manishearth (who requested I file this), @m-ou-se
Repository: go
Issue: x/pkgsite: better discoverability for extension interfaces
Labels: NeedsInvestigation,pkgsite

I was reading https://pkg.go.dev/io/fs, trying to find all the extension interfaces available for fs.FS. I had to scan the entire package API. It would have been even harder had the package not used a consistent naming convention.

Now that the standard library is using it, I suspect we'll see increasing uptake of [the extension pattern](https://go.googlesource.com/proposal/+/master/design/draft-iofs.md#extension-interfaces-and-the-extension-pattern). It'd be nice if pkg.go.dev could recognize it and surface extension interfaces, either through different grouping or through an explicit list at the base interface type.
Repository: TypeScript
Issue: Deprecated tag support for JavaScript and TypeScript in overrides in children
Labels: Suggestion,Awaiting More Feedback

Issue Type: <b>Feature Request</b>

https://code.visualstudio.com/updates/v1_49#_deprecated-tag-support-for-javascript-and-typescript added the great `@deprecated` tag support which works great.

However, when extending a parent class that has a `@deprecated` method, that method is not shown with strikethrough in the child. It would be great if this was the case.

VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.18363
Remote OS version: Linux x64 5.4.0-65-generic


<!-- generated by issue reporter -->
Repository: flutter
Issue: [iOS] Accessibility: provide a "allowsDirectInteraction" property to Semantics
Labels: platform-ios,framework,a: accessibility,c: proposal,P3,team-ios,triaged-ios

I'm currently writing a music application in Flutter. My app shows drum pads on the screen which should react directly, also when voice over is enabled. On iOS I use the following properties on an UIView to achieve that: 

~~~
self.accessibilityElementsHidden = NO;
self.accessibilityViewIsModal = NO;
self.isAccessibilityElement = YES;
self.accessibilityTraits = UIAccessibilityTraitAllowsDirectInteraction;
~~~

In Flutter, I did not find any possibility to configure Semantics to achieve the same effect. Please provide an `allowsDirectInteraction` property on Semantics that realizes the same effect. 

Here is a related issue:
https://github.com/flutter/flutter/issues/3814

Thanks, Gabriel
Repository: vscode
Issue: Menubar access keys are not underlined in native titlebar mode
Labels: bug,upstream,windows,titlebar,menus,confirmed,chromium

Issue Type: <b>Bug</b>

When using the "native" titlebar option, the menubar access keys are not underlined until you press the Alt key.  It should honor the Windows setting for whether to underline access keys.

Really frustrating that in order to be able to see when the app has focus (by using the native titlebar), I can't see the underlined menu items, which is a huge pet peeve.

VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.19041

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (8 x 2712)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>protected_video_decode: unavailable_off<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|23.79GB (16.99GB free)|
|Process Argv|--crash-reporter-id 42431fa7-02b8-4885-aa66-fb6b0034b665 --crash-reporter-id 42431fa7-02b8-4885-aa66-fb6b0034b665 --crash-reporter-id 42431fa7-02b8-4885-aa66-fb6b0034b665 --crash-reporter-id 42431fa7-02b8-4885-aa66-fb6b0034b665|
|Screen Reader|no|
|VM|29%|
</details><details><summary>Extensions (3)</summary>

Extension|Author (truncated)|Version
---|---|---
gitlens|eam|11.2.1
vscode-pull-request-github|Git|0.23.1
cpptools|ms-|1.2.0

(3 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt617cf:30253240
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry244:30256636
pythonvsdeb440:30248342
pythonvsded773:30248341
vstes627:30244334
pythonvspyt600cf:30251589

```

</details>

<!-- generated by issue reporter -->
Repository: godot
Issue: Changing default export value type resets every inherited instance
Labels: bug,topic:editor

**Godot version:**
3.2.3 stable


**OS/device including version:**
Linux


**Issue description:**
I imagine you are going to say this is as expected as it's changing internal data types, but it ends up losing all data without any warning.

Pretend you have a scene with a default export:

```
export var life_span:=10
```

You have created many inherited scenes using this node,e.g.
![image](https://user-images.githubusercontent.com/12863685/108129163-b136b780-70a5-11eb-98b6-907d79c23db3.png)

For many of these instances you have changed the export value of this instance (as you see by the icon changed) and the value:
![image](https://user-images.githubusercontent.com/12863685/108130045-e8f22f00-70a6-11eb-95e0-cbd85aa5f69f.png)

You then go into the code of the master node and change the default from the inferred int as you realised it should have been a float:
```
export var life_span:=10.0
```

What happens, without warning, is every single instance in your scenes that have an override are reset to the default value you just changed it to, and you might not even realised. But you've just wiped out over 100 nodes custom data despite the change not being an invalid cast or a loss of precision. The least I would expect would be a warning, but given the change hasn't affected the data there should be a bit more intelligence...


**Steps to reproduce:**
1. create export int
2. add some instances and override
3. change to float
Repository: go
Issue: io/fs, testing/testfs: disagreement about whether Open(".") must succeed
Labels: NeedsInvestigation

(Sorry for filing all these right around when 1.16 was released, not before. Just bad luck timing.)

I implemented what I thought was the simplest possible empty filesystem: 

```go
func (f *FS) Open(name string) (fs.File, error) {
	return nil, &fs.PathError{Op: "open", Path: name, Err: fs.ErrNotExist}
}
```

It seems to me that according to the `io/fs` docs, this is a valid empty filesystem.

`testing/fstest.TestFS` doesn't like it, though:

```
--- FAIL: TestEmptyFS (0.01s)
    fs_test.go:10: TestFS found errors:
        .: Open: open .: file does not exist
```

Is `TestFS` wrong? Or are there missing docs requiring the file `"."` to be openable?

cc @rsc

P.S. golang.org/s/owners doesn't list any owners for io/fs and testing/fstest.
Repository: go
Issue: x/sys/unix: Capget/Capset writes past struct's memory
Labels: NeedsInvestigation,compiler/runtime

I have a go program that is using unix.Capget/Capset and was randomly crashing.
Thanks to @ianlancetaylor this code was identified as a culprit:
```go
hdr := unix.CapUserHeader{Version: unix.LINUX_CAPABILITY_VERSION_3}
var data unix.CapUserData
unix.Capget(&hdr, &data) // this might write past &data.
```
Turns out that version 2 and version 3 linux capabilities are wider than version 1 capabilities.
Version 1 uses 32bit fields and fit perfectly into a single `unix.CapUserData`:
```go
type CapUserData struct {
	Effective   uint32
	Permitted   uint32
	Inheritable uint32
}
```
However version 2 and version 3 capabilities are 64 bit and do not fit into a single `unix.CapUserData`.
Instead of using a struct with wider fields however linux capget syscall uses the same struct but writes into 2 instances of the struct. It writes lower bits of the capabilities into the first struct and the higher bits into the second one.

So, confusingly the correct way of writing the code above would be:
```go
hdr := unix.CapUserHeader{Version: unix.LINUX_CAPABILITY_VERSION_3}
var data [2]unix.CapUserData
unix.Capget(&hdr, &data[0])
```
Which is normal practice in C, but doesn't look like a typical go to me.
This code would write lower bits into `data[0]` and higher bits into `data[1]`. Then the client would have to be careful when setting capabilities, choosing `data[0]` vs `data[1]` depending on the capability, for example:
```go
data[0].Effective |= 1<<unix.CAP_SYS_ADMIN
data[1].Effective |= 1<<(unix.CAP_CHECKPOINT_RESTORE - 32)
```
Same applies to unix.Capset, except it would *read* past the first struct.

I'm wondering if the signature of `unix.Capget/Capset` should be changed into something like:
```go
func Capget(hdr *CapUserHeader, data *[2]CapUserData) (err error)
```
to prevent issues like this. Such a signature would clearly indicate the amount of memory affected by the syscall.
Or maybe make the fields wider and repack during the call to account for a weird memory layout? That wouldn't work very well though if linux keeps expanding capabilities and would go even wider.
Thoughts?
Repository: pytorch
Issue: Normal_like operator
Labels: triaged,enhancement,module: numpy

## 🚀 Feature: normal_like operator



`aten::normal_(Tensor(a!) self, float mean=0, float std=1, *, Generator? generator=None) -> Tensor(a!) ` does not have a good functionally equivalent op, which makes it hard for backends with limited representation & optimizers. 

Other similar ops - `fill_, randn_, zero_,` all have `_like` operators. The only way to replicate it `normal_` without mutation is the `normal(float mean, float std, int[] size, *, Generator? generator=None, ScalarType? dtype=None, Layout? layout=None, Device? device=None, bool? pin_memory=None) -> Tensor` schema, which requires inserting seven operators into graph, see [here](https://github.com/pytorch/pytorch/pull/52175/files#diff-c098125f9cb12f6523dba61c6eebd88ba0f49914261bc3879b83526c81b49991R45). For consistency with other _like operators, and ease of use for other backends a normal_like operator would be useful.


cc @mruberry @rgommers @heitorschueroff
Repository: godot
Issue: [Mono] Consider warning rather than forbidding keywords when naming an autoload if the name isn't contextually reserved
Labels: enhancement,topic:editor,topic:dotnet

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2.3 mono stable

**OS/device including version:**
Windows 10 (20H2) x64

**Issue description:**
When using the mono build, the autoload manager will request from the script server the list of C# keywords in addition to the list of GDScript keywords.  This list includes a bunch of "contextual" keywords which are not necessarily reserved but nonetheless are forbidden as autoload names.  Despite this, the standard build can use these names and the mono build will run this way without complaining.  In my project, this happened when migrating to C# after the autoload was already named ("global") and is used as a shim on the GDScript side of things.  

In the context of interoperability, preventing a C# keyword (particularly a non-reserved one) for a gdScript autoload name doesn't seem to make sense.  There is no syntax I know of to access the node on the c# side that would utilize any keyword, reserved or otherwise, and I don't know what the difference in behavior can do to break projects if a forbidden name was already selected before opening that project in the Mono build.  


**Steps to reproduce:**
Using the mono build of Godot, attempt to create an autoload using a name from the `CSharpLanguage::get_reserved_words` list which isn't already reserved by GDScript, preferably one from the "contextual keywords" list, such as `global`.  The Add button will be grayed out.  Add using any name you like, then attempt to rename the autoload to a word from the aforementioned list.

**Possible Workaround:**

Manually editing the project file to force the name will probably work, but I haven't checked what kind of undesired behavior this could create in the editor when messing with the autoload.  In my existing project (where it was already named a CSharp "reserved" word before moving to the mono build) it seems to work fine, but I can't create an identical autoload in a new project from inside the editor.
Repository: deno
Issue: Support WebUSB
Labels: web,suggestion

We should support WebUSB.

Ref: https://developer.mozilla.org/en-US/docs/Web/API/USB
Spec: https://wicg.github.io/webusb/

From the spec:

> The software delivery model of the web is a key enabler for educational applications because they can be quickly loaded on any computer without questions of platform compatibility or administrative credentials. Science classes are incorporating computerized measurement and data logging into their lessons. These tools require bundled software that may be difficult to install on managed computers as every new native application adds overhead to an already stressed IT department. Web-based hardware APIs allow support for these devices to be built directly into existing online course materials, providing a completely seamless experience.
>
> Students learning to code with one of the many microcontroller development kits can take advantage of online developer tools to write and upload their code. These tools already exist however they require a native component to interface between the browser and the hardware. These native extensions add a barrier to entry and may expose the user to security vulnerabilities in a way that that code running in the sandboxed web environment does not.

Having WebUSB in Deno would open up whole arena for education, micro controller integration, etc.

Node.js has a couple native modules that provide the bindings, and there are polyfills that layer on top of that to provide WebUSB.  Like we have done with other items, we could just expose WebUSB directly as part of the CLI.
Repository: rust
Issue: Don't build rustc_middle for `x.py build src/tools/rustfmt`
Labels: C-enhancement,T-bootstrap,A-rustfmt,A-contributor-roadblock

Rustfmt only depends on the parser, not type checking, and building rustc_middle greatly increases the time it takes to build.

```
$ x.py build --stage 0 src/tools/rustfmt
Updating only changed submodules
Submodules updated in 0.01 seconds
   Compiling bootstrap v0.0.0 (/home/joshua/rustc2/src/bootstrap)
    Finished dev [unoptimized + debuginfo] target(s) in 12.04s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.15s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling rustc_middle v0.0.0 (/home/joshua/rustc2/compiler/rustc_middle)
   Building [=====================>   ] 195/217: rustc_middle  
```
Repository: vscode
Issue: [FR] Settings to make find-and-replace work like Notepad++
Labels: feature-request,editor-find

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
I am a new user but VS Code is already my favorite text editor, thank you so much to everyone who has worked on it and been part of the community! 🤗

I suggest that some settings should be introduced affecting find-and-replace, unless they already exist; if so, oops.

I want it to be possible to have a combination of settings that makes the following 5 things happen:

1). Maintain any selection in the editor regardless of any operations related to find-and-replace.
2). Automatically repeat the "find in selection" process whenever the find-and-replace interface is opened.
3). Automatically repeat the "find in selection" process whenever the selection is changed while the find-and-replace interface is open.
4). Make the "replace" operation apply only to the current selection, rather than to all lines intersecting the current selection.
5). Do not replace the "find" term with the current selection when opening the find-and-replace interface.

- When I say "find-and-replace," I mean the ctrl+h thing.
- When I say 'repeat the "find in selection" process', I mean mimic the behavior of toggling find-and-replace in selection to "on," except observing 1) and 5)).

Item 5) is already possible by itself, but I don't think the other 4 can currently be achieved. At least two of the others have been discussed (e.g. [2)](https://github.com/microsoft/vscode/issues/95356), [4)](https://github.com/microsoft/vscode/issues/107182)). But I think that these requests, taken together, make find-and-replace work the way that many other users expect, especially new boring corporate users like me.

If I explained everything correctly, this is how it works by default in Notepad++, SQL Server Management Studio, and Excel's VBA editor.
Repository: go
Issue: cmd/compile: imperfect compile error message
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

```go
  package main

  func main() {
    var a, b = 1, -2
    println(a<-b)
  }
```

### What did you expect to see?

```go
syntax error: a is not channel, unexpected <-
```

### What did you see instead?

```
syntax error: unexpected <-, expecting comma or )
```

BTW, `go fmt` doesn't work for much code which fails to compile.
But I think it should work here.