sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Add a button that could take the user to the extension details
Labels: feature-request,authentication

> Another idea for improvement is to add a button to each item which would take me to the extension details (e.g. by using `command:workbench.extensions.search` with an `@id:xx.yy` query).

_Originally posted by @gjsjohnmurray in https://github.com/microsoft/vscode/issues/204785#issuecomment-1935618123_
            
Although, at the moment, the details don't include anything about authentication (justification, usage cadence, etc) so I feel like that won't be too helpful in its current form beyond reminding the user what the extension is.
Repository: pytorch
Issue: torch.compile slower than eager on simple MLP
Labels: module: performance,triaged,enhancement,oncall: pt2,module: inductor

### 🐛 Describe the bug

```
import torch
from torch import Tensor
from torch import nn
import torch.nn.functional as F
import torch._inductor.config
torch.set_default_device('cuda')
# from torchvision.models import resnet18

class Layer(nn.Module):
    def __init__(self):
        super().__init__()
        dim = 4096
        self.mods = nn.Sequential(nn.Linear(dim, dim), nn.LayerNorm([dim]), nn.GELU())

    def forward(self, x):
        return self.mods(x)

class Layered(nn.Module):
    def __init__(self):
        super().__init__()
        self.layers = nn.Sequential(*[Layer() for _ in range(10)])

    def forward(self, x):
        return self.layers(x)

def bench(f, name=None, iters=1000, warmup=5, display=True, profile=False):
    import time
    from triton.testing import do_bench

    for _ in range(warmup):
        f()
    if profile:
        with torch.profiler.profile() as prof:
            f()
        prof.export_chrome_trace(f"{name if name is not None else 'trace'}.json")

    us_per_iter = do_bench(lambda: f())*1000

    if name is None:
        res = us_per_iter
    else:
        res= f"{name}: {us_per_iter:.3f}us"

    if display:
        print(res)
    return res

mod = Layered().to(dtype=torch.bfloat16)
comp_mod = torch.compile(mod)
inp = torch.randn(2048, 4096, dtype=torch.bfloat16)

bench(lambda: comp_mod(inp).sum().backward(), name="compiled")
print(torch.cuda.max_memory_allocated()/1e9)
torch.cuda.reset_peak_memory_stats()

bench(lambda: mod(inp).sum().backward(), name="eager")
print(torch.cuda.max_memory_allocated()/1e9)
torch.cuda.reset_peak_memory_stats()
```
```
compiled: 12249.492us
1.48218112
eager: 12180.403us
1.548758016
```

This is... not ideal. It seems something specific-ish to Gelu - changing it to relu makes `torch.compile` perform better.

### Versions

nightly

cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Repository: pytorch
Issue: init_device_mesh doesn't have a timeout kwarg
Labels: oncall: distributed,triaged,module: DeviceMesh

should it?  (should it be different per dim?)

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @yf225
Repository: PowerToys
Issue: Save and Restore Window Positions Across Multiple Monitors
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

The proposed feature is an enhancement to the FancyZones utility in PowerToys. It allows users to save the current layout of their windows across multiple monitors and restore this layout at a later time.

The feature could be activated through a hotkey or a button in the PowerToys interface. When activated, the current positions and sizes of all open windows are saved. Later, if the windows have been moved or resized, activating the feature again would restore all windows to their saved positions and sizes.

This feature would be particularly useful for users who frequently switch between different window layouts, as it would allow them to quickly restore a previous layout without manually rearranging their windows. It would work across multiple monitors and for all types of windows, enhancing the overall user experience of managing windows in a multi-monitor setup.

The feature could also include the ability to remember multiple layouts, allowing the user to save and restore different layouts as needed. This would provide users with greater flexibility in managing their workspace.

### Scenario when this would be used?

This feature would be used in scenarios where a user has a specific layout of windows across multiple monitors that they frequently use. For example:

System Reboots and Shutdowns: After system reboots, shutdowns, or power-ons, window positions can get shuffled around. With this feature, the user could easily restore their preferred layout once the system is back up.
Multitasking: A user might have a layout for multitasking where they have their email open on one half of a monitor, a spreadsheet open on the other half, and a web browser open on a second monitor. They could save this layout and quickly restore it whenever they need to multitask.
Different Work Modes: A user might have different layouts for different types of work. For example, they might have a layout for coding with their code editor and terminal on one monitor and documentation on another. They could switch to this layout whenever they’re coding.

### Supporting information

https://sl.bing.net/fAwiRwyLmRo
Repository: node
Issue: Async errors are blocked until test run is finished
Labels: test_runner

### Version

v21.6.1

### Platform

Windows

### Subsystem

_No response_

### What steps will reproduce the bug?

```js
var test = require('node:test');

setTimeout(function(){
    console.log(xxxxxxxxxx); // uncaughtException 
}, 100)

test('bug', function(t, done){
    setTimeout(function(){
        done();
    }, 10000);
});
```

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

_No response_

### What is the expected behavior? Why is that the expected behavior?

I would expect uncaughtException would bubble/log immediately. In my case because of the error, the test never finished, as such nothing was logged so there was no way of knowing what is happening.

### What do you see instead?

The reflection of myself in the monitor.

### Additional information

_No response_
Repository: rust
Issue: Incorrect conflicting trait implementation link when the first one is in macro
Labels: A-diagnostics,T-compiler

### Code

Add `thiserror` dependency.

```Rust
#[derive(Debug, thiserror::Error)]
pub enum MyError {
    #[error(transparent)]
    Io(#[from] std::io::Error),
}

impl From<std::io::Error> for MyError {
    fn from(error: std::io::Error) -> Self {
        Self::Io(error)
    }
}
```


### Current output

```Shell
error[E0119]: conflicting implementations of trait `From<std::io::Error>` for type `MyError`
 --> src/main.rs:1:17
  |
1 | #[derive(Debug, thiserror::Error)]
  |                 ^^^^^^^^^^^^^^^^ conflicting implementation for `MyError`
...
7 | impl From<std::io::Error> for MyError {
  | ------------------------------------- first implementation here
  |
  = note: this error originates in the derive macro `thiserror::Error` (in Nightly builds, run with -Z macro-backtrace for more info)
```


### Desired output

```Shell
error[E0119]: conflicting implementations of trait `From<std::io::Error>` for type `MyError`
 --> src/main.rs:7:1

(the rest should be the same)
```


### Rationale and extra context

The error link points to the first auto-generated implementation, whereas it should be pointing to the conflicting implementation.  Note that if I change my example code to this, the link points correctly to the conflicting one on line 11, not the first one on line 5.

```rust
pub enum MyError {
    Io(std::io::Error),
}

impl From<std::io::Error> for MyError {
    fn from(error: std::io::Error) -> Self {
        Self::Io(error)
    }
}

impl From<std::io::Error> for MyError {
    fn from(error: std::io::Error) -> Self {
        Self::Io(error)
    }
}
```

Correct error message:

```
error[E0119]: conflicting implementations of trait `From<std::io::Error>` for type `MyError`
  --> src/main.rs:11:1
   |
5  | impl From<std::io::Error> for MyError {
   | ------------------------------------- first implementation here
...
11 | impl From<std::io::Error> for MyError {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `MyError`
```

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.76.0 (07dca489a 2024-02-04)
binary: rustc
commit-hash: 07dca489ac2d933c78d3c5158e3f43beefeb02ce
commit-date: 2024-02-04
host: x86_64-unknown-linux-gnu
release: 1.76.0
LLVM version: 17.0.6
```


### Anything else?

_No response_
Repository: pytorch
Issue: Submatrix multiplication selected by rows or columns 
Labels: module: performance,module: cuda,triaged,matrix multiplication

### 🚀 The feature, motivation and pitch

Hi, I am trying to implement some code involving sub-matrix (selected by rows or columns) multiplication. 

A simplified example:

```
m, k, n = 5, 4, 6  
A = torch.randn(m, k).cuda() 
B = torch.randn(k, n).cuda()  
columns_to_use = [1, 3, 4]  
result = torch.matmul(A, B[:, columns_to_use])
```

However, the current implementation is very inefficient, the running time of `result = torch.matmul(A, B[:, columns_to_use])` is even slower than full matrix multiplication `result = torch.matmul(A, B)`.

I doubt the reason could be that CUDA allocates slice B[:, columns_to_use] new memory (creates a new tensor), which increases the running overhead.

I am wondering if there is any way to perform such sub-matrix multiplication with pytorch, or I need to write a custom CUDA kernel for this.

### Alternatives

_No response_

### Additional context

_No response_

cc @ptrblck
Repository: godot
Issue: Dynamic mesh lighting breaks with Physical Light Units and LightmapGI
Labels: bug,topic:rendering,topic:3d

### Tested versions

v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated AMD Radeon RX 6700 XT (Advanced Micro Devices, Inc.; 31.0.24002.92) - AMD Ryzen 7 5700X 8-Core Processor (16 Threads)

### Issue description

When PLU is enabled, dynamic meshes no longer receive any indirect lighting from LightmapGI (turns black).

![image](https://github.com/godotengine/godot/assets/25323231/3390715a-9b3d-46b2-8760-d79de8936ec2)


### Steps to reproduce

1. Set up a scene with baked lightmaps and a mesh with dynamic GI. Also enable PLU and set up camera attribs.
2. Bake
3. Move the dynamic mesh to update its lighting. The object will lose all indirect lighting.

### Minimal reproduction project (MRP)

[Lightmap.zip](https://github.com/godotengine/godot/files/14227970/Lightmap.zip)
Repository: deno
Issue: jsr: deno install cannot infer executable name from the jsr https url
Labels: suggestion,compile

Version: Deno 1.40.4

<img width="646" alt="image" src="https://github.com/denoland/deno/assets/10268458/9486c453-baee-49cd-bf0c-5c1e80ac673c">

Providing a jsr address of a package, I would expect `deno install` to infer the name of the executable as the package name, in the above example `dkill`. Similar to the existing behaviour with an address targeting /x. for example https://deno.land/x/dkill@0.10.0/cli.ts
Repository: go
Issue: runtime: CL 501976 performance and jitter regression
Labels: Performance,NeedsInvestigation,compiler/runtime

### Go version

go version go1.22.0 linux/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/steve/.cache/go-build'
GOENV='/home/steve/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/steve/Go/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/steve/Go/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/steve/Go/go1.22.0/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/home/steve/Go/go1.22.0/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build502182501=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

I am comparing the performance my project when compiled with Go 1.22.0 and when compiled with Go 1.21.7

The full instructions for my testing procedure ~~and the result CPU profiles~~ and the test program have been placed in a specially created Github [repository](https://github.com/JetSetIlly/gopher2600_performance_profiles)


### What did you see happen?

The performance of my project has dropped significantly with v1.22.0. Using the metric of performance used in my project, the performance with Go v1.21.7 is 146.28fps and the performance with Go v1.22.0 is 133.48fps. This is a drop of 8.75%


### What did you expect to see?

I expected either no significant change or an increased performance rating. This method of measurement has been used for many years and has shown increases in performance as expected when new Go versions have been released. For example, the introduction of profile-guided optimisation, showed the expected increase in performance.
Repository: deno
Issue: Parsing error when `satisfies` or `as` follows an Instantiation Expression 
Labels: bug,swc

Version: Deno 1.40.4

Consider this one-line TS file:
```typescript
Array<5> satisfies unknown;
```

As of Typescript 4.9, this is syntactically correct and also type-checks successfully ([playground](https://www.typescriptlang.org/play?ts=4.9.5#code/IIJxEME8B4FYD4AEBncAXAlsgZhgpsogK4B2A1iQPYDuJA3AFANA)).

However in Deno 1.40.4 (with Typescript 5.3.3), the CLI instead fails with this diagnostic:
```
error: The module's source code could not be parsed: Expected ';', '}' or <eof> at file:///redacted/type_tests.ts:1:20

  Array<5> satisfies unknown;
                     ~~~~~~~
```

This appears to persist when an expression like this is used elsewhere (eg wrapped in parens, used on the RHS of an assignment, etc).

I imagine this is getting mis-parsed as the equivalent of `(Array < 5 > satisfies) unknown;` which would be invalid. That's just speculation however.

❤️
Repository: excalidraw
Issue: Ability to find desired command or function
Labels: enhancement,shortcuts

Hi,

I think a feature similar to Sublime Text's Command Palette (Shift+Command+P) would provide a convenient way to access any command or function via single shortcut, allowing quickly find it without navigating through menus or remembering specific key combinations.

Thank you for really nice tool.
PetrasL
Repository: vscode
Issue: Allow globally disabling extensions from withinn an untrusted workspace
Labels: under-discussion,workspace-trust

Type: <b>Feature Request</b>

Currently, when I'm at the Welcome screen (or any other untrusted workspace), I cannot globally disable extensions which have been disabled automatically in an untrusted workspace, because when I select the (greyed out) extension from the Extensions sidebar there is no 'Disable' button on the extension page in this situation.

This is annoying, because I'm now forced to open some trusted workspace (which could take a long time in case of initializing a DevContainer, remote connection, etc.) just to globally disable some extension.

I would like to suggest a fix by way of always offering a 'Disable' button on an extension's info page to globally disable an extension, regardless of whether the extension is currently already automatically disabled because of working in an untrusted workspace.

VS Code version: Code - Insiders 1.87.0-insider (8fa84589eef3538dbc763ff98dc7d5a8a0c56374, 2024-02-09T05:47:15.236Z)
OS version: Windows_NT x64 10.0.22631
Modes:


<!-- generated by issue reporter -->
Repository: godot
Issue: Uneven control node scaling with canvas_items stretch mode
Labels: bug,topic:rendering,needs testing,topic:gui

### Tested versions

Godot v4.3.dev [4e990cd7e] 
I noticed this in 4.1.2 as well

### System information

Godot v4.3.dev (4e990cd7e) - macOS 14.3.0 - Vulkan (Forward+) - dedicated AMD Radeon RX 6800 

### Issue description

I've ran into an issue with control node scaling when using `canvas_items` stretch mode with `expand` and `fractional`.

This is a cropped image of the rendered window with 430x932px, where the boxes are all 88x88px. 
The first two boxes have a border width of 4px left, 4px top, 5px right, 5px bottom.
With the last two boxes they are 4px on the left and 5px top, right, bottom. 
With the allotted space of 88x88px they should all be 5px.

![canvas_stretch](https://github.com/godotengine/godot/assets/13589801/e4c765af-4aa2-4b40-8342-d04c4471058b)
In the base viewport resolution of 180x320px the boxes are all 37x37px with a border of 2px. This is a faux pixel art style with control nodes (the project started out as pure pixel art with viewport scaling).

I've tested this with different methods, the boxes are:
- Panel with border
- Border segments made with individual ColorRects
- Nested Sprite2D inside control node
- TextureRect set to keep size / scale

The expected behavior for `canvas_items` stretch mode would be an even scale of these control nodes. Or am I missing something? 

At first I thought this might be related to container sizing, because I have these boxes setup in a tree of MarginContainer - VBox - Hbox. But the same thing happens with freely positioned control nodes. The ones in the screenshot all have integer number transform positions.

This happens with all three rendering methods, the snap settings did not change the outcome.

Where would be a good place to start investigating, `scene/gui/control.cpp`?


### Steps to reproduce

See issue description

### Minimal reproduction project (MRP)

[ScaleTest.zip](https://github.com/godotengine/godot/files/14230000/ScaleTest.zip)
Repository: next.js
Issue: cookies() returns stale value when Javascript is disabled
Labels: bug

When a cookie is set in a server action, the Server Components that call `cookie()` will re-render. During that re-render, the value returned by `cookie()` is stale. The problem occurs consistently when JS is disabled on the client.

### Link to the code that reproduces this issue

https://github.com/debel27/next-reproduction-app-cookies

The relevant code is entirely in the [root layout.tsx file](https://github.com/debel27/next-reproduction-app-cookies/blob/main/app/layout.tsx).

### To Reproduce

1. Start the application in development mode (`next dev`)
2. Open the application in the browser (should be at http://localhost:3000)
3. Disable Javascript (the procedure varies depending on the browser)
4. Refresh the page

The page should now look like this:

![image](https://github.com/vercel/next.js/assets/3456755/5ffa1194-4010-44db-b8a3-8d30bb3488dc)

Click this "login" button.

### Current vs. Expected behavior

#### Expected behavior

Clicking the "login" button submits a form, whose server action sets a cookie. This action trigers the re-render of the root layout (which calls `cookie()`), leading to the "logout" screen, which displays the following:

![image](https://github.com/vercel/next.js/assets/3456755/6306e1dc-27bb-42ba-b665-2250fed446d2)

#### Actual behavior

Clicking the "login" button **does not** lead to the the "logout" screen. The UI keeps showing the login screen. Clicking a second time on the button or refreshing the page shows the logout screen.

Clicking the button does perform a form submit, which reloads the page. The new page comes with an authentication cookie, as expected. However, it appears the server reads a stale cookie value when re-rendering the layout after the form submission. This is why the login screen keeps showing up, despite the cookie being present in the response. 

This issue occurs only when Javascript is disabled in the browser. This looks strange to me, as I don't expect `cookies()` to be affected by this. I'm disabling Javascript to test the progressive enhancement capabilities of my app. I don't expect my users to disable Javascript, but I expect my app to work even if Javascript has not loaded yet.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #189-Ubuntu SMP Fri Jan 5 14:23:02 UTC 2024
Binaries:
  Node: 20.11.0
  npm: 10.2.4
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.1.1-canary.46 // Latest available version is detected (14.1.1-canary.46).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local)

### Additional context

_No response_
Repository: go
Issue: proposal: net/http: Custom handlers for 404 and 405 HTTP response codes
Labels: Proposal

### Proposal Details

Go 1.22 introduced an enhanced HTTP routing. The current implementation utilizes unexported handlers for 404 and 405 responses. However, if there is a need for a custom 404 response (e.g., in a REST API with JSON responses), it is no longer possible to use a 'catch-all' pattern `/`, as it prevents the ability to return a 405 response. This issue is elaborated further in [this discussion](https://github.com/golang/go/issues/61410#issuecomment-1871202015).

To address this challenge, one can define a custom `http.ResponseWriter` to intercept responses and their status codes and handle them appropriately. Nonetheless, this approach precludes the ability to return a custom 404 response based on whether the `http.ServeMux` couldn't locate the appropriate route or if the user's handler returned a response with a 404 status code. An example scenario is when responding to `GET user/{id}` for a non-existent user in the system.

Given these challenges, I believe it would be valuable to register custom 404 and 405 handlers.
Repository: PowerToys
Issue: Installing WinGet module - "untrusted repository"
Labels: Issue-Bug,Needs-Triage,Product-CommandNotFound

### Microsoft PowerToys version

0.78.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

Command not found

### Steps to reproduce

When WinGet is not installed - there is a clickable link here to install it..

![image](https://github.com/microsoft/PowerToys/assets/39176113/512d1282-74c2-4c3b-a0dc-c261d9fbf49e)

And when you do - you are presented with a warning that the site is untrusted...

![image](https://github.com/microsoft/PowerToys/assets/39176113/6b656afc-2cf6-4a2e-8675-aecedf160cd0)


### ✔️ Expected Behavior

If it's a known warning that the repository is untrusted - let folks know.

### ❌ Actual Behavior

Warning about repository makes one think that something is wrong or a security vulnerability has occurred. 

### Other Software

_No response_