sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: 2D contact points at incorrect position, incorrect body interaction
Labels: bug,topic:physics,topic:2d

### Tested versions

Reproducible in 3.5.x , 3.6

### System information

Windows 10 - v3.5.3.stable.mono.official [6c814135b] .NET

### Issue description

The interaction between 2D bodies is occasionally wrong, bodies orientation get stuck at unnatural angles to the ground that should be unstable. Seem to be connected with the fact that contact points are sometimes calculated at wrong positions, well away from the bodies edges where they could touch.
![wrongcollision](https://github.com/user-attachments/assets/bb6b98fe-9981-412f-a2ca-37d6f3a85923)
RigidBody2D (in red) stuck at weird angle to a StaticBody2D (light blue), at the same time sliding freely across its surface. Blue crosses mark contact points, as reported for the rigidbody by Physics2DDirectBodyState . Wrong contact point seem to be placed at one of the vertices of the static polygon.

Normally contact points should appear where bodies edges are actually touching, and the rigidbody would fall counter clockwise to rest on its wider edge.

### Steps to reproduce

The issue observed when a RigidBody2D (polygon) slide into contact with a complex shaped StaticBody2D (polygon). Specific conditions unknown, but highly reproducible in certain situations, as in the attached project.

### Minimal reproduction project (MRP)

[testcollision.zip](https://github.com/user-attachments/files/17164303/testcollision.zip)
Repository: material-ui
Issue: [tabs] Add the ability to modify a tab via context
Labels: new feature,waiting for 👍,component: tabs

### Summary

Currently, MUI only allows retrieving the value of a tab through context, but it does not support the ability to modify or manage tabs dynamically via context. It would be beneficial to extend the functionality by adding the ability to modify the current tab value and other tab parameters through a context API.

### Examples

An example implementation could reference the Material Design specification, which outlines the possibility of dynamic component management via contexts. This would enable the creation of more flexible and interactive interfaces where tabs can be changed based on different conditions in the application.

```
<TabContext value={value} setValue={setValue}>
   <Tabs>
      ...
   </Tabs>
   
   // Inside the component, you can get setValue through the context
   <TabPanel>
      ...
   </TabPanel> 
</TabContext >
```

**Search keywords**: tabs, context
Repository: vscode
Issue: SCM - Going up past the start of a commit message goes into history and sometimes loses the commit message you were typing
Labels: scm,under-discussion

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.85.2
- OS Version: Windows 11

Steps to Reproduce:

1. click on source control on the bar on the left side that causes it to scroll
2. start typing a long commit message, then hit up arrow to go to the top, but overshoot and now it is going back in history
3. going back down sometimes it brings back what you were typing, but often it does not and you have to start over :(


I *really* want to disable this behavior so that VSCode will NOT scroll back to previous commit messages just by hitting the up arrow
Repository: ui
Issue: [bug]:Installation error, prompt read ECONNRESET
Labels: bug

### Describe the bug

Failed to run the installation using the latest documentation for the Next.js project.
npx shadcn@latest init



### Affected component/components

failing to setup the cli

### How to reproduce

node 20.9.0 
npm 10.1.0
Created a Next.js project using the command `npx create-next-app@latest`, and then executed `npx shadcn@latest init` in the Next.js directory.


### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
D:\next_Learn> npx shadcn@latest init
✔ Preflight checks.
✔ Verifying framework. Found Next.js.
✔ Validating Tailwind CSS.
✔ Validating import alias.


Something went wrong. Please check the error below for more details.
If the problem persists, please open an issue on GitHub.
request to https://ui.shadcn.com/r/styles/index.json failed, reason: read ECONNRESET
```


### System Info

```bash
window 11  x64
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: pytorch
Issue: Error when calling multiple backward passes on FSDP model
Labels: triaged,module: fsdp

### 🐛 Describe the bug

When trying to add FSDP to our training code base that includes a pipelining scheme I encountered an issue if forward and backward passes are no longer interleaved but instead multiple backward passes directly follow each other. I was able to reproduce this in a minimal setup:

```python
import os
import torch
from torch.distributed import fsdp
import torch.multiprocessing as mp

def run(rank, world_size):
    torch.cuda.set_device(rank)
    torch.distributed.init_process_group(
        world_size=world_size,
        rank=rank,
    )

    ffn = torch.nn.Sequential(torch.nn.Linear(10, 10), torch.nn.Linear(10, 10))

    ffn = fsdp.FullyShardedDataParallel(ffn, device_id=rank)

    x1 = torch.rand((10, 10)).cuda()
    loss1 = ffn(x1).sum()

    x2 = torch.rand((10, 10)).cuda()
    loss2 = ffn(x2).sum()

    loss1.backward()

    #ffn._handle._needs_pre_backward_unshard = True
    loss2.backward()

if __name__ == "__main__":
    os.environ["MASTER_ADDR"] = "localhost"
    os.environ["MASTER_PORT"] = "12355"
    world_size = 2
    mp.spawn(
        run,
        args=(world_size,),
        nprocs=world_size,
        join=True,
    )
```

The error I observe is:
```
-- Process 1 terminated with the following error:
Traceback (most recent call last):
  File "*/pytorch/torch/multiprocessing/spawn.py", line 90, in _wrap
    fn(i, *args)
  File "torch_fsdp_pp.py", line 26, in run
    loss2.backward()
  File "*/pytorch/torch/_tensor.py", line 581, in backward
    torch.autograd.backward(
  File "*/pytorch/torch/autograd/__init__.py", line 347, in backward
    _engine_run_backward(
  File "*/pytorch/torch/autograd/graph.py", line 825, in _engine_run_backward
    return Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
RuntimeError: setStorage: sizes [10, 10], strides [10, 1], storage offset 110, and itemsize 4 requiring a storage size of 840 are out of bounds for storage of size 0
```

In my understanding the parameters are not unsharded in the second call to `backward()`. I was able to enforce this by manually setting `ffn._handle._needs_pre_backward_unshard = True` as indicated in the sample code. In this case the sample passes. 

Is there another way to resolve this issue? I was not able to find any indication for a solution in `torch.distributed.pipelining`


### Versions

PyTorch version: 2.6.0a0 <- current main branch
CUDA used to build PyTorch: 12.5


cc @zhaojuanmao @mrshenli @rohan-varma @awgu @fegin @kwen2501 @chauhang
Repository: godot
Issue: centerContainer anchor preset doesn't actually center the first time you select the center option
Labels: bug,topic:editor,topic:gui

### Tested versions

- Reproducible in: Godot_v4.2.2-stable_win64


### System information

Windows 11 - Godot v4.2.2.stable - Forward+ - dedicated

### Issue description

Adding a centerContainer to a Control Node as a child and then setting centerContainer's layout mode to Anchors and Anchors Preset to Center will not fully center the layout. The control node is the child of another node as well. 

### Steps to reproduce

1. Add a Control Node as a child of another node. 
2. Add a centerContainer as a child of the Control node. 
3. Set Control node anchor preset to full rect
4. set centerContainer layout mode to anchors
5. set centerContainer anchors preset to center. 

You will then see that centerContainer is not actually center and the way to fix this is to select its anchors preset and set it to H Center Wide and then set it back to center

### Minimal reproduction project (MRP)

[main.zip](https://github.com/user-attachments/files/17166694/main.zip)
Repository: go
Issue: x/net/quic: TestUDPSourceSpecified/udp4/udp/unspec failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/net/quic" && test == "TestUDPSourceSpecified/udp4/udp/unspec"
```

Issue created automatically to collect these failures.

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

    === RUN   TestUDPSourceSpecified/udp4/udp/unspec
    panic: test timed out after 10m0s
    running tests:
    	TestUDPSourceSpecified (10m0s)
    	TestUDPSourceSpecified/udp4/udp/unspec (10m0s)
    
    goroutine 1742 [running]:
    testing.(*M).startAlarm.func1()
    	/Volumes/Work/s/w/ir/x/w/goroot/src/testing/testing.go:2366 +0x30c
    created by time.goFunc
    ...
    
    goroutine 1770 [chan receive, 9 minutes]:
    golang.org/x/net/quic.TestUDPSourceSpecified.func1(0x1400012d380, {0x140001c9a40, 0x140001c9b00, {{{0x0, 0xffff7f000001}, 0x140001180a8}, 0xc3fe}, 0x1400001f140})
    	/Volumes/Work/s/w/ir/x/w/targetrepo675238800/quic/udp_test.go:47 +0x174
    golang.org/x/net/quic.runUDPTest.func1(0x1400012d380)
    	/Volumes/Work/s/w/ir/x/w/targetrepo675238800/quic/udp_test.go:180 +0x454
    testing.tRunner(0x1400012d380, 0x140001184c8)
    	/Volumes/Work/s/w/ir/x/w/goroot/src/testing/testing.go:1689 +0xec
    created by testing.(*T).Run in goroutine 1769
    	/Volumes/Work/s/w/ir/x/w/goroot/src/testing/testing.go:1742 +0x318


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: x/net/http2: TestServer_Rejects_Too_Many_Streams failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/net/http2" && test == "TestServer_Rejects_Too_Many_Streams"
```

Issue created automatically to collect these failures.

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

    === RUN   TestServer_Rejects_Too_Many_Streams
        server_test.go:2292: got stream ID 3, want 1
    panic: test timed out after 20m0s
    	running tests:
    		TestServer_Rejects_Too_Many_Streams (19m57s)
    
    goroutine 1754 [running]:
    testing.(*M).startAlarm.func1()
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/testing.go:2456 +0x4d8
    created by time.goFunc
    ...
    
    goroutine 1230 [select, 19 minutes]:
    golang.org/x/net/http2.(*serverConn).serve(0xc0003db880)
    	/home/swarming/.swarming/w/ir/x/w/targetrepo2947865698/http2/server.go:985 +0xcf0
    golang.org/x/net/http2.(*Server).serveConn(0xc0005148a0, {0x6ec108, 0xc0000a9860}, 0xc0001a1f50, 0xc0001a1fb0)
    	/home/swarming/.swarming/w/ir/x/w/targetrepo2947865698/http2/server.go:578 +0x1400
    golang.org/x/net/http2.newServerTester.func3()
    	/home/swarming/.swarming/w/ir/x/w/targetrepo2947865698/http2/server_test.go:204 +0x1bc
    created by golang.org/x/net/http2.newServerTester in goroutine 1229
    	/home/swarming/.swarming/w/ir/x/w/targetrepo2947865698/http2/server_test.go:202 +0xe0c


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: x/vulndb/internal/symbols: TestPatchedSymbols fails unless it is run inside a git repository checkout
Labels: NeedsInvestigation,vulncheck or vulndb

```
#!watchflakes
default <- pkg == "golang.org/x/vulndb/internal/symbols" && test == "TestPatchedSymbols"
```

Issue created automatically to collect these failures.

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

    === RUN   TestPatchedSymbols
        patched_functions_test.go:42: lstat testdata/module: no such file or directory
        patched_functions_test.go:46: lstat testdata/fixed-module: no such file or directory
        patched_functions_test.go:54: (-got, want+):
              map[symbols.symKey]bool{
            + 	{pkg: "golang.org/module", symbol: "Foo"}:          true,
            + 	{pkg: "golang.org/module/internal", symbol: "Bar"}: true,
              }
        patched_functions_test.go:42: lstat testdata/module: no such file or directory
        patched_functions_test.go:46: lstat testdata/fixed-module: no such file or directory
        patched_functions_test.go:54: (-got, want+):
              map[symbols.symKey]bool{
            + 	{pkg: "golang.org/nestedmodule", file: "main_linux.go", symbol: "main"}: true,
              }
    --- FAIL: TestPatchedSymbols (0.00s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: go/types: position-independent type checking
Labels: NeedsInvestigation

The following go/types APIs all use Pos in semantically significant ways:
```
Scope.LookupParent(name, pos)
Scope.Contains(pos)
Scope.Innermost(pos)
CheckExpr(fset, pkg, pos, expr, info)
Eval(fset, pkg, pos)
```
As the doc comment on Innermost says, "The result is guaranteed to be valid only if the type-checked AST has complete position information." This restriction applies equally to all these operations, and should probably be made explicit for all of them.

For example, Scope.LookupParent uses the position of the reference to compute the set of declarations that are in scope. This assumes the position information is accurate, which it is for trees produced by the parser, but not for ones that have been modified by refactoring algorithms or synthesized directly. It should be possible to type-check any syntax tree correctly, even without accurate position information.

In each case, the position is used as a shorthand to indicate the portion of the environment that is accessible at a given point. It would be possible to provide parallel APIs for these 5 functions, without the restriction, that replaces pos with a different parameter that indicates the environment. For example, it could be something like an []ast.Node indicating a path from the root of the tree to the designated node.

Internally, the tree of Scopes could record the environment in a form that is independent of position, similar to my lazy type checker, which mapped each Node to a pair of a Scope and an int that represents the length of the prefix of Scope symbols that are in scope at that point. Ignoring efficiency concerns, I imagine the existing Pos-based functions could become wrappers around a function that resolves a Pos to a []Node (assuming valid pos info), followed by a call to the []Node-based API.

This would open the door to composable refactorings that mutate the tree in a sequence of passes, invalidating position info but still allowing the type checker to be reinvoked after each mutation, before finally formatting the tree to produce the updated output.  There are still many open questions about how to build such refactorings: we rely heavily on pos for debugging and error reporting; re-typechecking may require additional packages that were not needed before; and so on. But it is both viable and desirable to make the type checker itself fully independent of syntax positions, so they are used only for error messages, or passed through to Object.Pos, but have no semantics.
Repository: vscode
Issue: Fix warnings in default keybindings file
Labels: debt,notebook

Windows (might not matter):

![Image](https://github.com/user-attachments/assets/94a0f41a-b80a-4adc-a15d-adee863a17c7)
Repository: rust
Issue: Outlives requirements are not implied in the return type of `async fn`, and generally for RPIT
Labels: A-impl-trait,C-bug,A-async-await,AsyncAwait-Triaged,T-types,A-implied-bounds

Split from #102682

The following doesn't compile:

```rust
trait MyTrait<T> {
    async fn foo(&self) -> &T;
}
```

it gives the following:
```
error[E0311]: the parameter type `T` may not live long enough
 --> <source>:2:5
  |
2 |     async fn foo(&self) -> &T;
  |     ^^^^^^^^^^^^^-^^^^^^^^^^^^
  |     |            |
  |     |            the parameter type `T` must be valid for the anonymous lifetime as defined here...
  |     ...so that the reference type `&T` does not outlive the data it points at
  |
help: consider adding an explicit lifetime bound
  |
2 |     async fn foo<'a>(&'a self) -> &'a T where T: 'a;
  |                 ++++  ++           ++   +++++++++++
```

of course, a normal function is fine. We just don't imply that `T: '_` here because it lowers to `impl Future<Output = &'_ T>`
Repository: rust
Issue: Decimal formatting for some floating point numbers does not round-to-even
Labels: T-compiler,C-bug,T-libs,A-floating-point,A-fmt

I have discovered a class of `f64` for which `format!("{}", f)` rounds ties up to 3, rather than down to 2 as expected. Formatting those same numbers with fixed precision correctly rounds ties to even.

Here is some code that demonstrates the discrepancy:
```
fn main() {
    let fs: [f64; 15] = [
        112171935477118.12,
        181681934355391.62,
        -581170764721946.2,
        131673329546813.62,
        711901304153173.2,
        91266877191838.12,
        18406814307348.312,
        -620793498637746.2,
        -889345962364809.2,
        -664193405104534.2,
        -157386457699813.12,
        566922914748074.2,
        223437609802779.12,
        945017102864441.2,
        32461450983719.062,
    ];

    for f in fs {
        let no_precision = format!("{}", f);
        let mut split = no_precision.split('.');
        let _int = split.next();
        let frac = split.next().unwrap();
        let precision = frac.len();
        println!("{} != {:.2$}", f, f, precision);
    }
```

This program prints:
```
112171935477118.13 != 112171935477118.12
181681934355391.63 != 181681934355391.62
-581170764721946.3 != -581170764721946.2
131673329546813.63 != 131673329546813.62
711901304153173.3 != 711901304153173.2
91266877191838.13 != 91266877191838.12
18406814307348.313 != 18406814307348.312
-620793498637746.3 != -620793498637746.2
-889345962364809.3 != -889345962364809.2
-664193405104534.3 != -664193405104534.2
-157386457699813.13 != -157386457699813.12
566922914748074.3 != 566922914748074.2
223437609802779.13 != 223437609802779.12
945017102864441.3 != 945017102864441.2
32461450983719.063 != 32461450983719.062
```

### Meta
`rustc --version --verbose`:
```
rustc 1.83.0-nightly (2bd1e894e 2024-09-26)
binary: rustc
commit-hash: 2bd1e894efde3b6be857ad345914a3b1cea51def
commit-date: 2024-09-26
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```
Repository: deno
Issue: WebGPU code works in browser but not in Deno, divergence from specification?
Labels: bug,upstream,webgpu

Version: deno 2.0.0-rc.6

The linked project
https://github.com/dezmou/SHA256-WebGPU
works in browser (latest Chrome stable on Windows), but doesn't work in Deno.

Deno fails in multiple ways:

Firstly
```
Device::create_shader_module error: 
Shader '' parsing error: failed to convert expression to a concrete type: the concrete type `i32` cannot represent the abstract value `3144134277` accurately
    ┌─ wgsl:183:20
    │
183 │     ctx.state[1] = 0xbb67ae85;
    │                    ^^^^^^^^^^ this expression has type {AbstractInt}
    │
    = note: the expression should have been converted to have i32 scalar type


00000000000000000000000000000000
```

If fixed by appending u to the end of these constants, Deno fails again with
```
Device::create_shader_module error: 
Shader validation error: 
   ┌─ :33:3
   │
33 │   fn EP0(x : u32) -> u32{return (ROTRIGHT(x,2) ^ ROTRIGHT(x,13) ^ ROTRIGHT(x,22));}
   │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   │   │                              │          │
   │   │                              │          naga::Expression [2]
   │   │                              invalid function call
   │   naga::Function [5]


00000000000000000000000000000000
```

Deno shouldn't prevent code that works in browser from working in Deno.

Test was performed by concatenating sha256shader.js + ' \n' + sha256.js and the lines
const result = await sha256("");
console.log(result);
Repository: vscode
Issue: Right side blue focus outline of chat is missing if we maximize the chat panel
Labels: bug,ux,panel-chat

![image](https://github.com/user-attachments/assets/85a1fa69-3ebc-432e-a8ea-c44b9a67629f)

right side blue outline of the missing if we maximize the chat panel
Repository: rust
Issue: `gen fn` with lifetime issue yields nonsensical suggestion
Labels: A-diagnostics,T-compiler

### Code

```rust
#![feature(gen_blocks)]

struct Value<'a>(&'a ());

struct Container<'a> {
    x: Value<'a>,
}

impl<'a> Container<'a> {
    gen fn f(&self) -> &'a Value {
        yield &self.x
    }
}
```

### Current output

```
error: lifetime may not live long enough
  --> <source>:10:34
   |
9  |   impl<'a> Container<'a> {
   |        -- lifetime `'a` defined here
10 |       gen fn f(&self) -> &'a Value {
   |  ______________-___________________^
   | |              |
   | |              let's call the lifetime of this reference `'1`
11 | |         yield &self.x
12 | |     }
   | |_____^ method was supposed to return data with lifetime `'a` but it is returning data with lifetime `'1`
   |
help: consider adding 'move' keyword before the nested closure
   |
10 |     gen fn f(&self) -> &'a Value move {
   |                                  ++++
```

### Desired output

```
<the `move` suggestion should not be given>
```

### Rationale and extra context

[Godbolt link](https://godbolt.org/z/a4sfrzTnh)

The correct suggestion would be to suggest `&'a Value<'a>` as `f`’s return type (or no suggestion at all).

Additionally, I don’t understand why this is an error in the first place? Given that `Self` contains lifetime `'a`, the elided lifetime of `&self` must clearly be outlived by `'a`? For reference, this works when directly returning `&'a Value` without a generator ([Godbolt link](https://godbolt.org/z/v8EfrqGfG)):
```rust
#![allow(unused)]

struct Value<'a>(&'a ());

struct Container<'a> {
    x: Value<'a>,
}

impl<'a> Container<'a> {
    fn f(&self) -> &'a Value {
        &self.x
    }
}
```

Tracking issue: #117078

### Other cases

_No response_

### Rust Version

```
rustc 1.83.0-nightly (2bd1e894e 2024-09-26)
binary: rustc
commit-hash: 2bd1e894efde3b6be857ad345914a3b1cea51def
commit-date: 2024-09-26
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```

### Anything else?

_No response_
Repository: rust
Issue: kind filters are insufficently documented
Labels: T-rustdoc,A-docs,A-rustdoc-search,T-rustdoc-frontend

some of these, like `tymethod`, i don't even know what they do.

there's a list in the formal search syntax, but there's a lot of missing descriptions.

the "search tricks" inline help also *seems* to have an "exhaustive" list, but is actually missing a ton of kinds.

https://doc.rust-lang.org/nightly/rustdoc/read-documentation/search.html