sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: net/http: optionally disable recover on panic
Labels: Proposal

### Proposal Details

Similar to the previous proposals in #16542 and #25245,
I propose a per `Server` opt out of panic recovering and printing. 

While the automatic panic recovery was previously deemed regrettable, the above proposals declined for being somewhat backwards incompatible, especially when `ErrAbortHandler` was used. Therefore, I also propose a new method for `ResponseController` to cleanly close the connection, without interrupting the control flow. This allows the handler to perform any clean up necessary, which is more in line with normal Go error handling.

Glancing through the uses of `panic(http.ErrAbortHandler)` on Github: [search link](https://github.com/search?q=language%3AGo+panic%28http.ErrAbortHandler%29&type=code&p=1), I assert that these are almost all in modules where the handlers and server are developed together, so it should be relatively easy for users that wish to set `DisablePanicHandler = true` to also audit the handlers for any uses of `panic(http.ErrAbortHandler)`.

API additions:

```go
type Server struct{
    // Disables the automatic recovery of panics 
    // and printing of stack traces in handlers.
    // To close a connection, use [ResponseController.AbortConnection].
    DisablePanicHandler bool
}

// Abort terminates the current request without sending a response.
// For HTTP/1 it closes the network connection,
// for HTTP/2 it sends a RST_STREAM. Handlers must not write to
// ResponseWriter after calling AbortConnection.
func (c *ResponseController) Abort()
```

cc @neild
Repository: three.js
Issue: hapticActuators not working in XR sessions started with hand tracking used first
Labels: WebXR

### Description

If an XR session is started with hand tracking being used, and then in the middle of the session you pick up your controllers, the hapticActuators won't work. I believe the issue is specific to three.js as it does not occur here: https://cabanier.github.io/webxr-samples-1/input-selection-2.html

I find myself at a bit of a loss when trying to find the source of the issue unfortunately

### Reproduction steps

1. Start an immersive experience using hand tracking (make sure that the controllers are not also being tracked at this moment)
2. Pick up your controllers
3. Trigger some code that uses the inputSource's hapticActuators


### Code

N/A

### Live example

* [Discord User Moog's example](https://handtracking-no-haptic.glitch.me)
* [Three's Haptics Example](https://threejs.org/examples/?q=haptic#webxr_xr_haptics) (Testing here is pending #29860)

### Screenshots

_No response_

### Version

r170

### Device

Headset

### Browser

Chrome

### OS

Android
Repository: pytorch
Issue: torch_dispatch x HOP handling
Labels: triaged,module: dispatch,oncall: pt2,module: higher order operators,module: pt2-dispatcher

From discussion with @Chillee and @bdhirsh.

1. torch_dispatch mode should have a flag for if it accepts HOPs or not. If it does, then the HOP should get passed into the `__torch_dispatch__`.
2. We should give HOPs similar properties to ops. That is, they should have a .tag, the .opoverload field should probably point back at itself, etc.
3. HOPs should take in a flag for if they're "passthrough" or "operator like". Maybe we can give generic handling for the passthrough HOPs x torch_dispatch stuff (but open question as to how this actually works).


cc @ezyang @chauhang @penguinwu @ydwu4 @bdhirsh @yf225
Repository: angular
Issue: resource signal : have a way to make value() to persists while loading like when we use reload()
Labels: area: core,core: reactivity,cross-cutting: signals

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

My typical use case is a resource loading data for a sortable table like this :

```typescript
readonly tableResource = resource({
    request: () => ({
      sort: this.sort(),
    }),
    loader: async ({ request }) => {
      const { sort } = request;
      const response = await fetch(`http://localhost/api/test?sort=${sort}`);
      return await response.json() as TableData[];
  }
});
```

On the first execution when the data is loaded, _tableResource.value()_ contains my initial data.

When the user sort the table, the _sort_ signal is changed therefore the tableResource reloads the data. 

While the loader function is running, _tableResource.value()_ is set to **undefined**, then when the data is loaded _tableResource.value()_ contains my new sorted data.

I think this is the expected behavior but I have 2 problem with this :

1/ If the fetch function is slow to return a value, the user will see all the table content disappearing (because the resource value changes to undefined) before it shows again.
I think its best if the "old" data stays on the screen while it's loading (even if there is a loading indicator)

2/ If I want to use a linkedSignal with the resource value, it will be called twice for only one reload



### Proposed solution

I think It would be nice if there was a way to force value to persists while it's loading (like when we call the reload() function)
Maybe by using an option ?
Or by making the behavior of reload() the default behavior since we can test _status_ to know the validity of _value_



### Alternatives considered

Testing status() === ResourceStatus.Loading in a linkedSignal and use it in the template instead of using _tableResource.value_

```typescript
data: WritableSignal<TableData[]> = linkedSignal({
  source: () => ({
    value: this.tableResource.value(),
    status: this.tableResource.status(),
  }),
  computation: (source, previous) => {
    if (previous && source.status === ResourceStatus.Loading) {
      return previous.value;
    }
    return source.value ?? [];
  }
});
```
Repository: rust
Issue: Tracking issue for RFC 3458: Unsafe fields
Labels: T-lang,C-tracking-issue,B-experimental,F-unsafe_fields

This is a tracking issue for:

- https://github.com/rust-lang/rfcs/pull/3458

The feature gate for the issue is `#![feature(unsafe_fields)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Approve as lang experiment.
- [ ] Accept an RFC.
  - https://github.com/rust-lang/rfcs/pull/3458
- [ ] Implement in nightly.
  - https://github.com/rust-lang/rust/pull/132915
  - https://github.com/rust-lang/rust/pull/133934
  - https://github.com/rust-lang/rust/pull/134008
  - [ ] Add rustdoc support
- [ ] Add documentation to the [dev guide][].
  - See the [instructions][doc-guide].
- [ ] Add documentation to the [reference][].
  - See the [instructions][reference-instructions].
- [ ] Add formatting for new syntax to the [style guide][].
  - See the [nightly style procedure][].
- [ ] Stabilize.
  - See the [instructions][stabilization-instructions].

[dev guide]: https://github.com/rust-lang/rustc-dev-guide
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[edition guide]: https://github.com/rust-lang/edition-guide
[nightly style procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md
[reference]: https://github.com/rust-lang/reference
[reference-instructions]: https://github.com/rust-lang/reference/blob/master/CONTRIBUTING.md
[stabilization-instructions]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[style guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions

TODO.

### Related

TODO.

cc @jswrenn @veluca93 @jhpratt @rust-lang/lang
Repository: TypeScript
Issue: Change the behavior of `tsc` on a tsconfig solution
Labels: Suggestion,In Discussion

### 🔍 Search Terms

The Vite starters now use a "solution" tsconfig, as documented in the docs.  

The issue is that a lot of people are used to run `tsc` or `tsc --noEmit` at the root of the project, and now, this silently does nothing.

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

I think in that specific case, it should do one of those two things:

- make it an error in that case with "You probably want tsc -b"
- default to build mode (when the tsconfig contains `files: []`)

### 📃 Motivating Example

You have three chars less to type? 😅

More seriously, it's about making project references more used without a familiar command becoming useless

### 💻 Use Cases

2. What shortcomings exist with current approaches?

We get some reports like this: https://github.com/vitejs/vite/issues/17585

I suspect a lot more people fall for this, but find the issue before opening an issue
Repository: three.js
Issue: GLTFExporter: Provide a way to export a mesh with multiple primitives
Labels: Enhancement

### Description

Currently when exporting a model with GLTFLoader all geometry-material pairs are separated into different "mesh" nodes that all have a single primitives in the final GLTF file. This sacrifices a lot of control over the final file, though, since GLTF can support multiple primitives (with unique material per primitive) per mesh. When just working in three.js this may be okay but other tools interpret these multi-primitive meshes differently. Unreal, for example, will load them as a single object with multiple materials assigned which is significantly easier for an artist to work with.

My current situation is that I'm trying to simplify a complex model and merge meshes components into semantic components with multiple materials for use in Unreal using three.js but the exporter doesn't allow for control over primitives. The reason I'm using three.js is because merging geometry and  reasoning about & adjusting the hierarchy is simpler than other tools I've used.

cc @donmccurdy 

### Solution

**Provide GLTFPrimitive, GLTFMesh Subclasses**

When importing a GLTF two `GLTFPrimitive` and `GLTFMesh` subclasses could be provided to better represent the original structure of the imported GLTF. Then the GLTFExporter could use these classes to export the structure reflected by these classes. This would allow for more user control of the structure, as well, since they could be created as-needed. Alternatively a flag in `userData` could be added to support the same thing.

### Alternatives

I've looked into gltf-transform for this but managing the hierarchy is not as clear or easy to visualize.

### Additional context

_No response_
Repository: terminal
Issue: Add options to control the new Builtin Box Drawing Glyphs
Labels: Help Wanted,Area-Settings,Product-Terminal,Issue-Task

### Description of the new feature

Since the new Builtin Box Drawing Glyph feature is parametric, exposing some of it to the user could be beneficial.

Specifically Line Width and Roundiness is most useful if a user wants to emulate the look of the original box drawing characters.

### Proposed technical implementation details

_No response_
Repository: godot
Issue: ENet Node not found errors
Labels: bug,topic:network

### Tested versions

I'm pretty sure it can be reproduced in any version.

### System information

Windows 11 64bit, Godot 4.3 stable win64

### Issue description

RPC calls can arrive to clients before the node is replicated and after it's freed, causing 'get_node: Node not found: NodePath' errors.

### Steps to reproduce

1. Create a basic server/client template
2. Create a simple test node which calls an rpc function every frame
3. Instantiate the test node during the game
4. Observe pre-replication Node not found errors
5. Wait a few seconds
6. Free the test node
7. Observe post-freedom Node not found errors

Alternative steps for the MRP:
1. Run the project
2. Observe errors

### Minimal reproduction project (MRP)

[node-not-found-errors.zip](https://github.com/user-attachments/files/17709175/node-not-found-errors.zip)
Repository: pytorch
Issue: AWS A100 runners reliability issue
Labels: high priority,module: ci,triaged

Compiler team reports that there are still some reliability issues with AWS A100 where some runners start to crash since last weekend. For example,

* https://github.com/pytorch/pytorch/actions/runs/11763098772
* https://github.com/pytorch/pytorch/actions/runs/11773760797/attempts/1

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @seemethere @malfet @pytorch/pytorch-dev-infra @jeanschmidt @ZainRizvi @desertfire 

Also @yangw-dev as this might be an interesting case for utilization monitoring because:

* Runner lost communication with server usually indicates OOM or a botched runner update.  Monitoring memory usage would help with OOM
* The hardware is shared, but each runner runs independently in its own cgroups / docker container https://fb.workplace.com/groups/pytorch.dev.perf.infra.teams/permalink/9137566856262424.  We probably want to monitor each of them independently
Repository: next.js
Issue: Conditionally Rendering Form Component Causes Server Action Error
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/elastic-raman-mdp554

### To Reproduce

I attached the CodeSandbox for a minimal reproduction. I am purposely calling the action from onSubmit so that I can do both client-side and server-side validation. I removed explicit validation parts as it reproduces without it.
```
    <form
      ref={formRef}
      action={formAction}
      onSubmit={() => {
        formRef.current?.submit();
      }}
    >
      <div>
        <label htmlFor="email">Your email</label>
        <input id="email" name="email" type="email" required />
      </div>
      <button type="submit">Reset password</button>
    </form>
```

In my reproduction, I have 2 forms. If I use the `useState()` toggle to turn on/off the other form, I will get the following error:

<img width="1233" alt="image" src="https://github.com/user-attachments/assets/fd0d39eb-2493-4165-9e11-785aa806a8b4">

If I don't have the toggle, I won't get the error and I will see the server action complete:
<img width="258" alt="image" src="https://github.com/user-attachments/assets/00481aad-e208-4e62-aa22-e300db0dd6d5">

### Current vs. Expected behavior

I expect server actions to work regardless of whether there is conditional rendering of the component or not.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.0.4-canary.6 // Latest available version is detected (15.0.4-canary.6).
  eslint-config-next: N/A
  react: 19.0.0-rc-5c56b873-20241107
  react-dom: 19.0.0-rc-5c56b873-20241107
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Runtime

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

Someone else encountered the same scenario here: https://github.com/vercel/next.js/discussions/56234#discussioncomment-9554752
Repository: rust
Issue: non-camel-case-types lint does not flag `repr(C)` types
Labels: A-lints,T-lang,T-compiler,C-discussion,A-repr,L-non_camel_case_types

### Code

```Rust
#![forbid(non_camel_case_types)]

#[repr(C)]
pub struct foo_bar {}
```

### Current output

```Shell
<no error>
```

### Desired output

```Shell
Compiling playground v0.0.1 (/playground)
error: type `foo_bar` should have an upper camel case name
 --> src/lib.rs:4:12
  |
4 | pub struct foo_bar {}
  |            ^^^^^^^ help: convert the identifier to upper camel case: `FooBar`
  |
note: the lint level is defined here
 --> src/lib.rs:1:11
  |
1 | #![forbid(non_camel_case_types)]
  |           ^^^^^^^^^^^^^^^^^^^^

error: could not compile `playground` (lib) due to 1 previous error
```

### Rationale and extra context

This was clearly an explicit design choice at one point: <https://github.com/rust-lang/rust/blob/81eef2d362a6f03db6f8928f82d94298d31eb81b/compiler/rustc_lint/src/nonstandard_style.rs#L170>

Presumably, the idea was that you'd have a bunch of FFI types with their native C names, and that's what `repr(C)` is for. You wouldn't want this lint firing for such types.

But I don't think it's one that makes sense today. `repr(C)` is used any time you want a stable layout, not just when you're defining a C type for FFI. The lint should fire in all cases, and crates that define a bunch of C types should silence the lint where appropriate.

### Other cases

```Rust

```

### Rust Version

```Shell
> rustc --version --verbose
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1
```

### Anything else?

_No response_
Repository: go
Issue: cmd/go: TestScript/fileline failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/go" && test == "TestScript/fileline"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8731521742206735809)):

    === RUN   TestScript/fileline
    === PAUSE TestScript/fileline
    === CONT  TestScript/fileline
        script_test.go:139: 2024-11-11T23:59:59Z
        script_test.go:141: $WORK=/Users/swarming/.swarming/w/ir/x/t/cmd-go-test-2262759160/tmpdir2484956214/fileline2287564947
        script_test.go:163: 
            PATH=/Users/swarming/.swarming/w/ir/x/t/cmd-go-test-2262759160/tmpdir2484956214/testbin:/Users/swarming/.swarming/w/ir/x/w/goroot/bin:/Users/swarming/.swarming/w/ir/x/w/goroot/bin:/Users/swarming/.swarming/w/ir/x/w/goroot/bin:/Users/swarming/.swarming/w/ir/cache/tools/bin:/Users/swarming/.swarming/w/ir/bbagent_utility_packages:/Users/swarming/.swarming/w/ir/bbagent_utility_packages/bin:/Users/swarming/.swarming/w/ir/cipd_bin_packages:/Users/swarming/.swarming/w/ir/cipd_bin_packages/bin:/Users/swarming/.swarming/w/ir/cipd_bin_packages/cpython3:/Users/swarming/.swarming/w/ir/cipd_bin_packages/cpython3/bin:/Users/swarming/.swarming/w/ir/cache/cipd_client:/Users/swarming/.swarming/w/ir/cache/cipd_client/bin:/Users/swarming/.swarming/cipd_cache/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
            HOME=/no-home
            CCACHE_DISABLE=1
            GOARCH=amd64
    ...
            > ! go run ../../gopath/x/y/z/err.go
            [stderr]
            ../x/y/z/err.go:1:22: cannot find package "bar" in any of:
            	/Users/swarming/.swarming/w/ir/x/w/goroot/src/bar (from $GOROOT)
            	/Users/swarming/.swarming/w/ir/x/t/cmd-go-test-2262759160/tmpdir2484956214/fileline2287564947/gopath/src/bar (from $GOPATH)
            [exit status 1]
            > stderr ^..[\\/]x[\\/]y[\\/]z[\\/]err.go:
            matched: ../x/y/z/err.go:1:22: cannot find package "bar" in any of:
        script_test.go:405: go was invoked but no counters were incremented
    --- FAIL: TestScript/fileline (0.60s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: PowerToys
Issue: Mouse zoom utility.
Labels: Needs-Triage

### Description of the new feature / enhancement

A mouse utility that lets users zoom in on small text and content, improving readability and focus for better visualization.

### Scenario when this would be used?

A mouse utility that enables users to quickly zoom in on small text and content, improving readability for tasks that involve fine details, like inspecting console log messages or object fields in web development. This eliminates the need to constantly zoom the browser or strain to read small text.

### Supporting information

_No response_
Repository: pytorch
Issue: Halide CPU backend numerical issue for inplace add
Labels: triaged,oncall: pt2,topic: inductor halide backend

### 🐛 Describe the bug

Found this bug when I debug a test failure in https://github.com/pytorch/pytorch/pull/140249

```
import torch
from torch._inductor import config

config.cpu_backend = "halide"

@torch.compile
def f(x, y):
    return x.add_(y)

x = torch.ones([2, 12, 13, 17]).transpose(1, 2)
y = torch.ones([2, 13, 1, 17])

f(x, y)
print(f"{x.numel()} {x.sum()}")
```

Correct result should be:
```
5304 10608.0
```
But the halide CPU backend generates:
```
5304 10680.0
```

### Error logs

.

### Versions

.

cc @ezyang @chauhang @penguinwu @jansel
Repository: pytorch
Issue: Flaky bot might be missing some data when making a judgement
Labels: module: ci,triaged

### 🐛 Describe the bug

See https://github.com/pytorch/pytorch/issues/139057 and https://github.com/pytorch/pytorch/issues/137771 that were closed today as no longer reproduced, only to be reopened soon afterwards as still happening

Which hints at some gaps in the logic that tracks whether or disabled tests are actually healthy

### Versions

CI

cc @seemethere @pytorch/pytorch-dev-infra
Repository: neovim
Issue: Terminal cleanup broken when resizing text in tmux, In WSL2
Labels: bug,tui

### Problem

**Description**:
Found an issue with how neovim cleans up the terminal screen when exiting after screen resize, but only happens inside tmux (or possibly other buffer based scroll-restricted environments).

**Current behavior**:
Neovim only partially cleans the screen, showing some of what was previously displayed instead of properly restoring the terminal state, when terminal got resized inside `nvim`.

**Theory**:
This may occurs because `tmux` stores output in a buffer and only shows the visible portion. `neovim` likely uses only the displayed content for cleanup and reprints, causing it to miss parts of the buffer outside the viewport. This discrepancy result in incomplete screen restoration when exiting `neovim` within `tmux` if the screen was resized inside `neovim`. 

**Possible Solution**:
If `neovim` could account for the full buffer `tmux` holds (not just the visible portion), it might better handle cleanup and restore the terminal state consistently. I believe vim already does that, cause this doesn't happen with vim.

**Environment**:
- Only tested on WSL ( but I belive this would be same on actual linux distros too )
- Happens consistently in tmux
- Might affect other scroll-restricted environments

**Screenshots**:
![Image](https://github.com/user-attachments/assets/0fed511b-3252-477e-ae46-99d62720ba3e)

> Let me know if you need any other info or want me to test something specific!

### Steps to reproduce

1. Start a tmux session
2. Have some terminal history (like 4-5 commands) above for better visibility
3. Open neovim (can be either empty buffer or existing file)
4. Resize the screen size (using ctrl-minus or equivalent zoom out)
5. Fill the screen with content (even empty lines work)
6. Exit neovim with :q!

### Expected behavior

**Expected behavior**:
Neovim should properly clean up the entire screen and restore the terminal state correctly, regardless of screen resize operations.

### Nvim version (nvim -v)

NVIM v0.11.0-dev

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

no, vim 8.2 ( only nvim failed even with `nvim -u DEFAULTS` )

### Operating system/version

Windows 11 ( WSL2 - Ubuntu )

### Terminal name/version

Windows terminal

### $TERM environment variable

xterm-256color

### Installation

System Package Manager (APT)