sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: SCM - hard to see the file list visual structure
Labels: ux,scm,under-discussion

<!-- ⚠️⚠️ 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. -->

In the SCM panel, VS Code shows a list of modified files. When there are modified files in multiple directories (especially in a large repo), it can be difficult to navigate and make sense of the list.

VS Code offers two options:

1. View as List
![unnamed](https://user-images.githubusercontent.com/485572/150365531-007c5bf6-0d80-4c8e-8528-a75bfdaa1749.png)

* Lack of visual structure (i.e. difficulty scanning and distinguishing information).
* Hard to see when two files are in the same directory (because the directory names are not aligned).

2. View as Tree
![unnamed](https://user-images.githubusercontent.com/485572/150365499-7a28a880-249b-49db-a2c5-96d28222a40e.png)

* Takes more vertical space.
* Hard to see what’s the full path of a file (e.g. in which directory is content.ts?).
* Easy to get lost after scrolling (the root part is no longer visible).

3. Proposal

I would like to have another rendering of the file list to fix these problems. I understand this might not be better in every case, so it should probably be a 3rd option.

![unnamed](https://user-images.githubusercontent.com/485572/150365516-ab90b63f-62cf-45be-8e72-2b4e8a659397.png)
(not a perfect mock, it's a screenshot from another tool, icons are missing)

* Compared to the screenshot 1, the filename and the path are reversed.
* The part of the path that’s the same as the previous line is greyed out.
* The structure is more obvious.
* It requires horizontal space (this works well when the SCM panel is at the bottom).


Happy to send a PR when the proposal is accepted. I'm also happy to discuss other possible solutions.
Repository: go
Issue: runtime/metrics: add scheduling statistics for go routines
Labels: NeedsDecision,compiler/runtime

For load shedding and monitoring/troubleshooting it's useful to understand how many goroutines are in which state: In particular, I am interested in the states: running, runnable, non-go (syscall/cgo), and blocked.  Right now, the only available metric is /sched/goroutines:goroutines, would it be possible to break that down by state?
Repository: bitcoin
Issue: Feature discussion: partial descriptors/miniscript
Labels: Feature

So far, we effectively have two levels of "solvability" in descriptors:
* `addr()` and `raw()` which can encode scriptPubKey with effectively no solvability information at all
* Everything else, which encodes scriptPubKeys that are fully solvable.

I've long held that there shouldn't be any level in between, in the sense that you shouldn't be using a descriptor if you don't know everything about its construction. I'm starting to think that's not a tenable position:
* Already, key origin information - which may be no less critical than other parts of descriptors for certain roles - is optional. There is no way to force that information to be included, because it may not exist (for non-BIP32-derived keys, for example), but it may also simply be omitted.
* #23480 proposes the introduction of a descriptor like `tr()`, except it encodes the post-tweak key rather than the inner key. This too may be because the information doesn't exist, but it cannot prevent situations where it is simply omitted.
* It has been suggested before (e.g. https://github.com/bitcoin/bitcoin/pull/21365#issuecomment-793027851) to permit `tr()` descriptors to contain hashes for omitted script subtrees. That too could represent non-existent information (Merkle path entries that are chosen rather than actual hashes), or omitted information. And it is useful - there are certainly scenarios where one might want to participate in, and sign for, taproot outputs for which certain subtrees are not known.
* If we're going to accept that the previous 3 examples will occur, we might as well bite the bullet and also add a way to encode "pkh with known keyhash, but not known key".

If all these mechanisms become permitted in descriptors (and miniscript), we get the nice logistical benefit of being able to represent all information extracted from PSBT/SPKM/scripts/... into a descriptor regardless of what is present or missing. I believe this would logistically simplify things later on too: Miniscript would not need separate instantiations for its descriptor-decoding use case and its signing/solving use case. Perhaps even further out, this can mean that many fields in `SignatureData` are replaced with just a descriptor object (everything except signatures/preimages), and the signing logic becomes a descriptor method.

Straw man proposal:
* Do #23480 (adding `rawtr(KEY)`), for P2TR outputs with specified tweaked key, but no specified internal key or script tree.
* Add a `rawnode(HEX)` fragment, only usable inside P2TR script tree expressions, indicating a tree node with specified hash, but no specified subtree.
* Add a `rawpkh(HEX)` fragment, usable wherever `pkh(KEY)` is usable, indicating a PKH script (`DUP HASH160 <hex> EQUALVERIFY CHECKSIG`), without specified public key. Post-miniscript this would also add a `rawpk_h(HEX)` fragment, corresponding to `pk_h(KEY)`.
Repository: PowerToys
Issue: Cascade Windows with keyboard combo
Labels: Idea-New PowerToy,Product-Window Manager

### Description of the new feature / enhancement

Press a customizable key combination to cascade all visible windows without the need to move your hands away from the keyboard.

![kbcaswin](https://user-images.githubusercontent.com/45464067/150384252-4967f42a-957f-4533-bef3-3fe8561743de.jpg)


### Scenario when this would be used?

When having multiple visible windows over the Desktop, the fastest way to organize all of them at once is simply pressing two or three keys.

FancyZones is best suited for commonly used programs and Snap Windows is comfortable to use, but these solutions still require some use of the mouse. Having a mouse-free workflow would be highly appreciated especially when some tasks require your whole focus when coding, writting business emails, analysing data, and the like.

### Supporting information

1. "...I regularly use it over ssh to code on remote servers and I feel quite productive while hardly touching the mouse..."

Having A Look. (2022) keyboard - Is there a way to code without a mouse? - Super User. Retrieved January 20, 2022, from https://superuser.com/questions/1231666/is-there-a-way-to-code-without-a-mouse


2. "Many users find that using an external keyboard with keyboard shortcuts for Excel helps them work more efficiently. For users with mobility or vision disabilities, keyboard shortcuts can be easier than using the touchscreen, and are an essential alternative to using a mouse."

One Cell. (2022) Keyboard shortcuts in Excel. Retrieved January 20, 2022, from https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-excel-1798d9d5-842a-42b8-9c99-9b7213f0040f


3. "By the end of my week without a mouse, many of the shortcuts were already beginning to feel like second nature. I found that they saved me a ton of time, especially on tedious tasks like deleting emails. Indeed, one shortcut evangelist suggests that switching to keyboard shortcuts in Gmail saved him as much as 60 hours per year."

Default. (2022) 'I Stopped Using a Computer Mouse For a Week and It Was Amazing' - Slashdot. Retrieved January 20, 2022, from https://hardware.slashdot.org/story/19/01/25/006216/i-stopped-using-a-computer-mouse-for-a-week-and-it-was-amazing
Repository: godot
Issue: Copying and pasting a Button or Button-derived Node incorrectly copies "focus_mode"
Labels: bug,confirmed,topic:gui

### Godot version

3.4.2

### System information

Windows 10

### Issue description

When copying and pasting a Button or a node inheriting Button in the editor, "focus_mode" is incorrectly set in the new instance to the value of "enabled_focus_mode" (the deprecated property in the "BaseButton" tab).

### Steps to reproduce

1. Create a new scene
2. Create a Button node and set "focus_mode" and "enabled_focus_mode" to different values
3. Copy and paste the created Button
4. The pasted Button has in "focus_mode" the value of "enabled_focus_mode"

### Minimal reproduction project

_No response_
Repository: godot
Issue: Parse Error: No constructor of 'RID' matches the signature 'RID(Object)'
Labels: bug,topic:core,documentation

### Godot version

3.3.stable, 3.5.beta1

### System information

Ubuntu 20.04

### Issue description

The documentation says the following: 

> # Method Descriptions
> `RID RID(from: Object)`
>
> Creates a new RID instance with the ID of a given resource. When not handed a valid resource, silently stores the unused ID 0.

But in reality, it is impossible to create a RID from an object, therefore, it is also impossible to find out its RID if the object does not provide the corresponding method (I need it to call the NavigationServer for the agent)

### Steps to reproduce

Apply this script to the object:
```gdscript
extends Spatial

func _ready():
	RID(self as Object)
```

### Minimal reproduction project

_No response_
Repository: rust
Issue: Windows: Audit, clarify, and add tests for `resolve_exe()` "append .EXE extension if the extension is different" (not just missing) behavior.
Labels: O-windows,C-bug

I was reading the code for `resolve_exe()` for some reason and I saw this code:

```rust
    let has_exe_suffix = if exe_path.len() >= EXE_SUFFIX.len() {
        exe_path.bytes()[exe_path.len() - EXE_SUFFIX.len()..]
            .eq_ignore_ascii_case(EXE_SUFFIX.as_bytes())
    } else {
        false
    };
```
(Incidentally, can't this be simplified?)

Then later:

```rust
        if has_exe_suffix {
             return [...];
        };

        // Append `.exe` if not already there.
        path = path::append_suffix(path, EXE_SUFFIX.as_ref());
        if path.try_exists().unwrap_or(false) {
            return Ok(path);
        } else {
            // It's ok to use `set_extension` here because the intent is to
            // remove the extension that was just added.
            path.set_extension("");
            return Ok(path);
        }
```

Appending EXE_SUFFIX if the extension isn't already EXE seems wrong to me; I think instead it would make more sense to use exactly the same rules that `CreateProcessW` is documented to use, which is roughly "there is no extension," not "the extension isn't .exe".

~~Further, let's say there is an extension that isn't EXE_SUFFIX, and we append EXE_SUFFIX and we find that the file doesn't exist. Then we remove the extension. The comment implies that this will reset the extension to what it was before, but this is only true if there was no extension at all. What if there was an extension that wasn't EXE_SUFFIX?~~
Repository: pytorch
Issue: Better Engineering: test_..._mem_overlap in test_torch.py should be ported to ErrorInputs
Labels: module: tests,triaged,better-engineering

These tests, like `test_shift_mem_overlap`, are ideal candidates to be converted to ErrorInputs. This would also let other systems verify they handle these operations properly. 

cc @mruberry
Repository: rust
Issue: Is  `std::fs::copy` racy and/or under-specified in how it sets file permissions?
Labels: T-libs,A-io,C-discussion

The documentation for `std::fs::copy` says "This function will also copy the permission bits of the original file to the destination file."

I do think the function adheres to that contract. But, is that contract strong enough? 

Consider a file that is isn't readable by the group or world that is passed to `std::fs::copy`. My expectation is that the copied file would never have group or world file permissions different from the source file. However, currently, between the time `fs::File::create` is called and the time `writer.set_permissions` is called, the destination file may have group/world permissions different than (and in particular, potentially more liberal than) the source file's permissions.

Further, what if, for some reason, the `set_permissions` call fails, or the process is killed before then? Then with the current code we'd be left with a group-/world-readable file. 

It seems like instead, when we create the file, we should use a syscall that ensures the file is created with the source file's permissions. 

If the file is read-only for the current user, then maybe we need to add the user write permission during creation, and then remove it when we're done writing? If we do this, then we should document that the file may be left writable if errors occur or the process crashes.

At a minimum, the documentation needs to be updated to consider these cases.

```
pub fn copy(from: &Path, to: &Path) -> io::Result<u64> {
    let mut reader = fs::File::open(from)?;
    let metadata = reader.metadata()?;

    if !metadata.is_file() {
        return Err(NOT_FILE_ERROR);
    }

    let mut writer = fs::File::create(to)?;
    let perm = metadata.permissions();

    let ret = io::copy(&mut reader, &mut writer)?;
    writer.set_permissions(perm)?;
    Ok(ret)
}
```
Repository: go
Issue: x/tools/internal/lsp/lsprpc: TestClientLoggingV2 failure with "timeout waiting for client log"
Labels: Testing,gopls,Tools

```
#!watchflakes
post <- (pkg == "golang.org/x/tools/gopls/internal/lsp/lsprpc" || pkg == "golang.org/x/tools/gopls/internal/lsprpc") &&
	test ~ `TestClientLoggingV2` &&
	`timeout waiting for client log`
```

```
2022/01/20 18:03:54 New server
	new_server="1"
	logfile=""
	debug_address=""
	gopls_path="/tmp/workdir-host-freebsd-arm64-dmgk/tmp/go-build3210943659/b793/lsprpc.test"
	client_id="3"
2022/01/20 18:03:54 forwarder: exited with error: remote disconnected: failed reading header line: read tcp 127.0.0.1:58365->127.0.0.1:25447: use of closed network connection
2022/01/20 18:03:55 New server
	new_server="3"
	logfile=""
	debug_address=""
	gopls_path="/tmp/workdir-host-freebsd-arm64-dmgk/tmp/go-build3210943659/b793/lsprpc.test"
	client_id="6"
2022/01/20 18:03:57 forwarder: exited with error: remote disconnected: failed reading header line: read tcp 127.0.0.1:25208->127.0.0.1:60842: use of closed network connection
2022/01/20 18:03:57 ping
2022/01/20 18:03:58 jsonrpc2 message delivery failed: JSON RPC internal error: "window/logMessage" notification failed: io: read/write on closed pipe: JSON RPC internal error
2022/01/20 18:03:58 ping
--- FAIL: TestClientLoggingV2 (1.58s)
    --- FAIL: TestClientLoggingV2/forwarded (1.58s)
        binder_test.go:111: timeout waiting for client log
FAIL
FAIL	golang.org/x/tools/internal/lsp/lsprpc	5.125s
```

`greplogs --dashboard -md -l -e 'timeout waiting for client log' --since=2021-01-01`

[2022-01-20T14:52:25-ab35822-9de1ac6/freebsd-arm64-dmgk](https://build.golang.org/log/3eaa2b580edaf058362f562fdee976b1d5b7563a)

CC @findleyr
Repository: rust
Issue: Audit uses of filesystem APIs for race conditions and the like within the standard library
Labels: T-libs,A-io

One consequence of https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html is that many people will now be auditing the use of `std::fs::{metdata,symlink_metadata,File::metadata,Metadata}` looking for similar race condition bugs. We should have some coordinated effort to ensure we have the comprehensive results of doing said audit; i.e. we should coordinate such an audit ourselves and publish the results.

I spent a few minutes thinking about this and started looking myself. Besides race conditions due to metadata checks, there are also checks as to whether a file exists (e.g. in `resolve_exe`) that seem questionable, and also uses of `set_permission` that seem racy or at least under-specified/documented (https://github.com/rust-lang/rust/issues/93126). My conclusion from looking at just a few functions is that, at minimum, we need to document (in the code and in the rustdoc documentation) more clearly what kinds of racy behavior we intentionally allow, and/or eliminate the racy behaviors.
Repository: svelte
Issue: Tween and transitions don't work together 
Labels: transition/animation

### Describe the bug

element with tweened location moves as its being transitioned in but not  as its being transitioned out.

### Reproduction

https://svelte.dev/repl/5b90bd8c3dda45c495df799dd2a5172e?version=3.46.2

### Logs

_No response_

### System Info

```shell
System:
    OS: macOS 12.1
    CPU: (8) x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
    Memory: 930.31 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 17.3.0 - /usr/local/bin/node
    Yarn: 1.22.11 - /usr/local/bin/yarn
    npm: 8.3.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 97.0.4692.99
    Firefox: 96.0.1
    Safari: 15.2
```


### Severity

annoyance
Repository: TypeScript
Issue: Empty array in union with tuple doesn't infer undefined on indexed access
Labels: Suggestion,In Discussion

# Bug Report

```
declare const tuple: never[] | [string];

tuple[0].length // no compile-time error :(
```
[Playground](https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true#code/CYUwxgNghgTiAEYD2A7AzgF3hgrgBwhAC54UQA3EGAbQF14AfeazGASxQHNaBuAKD64CIagAZaAOkJcMAC3gB6BaSTwqMJDCA)
Note that `noUncheckedIndexedAccess` is enabled - but doesn't make any difference in this case.


The reason it is a problem is that `[]` is inferred as `never[]` in many scenarios, thus allowing type-unsafe code. [Example](
https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true#code/MYewdgzgLgBAJgQygmBeGBtA5AQSwXRgQhlEigG4AoM6ItGAWSQAsA6AJwTDhAFsAFAEoYAPhgAGNgFYYAfkyEAXPCQJqVBBgn42UDgEtBQ6kA):
```
const data = ['A'] as const;

// inferred as `never[] | ['A']
const a = Math.random() > 0.5 ? [] : data;

a[0].length; // can be undefined, but no compiler error
```


### 🔎 Search Terms

Tuple, union, empty array, infer, noUncheckedIndexedAccess
### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about `never`, `tuple`, `array`

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true#code/CYUwxgNghgTiAEYD2A7AzgF3hgrgBwhAC54UQA3EGAbQF14AfeazGASxQHNaBuAKD64CIagAZaAOkJcMAC3gB6BaSTwqMJDCA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
declare const tuple: never[] | [string];

tuple[0].length // no compile-time error :(
```

### 🙁 Actual behavior

Compiles well, breaks at runtime

### 🙂 Expected behavior

Compile-time error that `tuple[0]` is possibly undefined
Repository: vscode
Issue: problemMatcher is too complicated and should be modernised
Labels: feature-request,tasks

 One of the most frustrating things I've found with setting up a task is the problemMatcher. Its far too complicated for simple tasks such as setting up a background task to the point most don't bother to use it, which is a shame because it's quite powerful.

Here are some things worth considering:

## Background Tasks

Sometimes I want to have a `watch` task, such as ESBuild watch. This is a pain to configure.

1. `background` should come out of the problemMatcher scope. This is because I don't care about matching the output, I just want to start background tasks and let VSCode know when something is being rebuilt.  Even though this is straight forward in theory I now need to define loads of problemMatcher config, and I usually end up just setting `$tsc` as a base, which is wrong if its not a TypeScript Project. This has been brought up as far back as [2016](https://github.com/microsoft/vscode/issues/6209#issuecomment-218154446) by @dbaeumer 
2. `background` shouldn't force you to have a `beginsPattern` it makes no sense for watch tasks which start straight away and every subsequent change just triggers similar output (like “build successful”). (see edge case)

Edge Case:

ESBuild for example [doesn't show any output](https://github.com/evanw/esbuild/issues/980#issuecomment-943321320) when a watch task starts, this means beginsPattern is not applicable, `"activeOnStart": true` is set but a beginsPattern is still required. After the first successful build "watch build succeeded" is shown. I can't set "watch build succeeded" as the beginsPattern because it will never show until the first save, and I can't set it as endsPattern because VScode will think im just beginning a build when it has in fact ended.

My Proposal is this:

background can stay within problemMatcher for backwards compatibility but it should be a top level item within tasks. It's not tied to problemMatching, and sometimes you just want to mark the beginning and end of a build in watch mode.

`beginsPattern` should be optional if activeOnStart is set to true. That way whenever endsPattern is shown a build has finished. I believe this will allow VSCode to be more flexible when creating background tasks. This would also fix https://github.com/microsoft/vscode/issues/6209 because now `preLaunchTask ` can start once endsPattern has been triggered.

## Steps to reproduce:
- Clone: https://github.com/styled-components/vscode-styled-components
- npm i
- run the build task
- try modifying the build task to show when running and finished (this is impossible because ESBuild doesn't show any output when it starts).


Docs:
- https://code.visualstudio.com/docs/editor/tasks
- https://code.visualstudio.com/docs/editor/tasks-appendix

Related:
- https://github.com/microsoft/vscode/issues/6209
Repository: godot
Issue: Luminance calculation formula appears to be wrong
Labels: enhancement,discussion,topic:rendering,topic:3d

### Godot version

4.0 (also found in 3.x)

### System information

Windows 10 Vulkan

### Issue description

I am currently reading Godot's shader code and was a bit stumped when I stumbled across how the luminance was calculated. Godot currently uses `luminance = max(color.r, max(color.g, color.b));`.

While this estimation should work okay-ish for most use cases it is not technically correct, since the human eye is far more sensitive to green colors.

According to e.g. Fillament or Wikipedia more correct formulas would be:
`L = 0.299*R + 0.587*G + 0.114*B` and `L = 0.2126*R + 0.7152*G + 0.0722*B`  for gamma corrected content.
(in practise this should obviously be calculated as a dot product)

This means that in a worst-case scenario (e.g. when the color is `{0,0,1}`) the currently calculated luminance value could be many times higher than it should be.

I did find a comment in luminance_reduce_raster.glsl#L59 that mentions the correct formula but implies that using it overexposes the result. This might imply that there are some other problems with how Godot handles luminance.

### Steps to reproduce

1. Open shaders/copy.glsl
2. Scroll to line 189
3. Be confused

### Minimal reproduction project

Should be present in all Godot projects.


### Effected shaders I found so far:
copy.glsl#L189
effect_blur.glsl#L285
blur_raster.glsl#L126
luminance_reduce_raster.glsl#L57
luminance_reduce.glsl#L47