sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [material-ui][Bottom Navigation] Not showing up on the bottom of the page
Labels: bug 🐛,component: bottom navigation,package: material-ui,ready to take

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://sweet-seahorse-923fd1.netlify.app/

Steps:

1. Open the url
2. Close current tab / open new tab
3. paste the url
4. you can see the bottom nav is missed
5. touching the screen or scroll it will display the navbar

![image](https://github.com/mui/material-ui/assets/22367469/73d6253d-0f8b-4a93-a6fc-0fab88362405)



### Current behavior 😯

Now the navbar doesn't show up on bottom of the page

### Expected behavior 🤔

The navbar should be dispalyed when open on new tab

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>next js 14</code></summary>
</details>
<details>
  <summary><code>node 18.17</code></summary>
</details>
<details>
  <summary><code>chrome mobile version 120 latest</code></summary>
</details>
Repository: ant-design
Issue: Select嵌套Typography.Text 开启缩略，版本4 5 的表现不一样，v5展示不出来tooltip
Labels: 🐛 Bug,Inactive,unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/typography-text-4-l78t3j?file=%2Fsrc%2FApp.tsx%3A30%2C69)

### Steps to reproduce

https://codesandbox.io/p/sandbox/typography-text-4-l78t3j?file=%2Fsrc%2FApp.tsx%3A30%2C69

https://codesandbox.io/p/sandbox/typography-text-5-qfv2nq?file=%2Fsrc%2FApp.tsx%3A10%2C19

### What is expected?

v5可以展示出来

### What is actually happening?

-

| Environment | Info |
| --- | --- |
| antd | 5.12.5 |
| React | react |
| System | macos |
| Browser | chrome最新 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: Collapsed diff should also collapse the diff when there are no changes at all (happens in clean rename and other events)
Labels: feature-request,diff-editor

Now that we have collapsed diff as per #3562 what I want is that if a diff has no changes at all, it should just collapse completely, showing nothing but a helpful message in the dead center of the editor pane (I think it's called a skeleton screen or an empty state):

<img width="850" alt="image" src="https://github.com/microsoft/vscode/assets/6047296/4fbad5f6-f7ea-4355-849c-ae1dbe61da5d">

At present, it shows the entire file by default, which is a little confusing when I'm browsing the diff of each file in the repository side panel. The above suggestion will hide the file contents by default, and only show it when the "View entire file" link is clicked.

Currently this happens when any of the following happens:

- The staged changes are committed while a collapsed diff from the index is open. (In this case, the diff suddenly expands to show the whole file. It's jarring.)
- The staged changes are unstaged while a collapsed diff from the index is open. (See above.)
- The unstaged changes are staged while a collapsed diff from the working tree is open. (See above.)
- A file is renamed and the rename is staged, with no changes in the file's contents. View the diff of the rename from the staged changes list.

NOTE: If the "Toggle Collapse Unchanged Regions" option is turned OFF, it can show the whole file by default, since that is the expected behavior anyway. But when it is turned ON, we should collapse in all conditions, including a total collapse.

NOTE: One thing to be careful of: When I'm actively editing a diff from the working tree, if the diff becomes a "no-change" diff due to my typing, it shouldn't suddenly collapse to this empty state. The collapse should only happen when the diff is updated by an external event.

_I think I couldn't find a duplicate, but this topic can also be really hard to search in the Issues list. If you know of a duplicate or a similar issue, please mention it. We can move the discussion there._
Repository: deno
Issue: Support passing paths to `--watch` flag of `deno test`
Labels: good first issue,feat

Currently, the following works as expected:

```sh
deno run --watch=watched-file.ts other-file.ts
```

However, the following fails:

```sh
deno test --watch=watched-file.ts other-file.ts
# error: unexpected value 'watched-file.ts' for '--watch' found; no more were expected
```

It seems like there isn't currently any way to customize the files that watched with the `test` command. It's also somewhat unexpected that `--watch` wouldn't work identically between `run` vs `test` (but I guess it might need to work somewhat differently due to multiple entrypoints?)

Motivating use case: test suite includes some doc tests that run code blocks found in markdown files, so the tests should be re-run on changes to the markdown files as well as ts/js files.
Repository: pytorch
Issue: Convolution NN for complex numbers and more special functions
Labels: feature,triaged,module: complex

### 🚀 The feature, motivation and pitch

Some people would like to use complex convolutional neural nets for Fourier series for MPS. Implement more functions like airy, jacobi theta, elliptical integrals. Please implement LBFGS and AdAM, SGD for special functions like Bessel, airy, jacobi theta functions. Thanks! 

### Alternatives

Hm, not easy to rewrite conv2d to process complex floats. 

### Additional context

First implement complex convolution for MPS and Cuda

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved
Repository: rust
Issue: make incremental ICEs more informative 
Labels: A-diagnostics,T-compiler,A-incr-comp,WG-incr-comp

We are getting a couple of "compiler crashed spuriously due to incr comp, not reproducible" ICEs every week for years now.
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-incr-comp

I wonder if we can print more data during/before the ice, if it occurs, to help us track down what the actual problem is.
So far the various stacktraces have not been too helpful without a clear reproducer afaik.
A similar approach made for a parallel compiler deadlock had great success https://github.com/rust-lang/rust/pull/118169/
Repository: ant-design
Issue: Scrollbar Issue on Table elements on iPad Devices
Labels: Inactive,📱Mobile Device,unconfirmed

### Reproduction link

[https://www.loom.com/share/3f31bf796eb5405aabf435475981f637?sid=dc5790a9-6e01-4433-b3bc-036f44815568](https://www.loom.com/share/3f31bf796eb5405aabf435475981f637?sid=dc5790a9-6e01-4433-b3bc-036f44815568)

### Steps to reproduce

1. Open Antd docs https://ant.design/components/table#components-table-demo-grouping-columns
2. Go to the table and scroll up and down, you can notice that the scrollbar is glitchy especially if the table is scrollable horizontally too
3. Check this with an Ipad device. (I tested on iPad Pro 12.9 2020)

### What is expected?

It is expected the scrollbar to scroll smoothly, same as it does for other devices

### What is actually happening?

It glitches

| Environment | Info |
| --- | --- |
| antd | 4.24.3 |
| React | 18.2.0 |
| System | MacOs |
| Browser | Safari and Chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Conflict implementation when upstream crate has any impl for any type_alias_impl_trait type
Labels: A-trait-system,C-bug,F-type_alias_impl_trait,T-types,A-coherence


I tried this code:

```rust
/// in crate A
pub trait Test {}

struct A;

impl Test for A {}

pub type OpaqueA = impl Test;
pub fn decide_type() -> OpaqueA {
  A
}

pub trait Test2 {}

impl Test2 for OpaqueA {}


/// end of crate A


/// in crate B that depends on crate A

pub struct B;

impl Test2 for B {}

/// end of crate B
```

I expected to see this happen: compiled successfully

Instead, this happened: failed to compile crateB

```
error[E0119]: conflicting implementations of trait `crateA::Test2` for type `crateA::OpaqueA`
```


### Meta

`rustc --version --verbose`:
```
rustc 1.77.0-nightly (bf8716f1c 2023-12-24)
binary: rustc
commit-hash: bf8716f1cd6416266807706bcae0ecb2e51c9d4a
commit-date: 2023-12-24
host: aarch64-apple-darwin
release: 1.77.0-nightly
LLVM version: 17.0.6
```

if I merge crate B into crate A, it compiles.

This code works on the previous nightly-2023-06-12 at least.
Repository: godot
Issue: GD.Print doesn’t print anything using c# when in child node , only prints when using Godot_v4.2.1-stable_mono_win64_console.exe 
Labels: bug,needs testing,topic:dotnet

### Tested versions

Godot v4.2.1.stable.mono - Windows 10.0.19045 - GLES3 (Compatibility) - Intel(R) UHD Graphics 620 (Intel Corporation; 30.0.101.1338) - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 Threads)

### System information

Godot v4.2.1.stable.mono - Windows 10.0.19045 - GLES3 (Compatibility) - Intel(R) UHD Graphics 620 (Intel Corporation; 30.0.101.1338) - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 Threads)

### Issue description

Godot v4.2.1.stable.mono - Windows 10.0.19045 - GLES3 (Compatibility) - Intel(R) UHD Graphics 620 (Intel Corporation; 30.0.101.1338) - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 Threads)

No output from  GD.Print in child node 
Can see output from root node . 






### Steps to reproduce

load the project in Godot_v4.2.1-stable_mono_win64.exe
Create profile in visual studio 2022 as in documentation , 
Run Debug 
Only the root node  GD.Print output is in the editor  . the child node is not printing 

### Minimal reproduction project (MRP)

[TestMe.zip](https://github.com/godotengine/godot/files/13770801/TestMe.zip)
Repository: opencv
Issue: avcodec_get_context_defaults3 from ffmpeg is deprecated
Labels: bug,category: videoio

### System Information

I am compiling the 4.8.1 version of opencv, it complains about missing function avcodec_get_context_defaults3 from ffmpeg. I found that ffmpeg has already removed this function since 2021 commit. So should the using of this function be removed in opencv source? 

### Detailed description

```
 in function `CvVideoWriter_FFMPEG::open(char const*, int, double, int, int, cv::VideoWriterParameters const&)':
cap_ffmpeg.cpp:(.text._ZN20CvVideoWriter_FFMPEG4openEPKcidiiRKN2cv21VideoWriterParametersE+0xcec): undefined reference to `avcodec_get_context_defaults3'

```

### Steps to reproduce

1, compile ffmpeg from source (because I need a third-party hardware encoder/decoder)
2, compile opencv 4.8.1 with ffmpet support

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: material-ui
Issue: [joy-ui][List Item Button] The `select` prop renders differently on different browsers and viewports
Labels: external dependency,component: list,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://mui.com/joy-ui/getting-started/templates/order-dashboard/

Steps:
```tsx
<ListItemButton  selected>
  {item?.icon}
  <ListItemContent>
    <Typography level="title-sm">{item.label}</Typography>
  </ListItemContent>
</ListItemButton>
```


![image](https://github.com/mui/material-ui/assets/59496975/7e0ea48d-2997-4724-b31b-2a89212d23ad)

![image](https://github.com/mui/material-ui/assets/59496975/9fbe83d7-b5fa-41db-bc8e-cf65d48c1969)



### Current behavior 😯

When I focus on the window of the browser, it removes the selection,

When I remove my focus on the browser window, it returns the selection.

Also, when I minimize the window size, it returns the selection, and when I maximize it, it removes the selection.

The behaviur is different in Firefox, Google chrome and Brave browser.

It's causing unexpected behaviours, as I have tried it on 3 different computers. it turned out the there must be some sort of a bug.

### Expected behavior 🤔

The selection should be visible when the `select` prop is provided regardless of the platform, and the situation.

### Context 🔦

I tried it on 3 different browsers, they cause different behaviors always, and I also tried it on different view ports.

and I have noticed something, when you enable darkmode, the selection will be visible, the problem is only in the light mode.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
   System:
    OS: Linux 5.15 Linux Mint 21.2 (Victoria)
  Binaries:
    Node: 21.4.0 - ~/.nvm/versions/node/v21.4.0/bin/node
    Yarn: Not Found
    npm: 10.2.4 - ~/.nvm/versions/node/v21.4.0/bin/npm
  Browsers:
    Chrome: 120.0.6099.129
  npmPackages:
    @emotion/react: ^11.11.3 => 11.11.3 
    @emotion/styled: ^11.11.0 => 11.11.0 
    @mui/base:  5.0.0-beta.24 
    @mui/core-downloads-tracker:  5.15.2 
    @mui/icons-material: ^5.14.18 => 5.14.18 
    @mui/joy: ^5.0.0-beta.15 => 5.0.0-beta.15 
    @mui/material: ^5.15.2 => 5.15.2 
    @mui/private-theming:  5.15.2 
    @mui/styled-engine:  5.15.2 
    @mui/system:  5.15.2 
    @mui/types:  7.2.11 
    @mui/utils:  5.15.2 
    @mui/x-date-pickers: ^6.18.6 => 6.18.6 
    @types/react: ^18 => 18.2.39 
    react: ^18 => 18.2.0 
    react-dom: ^18 => 18.2.0 
    typescript: ^5 => 5.3.2 
```
</details>
Repository: godot
Issue: [3.5.3] Problem with CollisionShape2D
Labels: discussion,topic:2d

### Tested versions

3.5.3

### System information

Windows 10

### Issue description

When duplicating a CollisionShape2D node and stretching it, other nodes also change their size

### Steps to reproduce

1. Add a CollisionShape2D node
2. Resize it
3. Duplicate this node
4. Change its size (you will see that all CollisionShape2D nodes change the size)

### Minimal reproduction project (MRP)

the example is easy to repeat, it is not necessary
Repository: rust
Issue: query cycles could be handled more like ICEs 
Labels: A-diagnostics,metabug,T-compiler,A-query-system

from https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/recent-ish.20nightly.20regression.20wrt.20Freeze

Sometimes the compiler blurps out something like `error[E0391]: cycle detected when XYZ`

yay: the compiler saved itself from going in circles infinitely because it noticed it was trying to compute something self-referential

nay: we SHOULD have had a proper diagnostic earlier in which the compiler errors out and explains the user why the self-referential thing they are trying to do is not going to work out instead of just throwing a "oops, query cycle" in their face.

If we encounter such a query cycle, we should tell users to report it a diagnostic bug.
Maybe we can also improve the spans of the `E0391` a bit.

```
error[E0391]: cycle detected when looking up late bound vars
 --> /home/matthias/vcs/github/rust_misc_stuff/tests/ui/traits/inheritance/auxiliary/icemaker_omni/BE190CEE104A225CD4B33CFB5FA41C069766D54BE3319CDCF10B5BCBEC24AD11.rs:4:1
  |
4 | pub trait MyNum : Add<Output=Self> + MyNum<Output=Self> + Mul<Output=Self> + PartialEq + Clone {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: ...which requires resolving lifetimes...
 --> /home/matthias/vcs/github/rust_misc_stuff/tests/ui/traits/inheritance/auxiliary/icemaker_omni/BE190CEE104A225CD4B33CFB5FA41C069766D54BE3319CDCF10B5BCBEC24AD11.rs:4:1
  |
4 | pub trait MyNum : Add<Output=Self> + MyNum<Output=Self> + Mul<Output=Self> + PartialEq + Clone {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires computing the super traits of `MyNum` with associated type name `Output`...
 --> /home/matthias/vcs/github/rust_misc_stuff/tests/ui/traits/inheritance/auxiliary/icemaker_omni/BE190CEE104A225CD4B33CFB5FA41C069766D54BE3319CDCF10B5BCBEC24AD11.rs:4:1
  |
4 | pub trait MyNum : Add<Output=Self> + MyNum<Output=Self> + Mul<Output=Self> + PartialEq + Clone {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: ...which again requires looking up late bound vars, completing the cycle
note: cycle used when computing the super predicates of `MyNum`
 --> /home/matthias/vcs/github/rust_misc_stuff/tests/ui/traits/inheritance/auxiliary/icemaker_omni/BE190CEE104A225CD4B33CFB5FA41C069766D54BE3319CDCF10B5BCBEC24AD11.rs:4:1
  |
4 | pub trait MyNum : Add<Output=Self> + MyNum<Output=Self> + Mul<Output=Self> + PartialEq + Clone {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information

error: aborting due to 3 previous errors
```
Repository: electron
Issue: [Feature Request]: Add getNativeWindowHandle() to BrowserView/WebContentsView
Labels: enhancement :sparkles:

### 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 feature request that matches the one I want to file, without success.

### Problem Description

My application creates several child `BrowserWindow` whose windows need to be accessed by `HWND`. I would like to switch all this to using a new `WebContentsView`, but it is quite inconvenient to search for a concrete child window without a `getNativeWindowHandle` method 

### Proposed Solution

Add the `getNativeWindowHandle` method to `WebContentsView` similar to `BrowserWindow`. As far as I can see `*View` are implemented as child windows and they have their own separate window handle.

### Alternatives Considered

-

### Additional Information

_No response_
Repository: godot
Issue: TileMap Physics layer won't disable when process set to disable while every other physics object will
Labels: bug,topic:physics,topic:2d

### Tested versions

v4.2.1.stable.flathub [b09f793f5]

### System information

Godot v4.2.1.stable (b09f793f5) - Freedesktop SDK 23.08 (Flatpak runtime) - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3070 Ti (nvidia) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

If we put a RayCast2D and make it intersect with any disabled CollisionObject2D, it won't detect it;
However, a disabled TileMap WILL be detected by Area2d and RayCast2d.


### Steps to reproduce

1.Set up any CollisionObject2D inherited class except PhysicalBone2D, give them CollisionShape2D to make them functional
2.Also create a TileMap with Physics layer property
3.Create RayCast2D or Area2D, print raycast.get_collider() or area.get_overlapping_bodies()/get_overlapping_areas() to check if all of the above are detected
4.Set everything except detector's process mode to disable
5.Print again, you should see TileMap is still there while every other stuffs are undetectable 

### Minimal reproduction project (MRP)

[ScriptTest.zip](https://github.com/godotengine/godot/files/13772349/ScriptTest.zip)
1.Press "Detect" and see how much it detect
2.Press "Set Disable" to disable everything aside detector
3.Press "Detect" again to see how the TileMap stands bravely
(Note: I originally had another "Set Enable" button, but somehow only CharacterBody agrees to turn back on, might be another issue but I'm not bothering)
Repository: go
Issue: proposal: cmd/go: structured deprecated block in go.mod
Labels: Proposal,GoCommand,modules

### Proposal Details

## Abstract

This proposal introduces a `deprecated {}` block within the `go.mod` file of Go modules. Its goal is to provide a structured, automated, and backward-compatible way for module maintainers to communicate package deprecations, including details like the last usable version, the reason for deprecation, and an optional new import path for continued development.

## Rationale

The current Go module system offers deprecation notices through comments (`// Deprecated: ...`) and the `retract {}` section in `go.mod`. However, these approaches have limitations in terms of visibility and automation. This proposal enhances this mechanism by introducing a dedicated, structured, and easily parseable method for declaring package deprecations.


## Comparison with Current Mechanism
| Approach  | Description | Pros | Cons |
|---|---|---|---|
| **Current** (`// Deprecated: ...`, `retract {}`) | Manual deprecation notices in comments or `go.mod`. | Simple to implement. | Limited visibility and automation; lacks a standard format. |
| **Proposed** (`deprecated {}`) | Structured block in `go.mod` for deprecation details. | Standardized, machine-readable format; enables automated handling of deprecated packages; detailed deprecation info and migration paths. | - |

## Proposed Syntax Enhancements
The `deprecated {}` block in `go.mod` could allow both detailed and shorthand declarations:

### Table of Fields

| Field| Required/Optional | Description  |
|---|---|---
| `version` | Required | The last usable version of the package or versions since package has been deprecated. |
| `message` | Optional | Explanation of why the package is deprecated. |
| `newpath` | Optional | New import path if package development has moved. |

### Shorthand Declaration Example

```go
module github.com/example/mypackage

go 1.23

require (
    other/package v1.0.0
)

deprecated "v1.5.2" // Last usable version
```

### Detailed Declaration Example
```go
module github.com/example/mypackage

go 1.23

require (
    other/package v1.0.0
)

deprecated {
    version "v1.5.2"
    message "Package deprecated due to XYZ reasons. Please migrate to the new version."
    newpath "github.com/newowner/newpackage"
}
```

## Impact on Tooling

This feature can be integrated into tools like `go get` and `go list`, providing warnings or recommendations when using deprecated packages. IDE integrations could also leverage this feature to alert developers during coding.

## Addressing Potential Concerns

- **Backward Compatibility**: The `deprecated {}` block should be backward compatible, ignored by older Go versions.
- **Future Extensions**: This feature could pave the way for more automated deprecation handling and better integration with dependency management tools.