sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Consider how we might improve navigation to chat response content for screen reader users
Labels: bug,accessibility,under-discussion

@jooyoungseo has been interacting with the rendered HTML version of our chat responses more recently because of the introduction of the helpful hyperlinks. 

He mentioned that there are several tab stops that are encountered before a screen reader user reaches the content of a chat response:

1) the header
2) the toolbar
3) the references (if any)

He suggested that at least for windows/linux users, adding the `role=document` would help here. This wouldn't help macOS users and we probably want a solution that solves this for all platforms.

Another idea he had was to add a heading to the content so when a user enters a mode of their screen reader, they can go to it directly.

I mentioned that we're thinking about moving the toolbar (not sure about the references) to the bottom of the response. He raised concerns about the discoverability of the toolbar in that case for screen reader users but suggested that he has long thought a right click context menu would be advantageous and discoverable for users. 

@roblourens or @rperez030 any thoughts?
Repository: electron
Issue: [Bug]: net.fetch fails on manual redirect
Labels: platform/macOS,bug :beetle:,component/net,has-repro-gist

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

30.4.0, 32.1.0

### What operating system(s) are you using?

macOS

### Operating System Version

Sonoma

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

unknown

### Expected Behavior

using redirect: 'manual' net.fetch should return with the redirect response.

### Actual Behavior

using redirect: 'manual' net.fetch fails with an 'Error: Redirect was cancelled'

### Testcase Gist URL

https://gist.github.com/510aba6af66a8bbecf31682d8098cf25

### Additional Information

_No response_
Repository: rust
Issue: rustdoc: reexports of hidden items are not hidden, and look confusing
Labels: T-rustdoc,C-bug,A-rustdoc-search,A-local-reexports,S-has-mcve

I tried [searching](https://doc.rust-lang.org/nightly/std/?search=Receiver) for the (unstable) `Receiver` trait in the standard library. The only result it links to is [this](https://doc.rust-lang.org/nightly/core/ops/index.html#reexport.Receiver):

![image](https://github.com/user-attachments/assets/5cdd3fe5-ed17-48ce-9177-c2ca388170fa)

I would expect this to be clickable or have some other way for me to look at the actual definition of this trait. But nothing, the story just ends here.

Looking at the trait, I noticed this:
```rust
#[doc(hidden)]
pub trait Receiver {
    // Empty.
}
```
So probably the `doc(hidden)` is why we don't get a link. But shouldn't rustdoc then also hide the reexport?
Repository: godot
Issue: When using a SubViewport to show 2D scenes the normal map information is lost.
Labels: topic:rendering

### Tested versions

4.3.stable

### System information

Windows 11 - 4.3.stable.official Vulkan 1.3.280 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 3060 Laptop GPU

### Issue description

When using a SubViewport to show 2D scenes the normal map information is lost.
SubViewport.get_texture() returns a ViewportTexture that does not contain the information regarding normal maps.
For example, if I wanted to project a scene containing some Sprite2D and related textures (CanvasTexture containing diffuse_texture and normal_texture) onto a PlaneMesh using a SubViewport, currently there is no way to make it interact properly with the light coming on the mesh in the 3D environment, because the data about the normal maps is lost.

Here I am projecting a 2D scene on a SubViewport rendered on a mesh, there is no way to retrieve the normal map informations to make it react to the light in the 3D environment (the relative Sprite2D in the 2D scene has a normal map):
![image](https://github.com/user-attachments/assets/0d55f5be-7d2d-49cb-a7ba-8fb8e0c3a033)

On the contrary using a 3D scene it is possible to see its normal information and use it throught Rendering > Debug Draw > Normal Buffer:
![image](https://github.com/user-attachments/assets/8aabb4f1-3d3b-488a-b596-5dbe0330901a)


I have thought of a few solutions:
- Set the diffuse_texture and normal_texture properties to ViewportTexture, mimicking the behavior of CanvasTexture.
- Add the get_normal() method to SubViewport.
- Make the SubViewport Rendering > Debug Draw > Normal Buffer feature that already works with 3D scenes work for 2D scenes as well. 

### Steps to reproduce

- Create a 2D scene with one or more Sprite2D with a CanvasTexture and relative diffuse_texture and normal_texture.
- Create a 3D scene with a MeshInstance3D and a shape.
- Add a SubViewport node to the 3D scene and instantiate the 2D scene as a child of the SubViewport.
- Add a material to the mesh, and add the SubViewport as a ViewportTexture in the albedo property.
- From here there is no way to retrieve the normal map from the 2D scene and use it as a normal map for the material. Did not found any workaround.

### Minimal reproduction project (MRP)

Here there is a little project with a SubViewport where both 3D and 2D scenes projection can be experimented. I animated the lights so that the results can be seen easily.
[bug_sub_viewport_normals.zip](https://github.com/user-attachments/files/16998791/bug_sub_viewport_normals.zip)
Repository: rust
Issue: wasip2 target should not conditionally feature gate stdlib APIs
Labels: T-libs-api,O-wasm,C-bug,O-wasi,F-wasip2

This was introduced in https://github.com/rust-lang/rust/pull/119616 (cc @rylev)

Currently, any crate using `std::os::wasi` stuff needs to add a `#![feature(wasip2)]` if it is to be compiled with `--target=wasm32-wasip2`. This is due to this line:


https://github.com/rust-lang/rust/blob/0307e401c26699656ae08e3809e7d272f5c103f4/library/std/src/os/wasi/mod.rs#L32

This puts library authors targeting stable wasm stuff in an annoying situation of needing to add a feature gate to support downstream users who wish to use unstable wasm stuff (see https://github.com/servo/rust-url/pull/960). This isn't really how feature gates should work: the entity using the feature should be the one opting in. I don't think any of the benefits of feature gates apply if every wasi-using dep in the ecosystem just slaps on a `#![cfg_attr(all(target_os = "wasi", target_env = "p2"), feature(wasip2))]`, which seems likely here.


A somewhat legitimate reason I could see for having such a feature is if the wasip2 target is stable, but certain stdlib things are unstable under that target. It still has the same problems, and I'd argue a target with specially unstable stdlib APIs should not be considered stable, but at least there appears to be a meaningful thing that the stdlib feature gate is gating.

However, it appears to me that wasip2 is just unstable: what's the purpose of gating the stdlib API? If the goal is to gate the target, why not require `-Zunstable-options` as we do for other CLI-level unstable things?
Repository: go
Issue: runtime: "some test left a core file behind" failure
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- `some test left a core file behind`
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8736891617620242513)):

    PASS
    runtime.test: some test left a core file behind
    FAIL	runtime	394.801s


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: [export] Export CIA preservation doesn't work well with prim decomposition as custom decomp. 
Labels: triaged,oncall: pt2,export-triaged,oncall: export,module: pt2-dispatcher

```
import torch 


class M(torch.nn.Module):
    def forward(self, x):
        torch.ops.aten._assert_async(torch.tensor(True), "f")
        return x


torch.export.export(M(), (torch.tensor(True),)).run_decompositions(torch._decomp.decomposition_table)
```

cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @angelayi @suo @ydwu4 @zou3519 @bdhirsh
Repository: PowerToys
Issue: Restore Settings
Labels: Needs-Triage

### Description of the new feature / enhancement

I would restore all the settings 

### Scenario when this would be used?

When you modify/delete something that now you can't reverse. For example: Delete a color format of the Color Picker.

### Supporting information

I don't have any supporting information other than my story of how my dumb head decide to delete the color formats without backing it up first.
Repository: vscode
Issue: Show breakpoint hit count
Labels: feature-request,debug

<!-- ⚠️⚠️ 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. -->
While debugging it sometimes is helpfull to see how often a breakpoint is already hit in the current debug session.
So it would be nice to have the hit count in the breakpoint view as a quickinfo.

Best regards,
Frank
Repository: TypeScript
Issue: Move to File does not generate imports in the same way that autoimports does 
Labels: Bug,Domain: Refactorings

In https://github.com/microsoft/TypeScript/blob/89e004f632323a276b67649e118e78f39a7dc429/src/compiler/expressionToTypeNode.ts#L66 under `} from "./_namespaces/ts.js";` (the last import), add

```
export interface Foo {
    foo: number;
}

export function f(): Foo {
    return { foo: 1 };
}
```

select `export interface Foo { ... }` and using `moveToFile`, move it to `compiler/types.ts`

**Actual behavior:** 
`// @Filename compiler/expressionToTypeNode.ts`
```typescript
} from "./_namespaces/ts.js";
import { Foo } from "./types.js";

export function f(): Foo {
    return { foo: 1 };
}
```

**Expected behavior:**
`Foo` is imported from the namespace. Note this correct behavior is the current behavior that happens through calling autoimports directly. If I delete the wrong import above and then auto-import on `Foo`, we get the following as well.
```typescript
...
Foo,
...
 } from "./_namespaces/ts.js";

export function f(): Foo {
    return { foo: 1 };
}
```


tags: moveToFile, moveToNewFile, move to new file, auto imports
Repository: vscode
Issue: Quick text search exclude files
Labels: feature-request,search

<!-- ⚠️⚠️ 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. -->
The quick text search is great, but it should be possible to exclude certain files.

In a javascript project it is common to have a local build output that is usually not intended to be searched. Quick text search currently search it, resulting in a bunch of useless results. 

I think it would make sense to respect my search settings "files to exclude" or include.
Repository: rust
Issue: Assignment into Deref is allowed and creates irrelevant errors
Labels: A-diagnostics,T-compiler,D-confusing,D-verbose

### Code

```Rust
fn main() {
    let i_am_sized = String::new();
    *i_am_sized = String::new();
}
```

I thought I've had `&mut String`, not `String`, so `*` was unnecessary here. 

Because the lvalue has been dereferenced anyway, it caused confusing type error about a type that is not relevant, and assigning to an unsized type that is not at fault here. ~~But the root cause was unexpectedly triggering `Deref` instead of a dereference on `&mut` or `DerefMut`.~~



### Current output

```text
error[E0308]: mismatched types
 --> src/main.rs:3:19
  |
3 |     *i_am_sized = String::new();
  |     -----------   ^^^^^^^^^^^^^ expected `str`, found `String`
  |     |
  |     expected due to the type of this binding

error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/main.rs:3:5
  |
3 |     *i_am_sized = String::new();
  |     ^^^^^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
```


### Desired output

Something that `*i_am_sized` due to `Deref` is can't be assigned to, and suggest removing `*` instead.

### Rust Version

```Shell
rustc 1.83.0-nightly (8d6b88b16 2024-09-11)
binary: rustc
commit-hash: 8d6b88b168e45ee1624699c19443c49665322a91
commit-date: 2024-09-11
host: aarch64-apple-darwin
release: 1.83.0-nightly
LLVM version: 19.1.0
```
Repository: TypeScript
Issue: Move To File makes extra spaces when moving jsdoc comments
Labels: Bug,Domain: Refactorings

In https://github.com/microsoft/TypeScript/blob/89e004f632323a276b67649e118e78f39a7dc429/src/compiler/expressionToTypeNode.ts#L66 under `} from "./_namespaces/ts.js";` (the last import), add

```
/** @internal */
export interface Foo {
    foo: number;
}

/** @internal */
export function f(): Foo {
    return { foo: 1 };
}
```

select `/** @internal */ export interface Foo { ... }` and using `moveToFile`, move it to `compiler/types.ts`

**Actual behavior:** 
`// @Filename types.ts`, end of file:
```typescript
}/** @internal */

export interface Foo {
    foo: number;
}
```

**Expected behavior:**
```typescript
}

/** @internal */
export interface Foo {
    foo: number;
}
```

The comment appearing immediately after the closing bracket is probably related to `https://github.com/microsoft/TypeScript/issues/54306`, as `types.ts` has a trailing newline.

This may be related to https://github.com/microsoft/TypeScript/issues/54375, but #54375 adds statements in two stages, since the new lines are added between the generated imports and the moved code, while these lines appear within the moved code. 


tags: moveToFile, moveToNewFile, move to new file, auto imports, formatting, formatter
Repository: pytorch
Issue: xpu: set of aten ops are missing for Huggingface Transformers
Labels: triaged,module: xpu

With:
* https://github.com/pytorch/pytorch/commit/cd472bb1e368a711a2bd34d5671c77dab336d312
  * Plus this applied: https://github.com/pytorch/pytorch/pull/135567
* https://github.com/intel/torch-xpu-ops/commit/c6981a238cdaf93774b1c6a3550a436f530f4736
* https://github.com/huggingface/accelerate/commit/4b4c036933f7c50fe3a7027b0380fcec53c6975e
* https://github.com/huggingface/transformers/commit/d70347726577e9823e35c11883e98c5b2c520b37

I was running Huggingface transformers models tests, i.e.:
```
TRANSFORMERS_TEST_DEVICE_SPEC=spec.py PYTORCH_DEBUG_XPU_FALLBACK=1 python3 -m pytest --pspec tests/models
```

Overall:
* **Few aten ops not implemented for XPU (this issue is about this)**
* `PYTORCH_ENABLE_XPU_FALLBACK=1` was not needed at all (which is good)
* https://github.com/pytorch/pytorch/issues/136007 - hang happens in levit tests on Intel PVC (only in levit, other models ran fine)
* https://github.com/huggingface/transformers/pull/33485 - few HF tests were not enabled for HW devices (cuda/xpu wise), this PR adds support

The following aten ops are not yet implemented for XPU and affect HF tests. Please, implement:
- [x] `aten::_ctc_loss`, https://github.com/intel/torch-xpu-ops/pull/925
- [x] `aten::_ctc_loss_backward`, https://github.com/intel/torch-xpu-ops/pull/925
- [ ] `aten::_fft_c2c`, https://github.com/intel/torch-xpu-ops/pull/526
- [ ] `aten::_fft_c2r`
- [ ] `aten::_fft_r2c`
- [x] `aten::index_copy.out`, https://github.com/intel/torch-xpu-ops/pull/793
- [x] `aten::linspace.out`, https://github.com/intel/torch-xpu-ops/pull/850
- [x] `aten::take`, https://github.com/intel/torch-xpu-ops/pull/868
- [x] `aten::upsample_bicubic2d_backward.grad_input`, https://github.com/intel/torch-xpu-ops/pull/914
- [x] `aten::xlogy.OutTensor`, https://github.com/intel/torch-xpu-ops/pull/697

CC: @gujinghui @EikanWang @fengyuan14 @guangyey @jgong5

cc @gujinghui @EikanWang @fengyuan14 @guangyey
Repository: rust
Issue: unnamed_fields allows unnamed enum variants which behave oddly
Labels: T-compiler,C-bug,requires-incomplete-features,F-unnamed_fields

Example:

```rust
enum E {
    _,
    _ = 1,
    _(),
    _ {},
}
```

I don't think this is intended; unnamed fields are described for `struct` and `union`, but not for `enum`.

A built-in derived trait implementation appears to work as long as only a single unnamed variant exists, but more than one unnamed variant usually (but not always) results in errors (e.g. non-exhaustive patterns or attempting to use the wrong kind of variant).

These should probably just be forbidden. There's probably no harm in allowing the syntax, but semantically unnamed variants don't make any real sense. *Maybe* they could in an “inline the variants” manner, but that very much isn't the currently observed behavior.

### Meta

rustc 1.83.0-nightly (2024-09-12 adaff5368b0c7b328a03)

@rustbot label: +F-unnamed-fields +requires-incomplete-features
Repository: PowerToys
Issue: Mouse cursor anomaly
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.84.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

Mouse without borders, sometimes the pointer disappears or the cursor jumps here and there.
With the stand-alone Mouse without borders, which is not Power Toys, such an event has not occurred.
Please investigate and address the cause.

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: PowerToys
Issue: Keyboard shortcut for moving windows in FancyZones doesn't work when Windows key is remapped in Keyboard Manager
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.84.1

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Configure Keyboard Manager as below.
![image](https://github.com/user-attachments/assets/6dbb8462-6982-4802-8775-11c0f8c0821d)
2. Press Win + arrow keys

### ✔️ Expected Behavior

Active window will be moved and reshaped according to the layout settngs.

### ❌ Actual Behavior

Active window is moved but doesn't follow the layout settings. It seems that windows default snap function works instead of fancyzones.

### Other Software

_No response_
Repository: godot
Issue: RigidBody3D and CharacterBody3D do not register collision
Labels: topic:physics,needs testing

### Tested versions

Tested in:
v4.3.stable.official [77dcf97d8]
v4.0.stable.official [92bee43ad]


### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.5134) - AMD Ryzen 5 5600G with Radeon Graphics (12 Threads)

### Issue description

When a RigidBody collides with a CharacterBody (e.g. an object falls on top of the player) the RigidBody will register its `_on_body_entered` event. However, if the CharacterBody collides with the RigidBody (e.g. the player walks into an obstacle), said RigidBody will not have its `_on_body_entered` event triggered.
In both cases the CharacterBody does register the collision since move_and_slide returns True (as seen in the minimal reproduction project)

### Steps to reproduce

Create a RigidBody3D or 2D with a collision shape.
Create a CharacterBody 3D or 2D (matching the RigidBody) with a collision shape.
Create a ground-plane for the RigidBody to sit on, or set RigidBody gravity to 0 to keep it in case (in MRP a ground-plane is added).
Drop the RigidBody on top of the Character by placing it above the CharacterBody. Note how this will trigger a `_on_body_entered` event.

When the CharacterBody is given a script to move into the RigidBody, the even is not triggered.

### Minimal reproduction project (MRP)

[MRP.zip](https://github.com/user-attachments/files/17000663/MRP.zip)
Repository: godot
Issue: Controller vibration not working in HTML5
Labels: bug,platform:web,topic:input

### Tested versions

4.3 and earlier

### System information

Windows / OSX, Chrome

### Issue description

Input.start_joy_vibration() does nothing in HTML exports.

May be related to #73446 .

### Steps to reproduce

Export a game to HTML5 that runs Input.start_joy_vibration() and upload it to a webserver.  No vibration.

### Minimal reproduction project (MRP)

N/A
Repository: ant-design
Issue: antd Cascader级联选择框展开触发改成hover时，容易误操作。
Labels: Inactive,improvement

### What problem does this feature solve?

已经有人提过issue：https://github.com/ant-design/ant-design/issues/1065
重现：设置10几条数据，先选择一级靠下的项，再选二级靠上的项，这时候很大概率划过其它一级项，导致二级项变成不是你要选择的数据。

### What does the proposed API look like?

有一个延时展开的api供给用户设计，或者有没有其他方式可以解决怎么问题。

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: neovim
Issue: Out of bounds memory access in large `:term` sessions.
Labels: terminal,needs:repro,bug-crash

### Problem

If you use the neovim terminal and zoom the terminal out too far. Then when you run a command with a large horizontal output, you will get a SIGSEGV (out of bounds memory access).

I'm gonna take a stab at diving into this issue to see if I can fix it this weekend but I wanted to report it too.

### Steps to reproduce

```
nvim --clean
:term
# Zoom all the way out in alacritty with ctrl&- (Any terminal with far enough zoomout)

# In any posix-ish compliant shell (You just need to generate long enough horizontal lines)
for i in $(seq 1 10000); do echo -n $i; done
# This reliably causes a SIGSEGV (out of bounds memory access) independent of shell.
```

### Expected behavior

I would expect nvim to not segfault (even just killing the term instead of all of nvim would be better).

Also, this may seem like a niche edge case, but I frequently do this when logging buffers while debugging. 

### Neovim version (nvim -v)

NVIM v0.10.1 Build type: Release LuaJIT 2.1.1723675123

### Vim (not Nvim) behaves the same?

no, 9.1.707 (It seems like vim just limits term size)

### Operating system/version

Arch Linux

### Terminal name/version

Alacritty

### $TERM environment variable

alacritty

### Installation

pacman (release version)