sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: runtime: mexit leads to SIGSEGV due to g.m becoming nil
Labels: NeedsInvestigation,compiler/runtime

Issue is reproducible on openbsd/amd64 with both go1.17.7 and -tip.

While debugging test failures (for another software package - delve), the `go test` run will regularly hit a `SIGSEGV` like the following:

```
Thread 5 received signal SIGSEGV, Segmentation fault.
[Switching to thread 129486]
0x00000000007a6f2e in runtime.lock2 (l=0xec5e98 <runtime.sched+24>) at /usr/local/go/src/runtime/lock_sema.go:42
42              if gp.m.locks < 0 {
(gdb) bt
#0  0x00000000007a6f2e in runtime.lock2 (l=0xec5e98 <runtime.sched+24>) at /usr/local/go/src/runtime/lock_sema.go:42
#1  0x00000000007dac0d in runtime.lockWithRank (l=<optimized out>, rank=<optimized out>) at /usr/local/go/src/runtime/lockrank_off.go:23
#2  runtime.lock (l=<optimized out>) at /usr/local/go/src/runtime/lock_sema.go:37
#3  runtime.mexit (osStack=true) at /usr/local/go/src/runtime/proc.go:1532
#4  0x00000000007da86f in runtime.mstart0 () at /usr/local/go/src/runtime/proc.go:1372
#5  0x000000000080b425 in runtime.mstart () at /usr/local/go/src/runtime/asm_amd64.s:248
#6  0x0000000000e420f4 in crosscall_amd64 () at gcc_amd64.S:40
#7  0x000000000080b420 in ?? ()
#8  0x000000c0000011e0 in ?? ()
#9  0x00007f7ffffc7b68 in ?? ()
#10 0x0000000000e41ff0 in ?? () at gcc_openbsd_amd64.c:51
#11 0x0000000297c8ee70 in ?? ()
#12 0x000000027d9ca8a8 in ?? ()
#13 0x0000000000e42024 in threadentry (v=<optimized out>) at gcc_openbsd_amd64.c:63
```

This is occurring due to `gp.m` becoming `nil` during the following in `mexit` (it is non-nil before this line and is nil immediately afterwards):

```go
        // Release the P.
        handoffp(releasep())
```

The next piece of code is:

```go
        lock(&sched.lock)
```

And this leads to a `gp.m.locks` dereference and hence a `SIGSEGV`.

This seems to be triggered by the fact that these tests run code that calls `runtime.LockOSThread` - adding a matching `runtime.UnlockOSThread` call makes the issue disappear, as does removing the `runtime.LockOSThread` call. Additionally, the `openbsd/amd64` port uses system threads, which may play a part.

So far I've been unsuccessful in reducing the test suite to provide a minimal reproducer. However, it is easy to trigger and I can provide further information as needed.
Repository: godot
Issue: The collision is not registered.
Labels: topic:physics,needs testing,topic:2d

### Godot version

v3.5.beta4.official [b6968ab06]
3.4.4
3.1

### System information

win10 64

### Issue description

A KinematicBody2D surrounded by walls (tilemap node) will not record any other collisions.

The question is:
Why doesn't the player node register enemy collision when the player node is between walls?.

A video showing the problem:
https://youtu.be/7BkblG0We4Q

The collision is also not registered if the player is moved to the wall:
![Captura](https://user-images.githubusercontent.com/19652075/163726118-1229aef1-f5d4-4f07-966c-7f84b0aa5858.PNG)

![Captura2](https://user-images.githubusercontent.com/19652075/163726122-56cc4bf2-de0b-4aa0-a93c-703b3f3f5d80.PNG)

### Steps to reproduce

Only execute the test project uploaded

### Minimal reproduction project

[test.zip](https://github.com/godotengine/godot/files/8502230/test.zip)
Repository: deno
Issue: Interest in Adding Support for "navigator.sendBeacon"?
Labels: web,suggestion

I was following up on trying to use OpenTelemetry-JS in Deno (after my earlier efforts [here](https://github.com/open-telemetry/opentelemetry-js/issues/2293#issuecomment-1030750431)) this time trying to export trace data out of Deno and to an OTEL collector.

The main issue I ran into this time was that the [browser version of the exporter](https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/exporter-trace-otlp-http/src/platform/browser/OTLPExporterBrowserBase.ts#L80) relies on either navigator.sendBeacon or XmlHttpRequest to do the exporting, neither of which are currently available in Deno.

I was able to put together this [small userland polyfill](https://deno.land/x/sendbeacon_polyfill@0.0.1) of navigator.sendBeacon based on [this comment from MDN](https://developer.mozilla.org/en-US/docs/Web/API/fetch#keepalive) about the "keepalive" option for fetch, which seemed to do the trick as far as my OTEL-JS experiment goes. However I'm not sure if its description there as a "drop-in replacement for navigator.sendBeacon" also applies in Deno.

I remember seeing elsewhere XmlHttpRequest won't be supported in core, but I was curious if the same would apply to navigator.sendBeacon? I'm not quite sure what the direction is around navigator APIs, as I see there seem to only be 2 supported at the moment (?) so I figured it couldn't hurt to ask.
Repository: godot
Issue: Flickering Panel when using popup with mouse_entered and mouse_exited
Labels: bug,confirmed,topic:gui

### Godot version

3.4.2 stable

### System information

Windows 10

### Issue description

Popup panel was flickering when i used it as a details panel for my game. Basically when popup() is called in Mouse entered of a control, lets say a button and we have the popup set to invisible when the mouse exits the button, we get flickering of the popup panel as well as calls to mouse_entered and mouse_exited signals whenever the mouse is moved

https://user-images.githubusercontent.com/81511084/163729969-b7639a9a-c902-4af0-b022-194cd59ff705.mp4

.

### Steps to reproduce

It's quite simple to reproduce

![image](https://user-images.githubusercontent.com/81511084/163730005-38200733-f6f2-40c8-bdcf-ac10bba5655e.png)

then just play the scene and enjoy the flickers :)

### Minimal reproduction project

[flicker_issue.zip](https://github.com/godotengine/godot/files/8502364/flicker_issue.zip)
Repository: rust
Issue: Type inference with generics sometimes does not work with type annotation on the variable
Labels: A-trait-system,A-inference,C-bug,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

Here is an example code to illustrate the issue

```rust
fn foo<T: std::str::FromStr>(s: &str) -> T {
    s.parse().ok().unwrap()
}

fn add_other<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
    a + b
}

fn main() {
    // This one works fine, as expected
    let a: u32 = foo("42");
    // This line works although it seems to be a similar situation to d below, type inference-wise:
    let b: u32 = add_other(foo("42"), 1);
    
    // This one obviously can't work as rust can't guess which type we'd want here (i32 or u32 or usize or whatever?)
    //let c = foo("42") + 1;
    // All of these don't work, even with type annotation(s) added
    let d: u32 = foo("42") + 1;
    let e: u32 = foo("42") + 1u32;
    let f: u32 = foo("42").add(1u32);
    
    // This one does work:
    let g: u32 = foo("42");
    let g = g + 1;
    
    // This one works fine, since the type annotation is on the generic rather than on the variable itself
    let h = foo::<u32>("42") + 1;
}
```

In this example, I expected type inference to work for d, e and f, but it does not work, although b seems to be in a similar situation and works fine currently. The variable's type is specified, but rust does not manage to infer the `foo()` call when using one of its type's method, either through `foo().bar()` or an operator (syntaxic sugar).

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-unknown-linux-gnu
release: 1.60.0
LLVM version: 14.0.0
```

Backtrace not relevant.

I saw some other type inference issues in the issue tracker, but none seemed quite like this one. If it's obviously a duplicate, feel free to close this issue.
Repository: neovim
Issue: vim.region errors on block regtype
Labels: bug,lua

### Neovim version (nvim -v)

NVIM v0.7.0

### Vim (not Nvim) behaves the same?

No

### Operating system/version

Windows 10 20H2 19044.1645

### Terminal name/version

Windows Terminal 1.12.10732.0

### $TERM environment variable

empty

### Installation

chocolatey

### How to reproduce the issue

```
nvim --clean
```

Edit so buffer contains two lines: "abc" and "def"

```
:lua vim.region(0, {0, 0}, {1, 1}, '^V', true)
```

Note the '^V' is the actual ctrl-v character, not the two characters '^' and 'V'.

### Expected behavior

The function succeeds

### Actual behavior

The function fails with the error below:

```
E5108: Error executing lua vim/_editor.lua:347: attempt to perform arithmetic on a string value
stack traceback:
        vim/_editor.lua:347: in function 'region'
        [string ":lua"]:1: in main chunk
```

This seems to come from the line `c2 = c1 + regtype:sub(2)` in `vim.region`. It apparently expects a number to come after the '^V'. This seems to be allowed by `:h setreg()`, but here there are a couple problems:

1. The number isn't treated as optional.
2. The string isn't converted to a number before adding it to `c1`.

This seems similar to #17140, which was closed as external.
Repository: rust
Issue: doc(cfg) doesn't work on glob reexports
Labels: T-rustdoc,C-bug,requires-nightly,A-rustdoc-ui,F-doc_cfg

I tried this code:

```rust
#![feature(doc_auto_cfg, doc_cfg)]

#[doc(inline)]
#[cfg(feature = "raw")]
pub use crate::raw::*;
```

I expected to see this happen:

![image](https://user-images.githubusercontent.com/5992217/163751408-d51f634d-81e2-45ed-a5bc-a030b322f141.png)

The doc_cfg note would appear on the reexported items.

Instead, this happened:

The doc_cfg note does not appear on glob reexported items. If items are reexported individually, the doc_cfg note does apply.

(My actual case has a `#[cfg(feature = "raw")` on a containing module, and then `#[cfg(feature = "lib")]` on the glob reexport. The cfg note for `raw` always appears, but "and **lib**" only appears for explicitly named items.)

### Meta

`rustc -Vv && rustdoc -Vv`:
```
rustc 1.62.0-nightly (e7575f967 2022-04-14)
binary: rustc
commit-hash: e7575f9670f3c837def3d186ae09366c75c7632e
commit-date: 2022-04-14
host: x86_64-pc-windows-msvc
release: 1.62.0-nightly
LLVM version: 14.0.0

rustdoc 1.62.0-nightly (e7575f967 2022-04-14)
binary: rustdoc
commit-hash: e7575f9670f3c837def3d186ae09366c75c7632e
commit-date: 2022-04-14
host: x86_64-pc-windows-msvc
release: 1.62.0-nightly
LLVM version: 14.0.0
```

@rustbot modify labels: +A-rustdoc-ui +requires-nightly
(I think?)
Repository: opencv
Issue: Enable filesystem in OpenCV.js
Labels: feature,RFC

### Description

Filesystem support in OpenCV.js is currently disabled.

https://github.com/opencv/opencv/blob/17234f82d025e3bbfbf611089637e5aa2038e7b8/modules/core/include/opencv2/core/utils/filesystem.private.hpp#L9-L11

Since Emscripten [supports file system operations through a virtual browser file system](https://emscripten.org/docs/porting/files/file_systems_overview.html), it would be great to enable a file system for OpenCV.js.

For a reference, in [Pyodide](https://github.com/pyodide/pyodide) (Python distribution for the browser based on WebAssembly), I was able to [build File System enabled OpenCV](https://github.com/pyodide/pyodide/pull/2305) with [some minor modifications](https://github.com/pyodide/pyodide/blob/5e874a87f38fac4e4875162a081968ffdb003a77/packages/opencv-python/patches/0001-Enable-file-system.patch).
Repository: opencv
Issue: Add haveImageReader(const Mat& buf) to imgcodecs and expose it in python
Labels: feature,RFC

I would like to propose exposing the buffer variant of `findDecoder` ([here](https://github.com/opencv/opencv/blob/217fea96676f415762a5e6e46177162b4f95f0bc/modules/imgcodecs/src/loadsave.cpp#L260)) in the python API in the same way that the filename version of it is already exposed, i.e., by overloading `haveImageReader`.

The overload which [accepts filenames](https://github.com/opencv/opencv/blob/217fea96676f415762a5e6e46177162b4f95f0bc/modules/imgcodecs/src/loadsave.cpp#L1023) is nice because we can check that an image can be read before calling `imread` on it. One example where this is useful is if we have a main thread (or process) that verifies that a list of images is loadable and then delegates the actual loading and processing to worker threads (or sub-processes). 

I would like to be able to do the same for buffers, so that I can do a similar check before calling `imdecode` on encoded image data. Currently, I have to call `imdecode` on the main thread and check the result. Decoding the image in the main process isn't ideal, however. Alternatively, I could write the content of the buffer to disk and call `haveImageReader` on that file and later load in on a worker, but writing to disk and reading from it twice is costly so I would prefer not to do that.
Repository: godot
Issue: Dock icon on macOS Monterey gets duplicated every time it is manually moved
Labels: bug,platform:macos,topic:editor,topic:porting,confirmed,documentation

### Godot version

3.4.4.stable.mono

### System information

macOS Monterey 12.3.1, MacBook Pro M1 Max, GLES3

### Issue description

When I open the Godot editor and manually change the position of the dock icon, then restart the editor, I get a duplicate dock icon all the way to the right of the dock.

This happens every time I manually change the position of the dock icon.
You can see the effect in the following screenshot:
![Screen Shot 2022-04-18 at 16 07 01](https://user-images.githubusercontent.com/1736929/163770279-e3c49b54-415f-47b8-8a3c-75f112fef3bb.jpg)



### Steps to reproduce

1. Install latest version of Godot (3.4.4.stable.mono) on latest macOS Monterey (12.3.1)
2. Open the editor, start a new blank project
3. Move the Godot editor dock icon to a different place on the dock
4. Save the project somewhere, quit the editor
5. Restart the editor
6. Dock icon is now duplicated

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: jit/_trace.py", line 71, in _unique_state_dict     filtered_dict[k] = v.detach() AttributeError: 'torch.dtype' object has no attribute 'detach'
Labels: oncall: jit

### 🐛 Describe the bug

Try exporting torch.fx quantized model to onnx get this error:

```jit/_trace.py", line 71, in _unique_state_dict
    filtered_dict[k] = v.detach()
AttributeError: 'torch.dtype' object has no attribute 'detach'

```

From discussion forum, it was claimed quantized model export to onnx already supported, but I still get this error on a single res18 model from torchvision.



### Versions

torch.1.11
Repository: create-react-app
Issue: Security Vulnerability in react-scripts 5.0.0 - CVE-2021-43138
Labels: needs triage,issue: bug report

CVE-2021-43138
Update async to "async": "^3.2.3",
Repository: material-ui
Issue: [migration] Issue while upgrading to v5 from v4
Labels: support: question,v5.x migration

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

As per the documentation of MUI v5, I've upgraded to React 17 from React 16 and react scripts as well,
but once we've upgraded react scripts all the test cases are failing. 
We're using testing library and jest for testing

### Expected behavior 🤔

All test cases should pass

### Steps to reproduce 🕹

Steps:

1. Upgrade to React 17 from React 16
2. Upgrade react-scripts to latest version


### Context 🔦

We're trying to upgrade to MUI v5

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>
Repository: terminal
Issue: We don't update LPWINDOWPOS flags during `WM_WINDOWPOSCHANGED`, maybe we should?
Labels: Help Wanted,Issue-Bug,Product-Terminal,Area-CodeHealth,Priority-3,Area-Windowing

https://github.com/microsoft/terminal/blob/41ef5554f5cb946c4a48e2b8db791265c7217fce/src/cascadia/WindowsTerminal/IslandWindow.cpp#L592

Since size is changed here shouldn't we clear the SWP_NOSIZE bit in lpwpos->flags?
Repository: create-react-app
Issue: CRA ships with react-scripts version 0.9.5
Labels: needs triage

Today I created a new app using the command

`npx create-react-app <app name>`


I was trying to use scss in my react app but unfortunately even after installing sass library still scss styles were not getting applied. So I though of checking the versions on package.json and found that react-scripts 0.9.5 was shipped with CRA by default whereas the present stable version is 5.0.1 (as per npm).

![Screenshot from 2022-04-18 16-46-29](https://user-images.githubusercontent.com/50210712/163800826-b1316660-273c-4607-bd4b-326b02bdd603.png)
Repository: flutter
Issue: Proposal to Stream data to native channels
Labels: engine,c: proposal,P3,team-engine,triaged-engine

`Feature request`
Hello!
Problem I have: saving large file (500MB for example) to specific folder throws `OutOfMemoryError`.
I have service that sends `Uint8List` data to platform plugins, where this data is being saved. So, for large files it would be good, if I could stream this data to platforms. 
I've found out that `EventChannel` lacks support for streaming data from Flutter to native, only in reverse direction. Of course, I could simply use `MethodChannel` and send simple events for each byte, but I've found out that this solution is extremely slow even for file of 5MB, while sending whole `Uint8List` takes milliseconds. And also I have to manually handle beginning and finish of stream, that's not so nice.
So it would be nice to have some better way to send stream of data to native platforms
Repository: neovim
Issue: virtual text: type-over overlay text ("ghost text")
Labels: enhancement,marks

### Feature already in Vim?

No

### Feature description

I've played with `vim.api.nvim_buf_set_extmark`'s options for a while but there doesn't seem to be a way to display the virtual text behind the buffer text when new characters are inserted.

For example, starting with an empty buffer, this
```lua
local api = vim.api
local ns = api.nvim_create_namespace("foo")
api.nvim_buf_set_extmark(0, ns, 0, 0, {id=1, virt_text={{"foo", "Comment"}}, virt_text_pos="overlay", virt_text_win_col=0})
```
will display
![2022-04-18_13-22](https://user-images.githubusercontent.com/59321248/163801318-9a73b19d-cf2d-4af2-956d-6983f2c8105d.png)

if I now type `b` I just see the cursor moving one column to the right. It'd be nice to have an option to show `b` *over* the virtual text, resulting in

![2022-04-18_13-26](https://user-images.githubusercontent.com/59321248/163801760-7a4752b8-4e35-478f-8bb6-b205db72c9ef.png)
Repository: pytorch
Issue: Add build support for GCC 11.2
Labels: needs reproduction,module: build,triaged

My build from source fails with GCC 11.2, is it possible to support that? Thanks

cc @malfet @seemethere
Repository: godot
Issue: Project manager goes partially off screen on small displays
Labels: bug,topic:editor,usability

### Godot version

v3.5.beta4.official [b6968ab06]

### System information

Android 10. Oppo A15

### Issue description

The button can still be pressed but, you know it's hard and uncomfortable.
 
I hope in the next update the UI will be fixed soon.

![Screenshot_2022-04-18-19-29-05-19](https://user-images.githubusercontent.com/103937907/163808478-4b673ea4-71e2-4ad2-8bc5-32483e9ec65f.jpg)

![Screenshot_2022-04-18-19-32-51-67_218127a443514d46ba847e5e6ae6a29b](https://user-images.githubusercontent.com/103937907/163809403-94cff71d-74f6-4ffc-b867-5cdc431652a3.jpg)

> [ Ignore ] other bug : 
• When I open the project the screen is just black (That's why I can't give a preview of the project)
• I can't change the language back to English (that's why in the picture I use Indonesian)

### Steps to reproduce

Open Godot app | v3.5.beta4.official [b6968ab06] | in _Android_

### Minimal reproduction project

_No response_
Repository: godot
Issue: GLTF,*.glb Animations are distorted during import
Labels: bug,topic:import,topic:3d

### Godot version

Godot_v3.4.4-stable_win64

### System information

W10x64, GLES 3.0 Quadro K2000M/PCIe/SSE2

### Issue description

When importing a glb format model with animation, the animation does not play correctly

### Steps to reproduce

To reproduce, try adding the animation of the central model, which was not originally there, from the previously saved ones.

### Minimal reproduction project

[issue.zip](https://github.com/godotengine/godot/files/8505850/issue.zip)
Repository: rust
Issue: bootstrap: Remove the distinction between `compiler` and `compiler_for`
Labels: E-hard,E-mentor,T-bootstrap

> I am not sure whether compiler/compiler_for is a meaningful + worthwhile distinction; I think the best way to find out is probably to try to unify and see what goes wrong. I suspect the intent behind the addition was largely the typical "it seems like this one place wants something slightly different" that perhaps was more of a patchwork fix than done with long-term correctness, so it's unlikely to be super principled I expect in terms of where it's used and such.

I tried changing this and it went ... not well. Removing `compiler` altogether gives 71 build errors, and changing it to alias `compiler_for(stage, host, host)` fails a bunch of the tests, including some that look like real issues:
```
---- builder::tests::dist::dist_with_targets_and_hosts stdout ----
thread 'builder::tests::dist::dist_with_targets_and_hosts' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
 [
     Rustc {
         compiler: Compiler {
<            stage: 1,
>            stage: 2,
             host: A,
>        },
>    },
>    Rustc {
>        compiler: Compiler {
>            stage: 2,
>            host: B,
         },
     },
 ]

', src/bootstrap/builder/tests.rs:314:9
```

Looking at the call sites, they usually look like this:
```rust
            fn make_run(run: RunConfig<'_>) {
                run.builder.ensure($name {
                    compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build),
                    target: run.target,
                    extra_features: Vec::new(),
                });
            }
```
so I think the "proper" fix is to pass `run.target` into compiler_for in most of these cases; at very least, we can't assume it's always `host`.

In some cases it may not be clear what target is appropriate - feel free to ask on Zulip.

@rustbot label +A-rustbuild +E-mentor +E-medium

_Originally posted by @jyn514 in https://github.com/rust-lang/rust/pull/96000#issuecomment-1101461571_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->