sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [google_sign_in] Android documentation is wrong
Labels: d: api docs,p: google_sign_in,package,team-ecosystem,P2,triaged-ecosystem

I'm trying to use Google Sign In and it works fine on iOS but on Android the documentation is weird/not clear.

For example I'm trying to init the library like this:
```
final googleUser = await GoogleSignIn(
  serverClientId: 'your_server_client_id',
  clientId: 'your_client_id'
).signIn();
```

However, in the documentation it says this in regards to the `clientId` param ([source](https://github.com/flutter/plugins/blob/main/packages/google_sign_in/google_sign_in/lib/google_sign_in.dart#L235)):
> This option is not supported on all platforms (e.g. Android)

And it says this in regards to `serverClientId` param (source):
> Optional and not supported on all platforms (e.g. web)

Which implies that `serverClientId` is working on Android.

However if we look at the implementation [here](https://github.com/flutter/plugins/blob/main/packages/google_sign_in/google_sign_in_android/lib/google_sign_in_android.dart#L27), the `serverClientId` is actually not used and not only that but `clientId` param is [used](https://github.com/flutter/plugins/blob/main/packages/google_sign_in/google_sign_in_android/android/src/main/java/io/flutter/plugins/googlesignin/GoogleSignInPlugin.java#L141) even if the documentation says it is not supported on Android.
Repository: axios
Issue: UNABLE_TO_VERIFY_LEAF_SIGNATURE just to some requests to same server
Labels: state::triage

#### Describe the issue
Axios is throwing `UNABLE_TO_VERIFY_LEAF_SIGNATURE` just for some requests to the same server using `rejectUnauthorized: false`

#### Example Code
I have a method `sendRequest` as follows:

```ts
import axios, { AxiosRequestConfig } from 'axios'
import https from 'https'

  private async sendRequest(
    method: 'post' | 'get' | 'put' | 'delete' | 'patch',
    url: string,
    payload?: unknown,
    options?: AxiosRequestConfig
  ): Promise<any> {
    console.log(url)
    try {
      const response = await axios[method](url, payload, {
        ...options,
        httpsAgent: new https.Agent({
          rejectUnauthorized: false,
        })
      })
      return response?.data
    } catch (error: any) {
      console.error(error)
    }
  }
```

I'm using that method to send requests to an [Apache Guacamole](https://guacamole.apache.org/) API that is being served with `https` (port 443) using a Kaspersky Anti-Virus Personal Root Certificate.

Firstly, implemented a request to get a token (`POST /api/token`) and got SSL errors, so then added the `https.Agent` with `rejectUnauthorized: false` and workarounded that issue.

However, now I implemented another request to invalidate that token (`DELETE /api/token/:token`) and I'm getting this error even with the `rejectUnauthorized: false`:

```
AxiosError: unable to verify the first certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1532:34)
    at TLSSocket.emit (node:events:527:28)
    at TLSSocket.emit (node:domain:475:12)
    at TLSSocket._finishInit (node:_tls_wrap:946:8)
    at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:727:12)

// console.error
{
  code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE',
  // ...
}
```

Both requests are made to the same server, so I don't understand why the first success and the second don't. There is not a proxy nor anything strange that could redirect the request between my code and the Guacamole server.

Launching my code with `NODE_TLS_REJECT_UNAUTHORIZED=0` env variable seems to fix the issue, but disables TLS everywhere, which is not desired.

#### Expected behavior, if applicable
To the request to happen without TLS errors, due to the `rejectUnauthorized: false`

#### Environment
 - Axios Version: 0.27.2
 - Adapter: `https` is version 1.0.0
 - Browser: does not apply.
 - Browser Version: does not apply:
 - Node.js Version: 16.15.1
 - OS: Ubuntu 20.04.4 LTS
 - Additional Library Version: does not apply

#### Additional context/Screenshots
Launching my code with `NODE_TLS_REJECT_UNAUTHORIZED=0` env variable seems to fix the issue, but disables TLS everywhere, which is not desired.
Repository: neovim
Issue: `nvim_get_mode` waits 3~4 secs with 'showmode' enabled or when there are error messages
Labels: bug,channels-rpc,has:workaround,event-loop

### Neovim version (nvim -v)

v0.8.0-dev+604-gd8360e903

### Vim (not Nvim) behaves the same?

I did not check since vim does not have `pynvim`

### Operating system/version

macOS 12.4

### Terminal name/version

Terminal.app

### $TERM environment variable

xterm-256color

### Installation

build from repo

### How to reproduce the issue

I am running the following Python script (pynvim) to feed Neovim with three inputs (`i<C-o><C-g>`) and query the mode after each input. The script reports the times for each input. 
```python

import pynvim
from time import perf_counter as pc

n = pynvim.attach(
    "child", argv=['./nvim', '--clean', '--embed', '--headless', 'filename'])

print("Starting the sequence")

before = pc()
n.feedkeys(n.replace_termcodes("i"), 't')
assert (n.api.get_mode() == dict(
    {'mode': 'i', 'blocking': False})), "not in Insert mode or is blocked!"
after = pc()
print("i:", after - before)

before = pc()
n.feedkeys(n.replace_termcodes("<C-o>"), 't')
assert (n.api.get_mode() == dict(
    {'mode': 'niI', 'blocking': False})), "not in Insert Normal mode or is blocked!"
after = pc()
print("CTRL-O:", after - before)

before = pc()
n.feedkeys(n.replace_termcodes("<C-g>"), 't')
assert (n.api.get_mode() == dict(
    {'mode': 'i', 'blocking': False})), "not in Insert mode or is blocked!"
after = pc()
print("CTRL-G:", after - before)

print("End Of Sequence")
n.close()
```

### Expected behavior

The documentation says `nvim_get_mode()` is supposed to be served immediately.
```
Non-deferred ({fast}) functions such as |nvim_get_mode()| and
|nvim_input()| are served immediately (i.e. without waiting in the input
queue).
```



### Actual behavior

Yet I get the following output from the above script:
```
python3 -u trace.py
Starting the sequence
i: 1.0152065000000001
CTRL-O: 0.0016440410000000405
CTRL-G: 3.005534583
End Of Sequence
```
So `<C-G>` is much slower than the other two inputs which seems to go against what is stated in the documentation.
Repository: node
Issue: How could we support typescript without vendoring it?
Labels: discuss

I would like Node.js to support the following user experience

```bash
$ node script.ts
Typescript support is missing, install it with:
npm i --location=global typescript-node-core
$ npm i --location=global typescript-node-core
...
$ node script.ts
"Hello World"
```

(I picked the typescript-node-core name at random, I would be extremely happy if that could be ts-node)

Note that `script.ts` could evaluate to either cjs or mjs depending on the `tsconfig.json` file.

_Originally posted by @mcollina in https://github.com/nodejs/node/issues/43408#issuecomment-1182883689_

---

__Why vendoring is not an option?__

1. TypeScript changes too fast and they do not follow semantic versioning, nor do they provide any long-term support.
2. We will never be able to pick a default `tsconfig` given the 100+ options.
Repository: go
Issue: x/build/cmd/buildlet: Reverse Dial Fails in Local devMode 
Labels: Builders,NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go1.19
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>
`linux/amd64`
### What did you do?
Followed instructions at https://github.com/golang/build/tree/master/cmd/coordinator
1. ran `go run . -mode=dev -listen-http=localhost:8119`
2. followed by `go run golang.org/x/build/cmd/buildlet -halt=false -reverse-type=host-linux-amd64-localdev`

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->



### What did you expect to see?

Messages confirming reverse mode connection between coordinator and buildlet such as:
```
Registering reverse mode with coordinator...
Connected to coordinator; reverse dialing active
```

### What did you see instead?

`Error dialing coordinator: failed to handshake with coordinator: tls: first record does not look like a TLS handshake`
Repository: rust
Issue: fn where clause "constrains trait impls" or something
Labels: T-compiler,A-SIMD,C-bug,PG-portable-simd

the code below should be pretty self-explanatory.
anyway, here's the run down:
- make a trait to extend the simd types (this should happen for any equivalently defined types, though i haven't tested that).
- implement the trait for all f32 simd types.
- define a generic function with the same trait bound as the extension trait.
- the trait impl is now constrained to the function's generic parameter.
- profit.

I tried this code:

```rust
#![feature(portable_simd)]

use core::simd::*;

trait SimdExt<const N: usize> where LaneCount<N>: SupportedLaneCount {
    fn id(self) -> Self;
}

impl<const N: usize> SimdExt<N> for Simd<f32, N> where LaneCount<N>: SupportedLaneCount {
    fn id(self) -> Self { self }
}


// these are all the same.
// just adding the where clause breaks it.

fn fine() {
    let foo: f32x2 = f32x2::splat(0.0).id();
}

fn also_fine<const N: usize>() {
    let foo: f32x2 = f32x2::splat(0.0).id();
}

// this one doesn't compile
fn oops<const N: usize>() where LaneCount<N>: SupportedLaneCount {
    // the trait `SimdExt<N>` is not implemented for `std::simd::Simd<f32, 2_usize>`
    let foo: f32x2 = f32x2::splat(0.0).id();
}

// this function demonstrates the "constrains" part (it compiles just fine).
fn fine_again<const N: usize>() where LaneCount<N>: SupportedLaneCount {
    let foo: Simd<f32, N> = <Simd<f32, N>>::splat(0.0).id();
}
```

I expected to see this happen: it compiles.

Instead, this happened: it doesn't compile.

### Meta

`rustc --version --verbose`:
```
rustc 1.64.0-nightly (1c7b36d4d 2022-07-12)
binary: rustc
commit-hash: 1c7b36d4db582cb47513a6c7176baaec1c3346ab
commit-date: 2022-07-12
host: x86_64-pc-windows-msvc
release: 1.64.0-nightly
LLVM version: 14.0.6
```
(i encountered this initially on 1.63.0 nightly, then upgraded hoping that it has been fixed in the latest version, which it wasn't)
Repository: electron
Issue: [Bug]: MessagePort to MessagePortMain cannot transfer transferable resources
Labels: enhancement :sparkles:,platform/all,has-repro-gist,18-x-y,19-x-y,20-x-y

### Preflight Checklist

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

### Electron Version

18, 19, 20

### What operating system are you using?

Windows

### Operating System Version

Windows 10 Enterprise 21H2 (19044.1766)

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

As per documentation (https://www.electronjs.org/docs/latest/tutorial/message-ports) MessagePortMain should behave like the original MessagePort available in the renderer process, except for how the events are handled.

It's expected that a transferable object would be correctly passed to the main process when transferred from the renderer process without the need of serialization and deserialization of the object.



### Actual Behavior

When transfering a transferable object, such as a buffer array, from the Renderer to Main process the entire message data is lost. Transferable object ownership is correctly lost in the renderer.

### Testcase Gist URL

https://gist.github.com/a76896c0052ac3311fbe66436befefd0

### Additional Information

The issue is easy to replicate (see the linked gist). 

When the port is forwarded to another renderer process the transferable data is handled correctly, the issue is only from Renderer to Main

Looking at MessagePortMain's postMessage interface I can see that only MessagePortMain are accepted as transferables, but I can't find anywhere that says that it shouldn't be possible to transfer transferables fro Renderer's postMessage API to MessagePortMain message event
Repository: godot
Issue: Button.pressed abnormal
Labels: enhancement,documentation,topic:gui

### Godot version

4.0A11

### System information

Windows10 21H2 or 20H2

### Issue description

```gdscript
func _on_Button_gui_input(event):
	if $Button.pressed:
		if event is InputEventScreenDrag:
			Vector += event.relative
			Direct  = event.relative
			if Origin.distance_to(Vector) > 150:
				Vector = ((Vector - Origin).normalized()*150) + Origin
	else:
		Vector = Origin
		Direct = Vector2()
```

When "$Button.pressed" is false, there is no effect

### Steps to reproduce

When "$Button.pressed" is false, there is no effect

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: Implement shape/size functions for nestedtensor
Labels: triaged,module: nestedtensor

### 🚀 The feature, motivation and pitch

Currently, nt.shape does not work. It just throws an error:

```
>>> import torch
>>> x = torch.nested_tensor([torch.rand(2), torch.rand(3)])
<stdin>:1: UserWarning: The PyTorch API of nested tensors is in prototype stage and will change in the near future. (Triggered internally at /Users/runner/work/pytorch/pytorch/pytorch/aten/src/ATen/NestedTensorImpl.cpp:99.)
>>> x.shape
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: Internal error: NestedTensorImpl doesn't support sizes. Please file an issue on https://github.com/pytorch/nestedtensor
```

The shape function has been implemented, as seen [in this colab](https://colab.research.google.com/github/pytorch/nestedtensor/blob/master/tutorials/notebooks/basic.ipynb#scrollTo=STGxLWXXVg5Z), it just hasn't been migrated to torch.

I do not see any downside to implementing this function, as it is easy it implement (the code is already written; it just needs to be migrated), and it's much better than throwing an error.



### Alternatives

_No response_

### Additional context

My use case:
I am working with graph neural networks, which involve a variable number of agents, each of which can observe a variable number of objects in the environment. if fully functional, nestedtensor would significantly simply the problem, as it would obviate the need to store and manipulate tensors of batch indices.

cc @cpuhrsch
Repository: godot
Issue: [Bullet] RigidBody bounces when sliding along HeightMapShape's internal edges
Labels: bug,topic:physics,topic:3d

### Godot version

v3.5.rc.custom_build (3f0201335)

### System information

Windows 10

### Issue description

As described in another simillar issue: #21341 there's a issue with bullet physics that rigidbodies bounces off or bumps into a mesh-based collider internal edges. This can be solved for ConcavePolygonShape by turning on `physics/3d/smooth_trimesh_collision` project setting, which will call `btGenerateInternalEdgeInfo` internally when generating the mesh shape.

But for HeightMapShape, this same issue happens when toggling this setting, because there isn't any call to `btGenerateInternalEdgeInfo` when generating the HeightMapShape.

I've tested with the official build, and created a custom build adding these lines for `modules/bullet/shape_bullet.cpp@ShapeBullet::create_shape_height_field`:

```cpp
if (GLOBAL_GET("physics/3d/smooth_trimesh_collision")) {
	btTriangleInfoMap *triangleInfoMap = new btTriangleInfoMap();
	btGenerateInternalEdgeInfo(heightfield, triangleInfoMap);
}
```

This is the result without using the custom build:

https://user-images.githubusercontent.com/43936806/178769858-103d0418-985d-4ca9-bc44-effa9f6a2bee.mp4

This is the result using the custom build and toggling on `physics/3d/smooth_trimesh_collision`:

https://user-images.githubusercontent.com/43936806/178770066-ef4f67a0-2d3d-43c5-bdfa-875f0f20e9b0.mp4

As a side note, I've scaled the HeightMapShape collision shape by Vector3(4, 1, 4).

### Steps to reproduce

1. Create a simple StaticBody with a flat HeightMapShape collider, with a arbitrary width/height with all the heights values at zero;
2. Create a simple RigidBody with a box collider, put it above the StaticBody;
3. Set friction to zero and initial linear velocity to slide along the StaticBody;
4. Toggle on and off `physics/3d/smooth_trimesh_collision` setting and compare the results by playing the scene;
5. Make the same test adding `btGenerateInternalEdgeInfo` function call when creating the HeightMapShape in the engine's source code.

### Minimal reproduction project

[Collision Issue.zip](https://github.com/godotengine/godot/files/9103551/Collision.Issue.zip)
Repository: opencv
Issue: cv::filter2D kernel documentation is different from actual behaviour
Labels: bug,category: documentation

##### System information (version)
- OpenCV => 4.5.5
- Operating System / Platform => Ubuntu 64bit
- Compiler => clang 14.0.6

##### Detailed description

Current documentation on `cv::filter2D` says that kernel should be of floating point type, but in reality it supports any type supported by `cv::Mat`. So either supported types in documentation should be expanded, or exception should be thrown in case of non floating point types.

##### Steps to reproduce
This works even though `kernel` type is `CV_8S`:
```cpp
auto input = ::cv::Mat(5, 5, CV_32F, 2);
auto kernel = ::cv::Mat(3, 3, CV_8S, 1);
auto output = ::cv::Mat(5, 5, CV_32F, 2);
::cv::filter2D(input, output, output.depth(), kernel);
```
Repository: next.js
Issue: [NEXT-780] The same library is imported as both ESM and CommonJS module
Labels: bug,linear: next

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 21.4.0: Fri Mar 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64
    Binaries:
      Node: 16.15.1
      npm: 8.11.0
      Yarn: 1.22.10
      pnpm: 7.5.0
    Relevant packages:
      next: 12.2.3-canary.5
      eslint-config-next: 12.2.2
      react: 18.2.0
      react-dom: 18.2.0

warn  - Latest canary version not detected, detected: "12.2.3-canary.5", newest: "12.2.3-canary.4".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

My application depends on a libraries `a` and `b`, library `a` also internally depends on the library `b` (same version).

The bundle ends up having two distinct versions of `b`: ESM and CommonJS. This unnecessarily increases bundle size and prevents things like `instanceof` from working.

Both `a` and `b` provide `require` and `import` versions of the export in package.json. This shouldn't matter, however. There should be no way for the same version of the same library to result in duplication in the bundle.

### Expected Behavior

`b` is imported either as ESM or CommonJS but not both.

### Link to reproduction

https://codesandbox.io/s/confident-joliot-m05z3c

### To Reproduce

The codesandbox provides a real-world example that led me to discovering this bug.
The libraries in question are `html-react-parser` which depends on `domhandler`. `html-react-parser` imports CommonJS version of `domhandler`. Importing `domhandler` directly brings in the ESM version.

In the browser console, follow `[[FunctionLocation]]` of both versions of `Element`. They are originating from two distinct locations

```
webpack://_N_E/node_modules/.pnpm/domhandler@5.0.3/node_modules/domhandler/lib/node.js?4da4
webpack://_N_E/node_modules/.pnpm/domhandler@5.0.3/node_modules/domhandler/lib/esm/node.js?b3fb
```

Note that both packages define both `module` and `exports.import` inside `package.json`. Removing `exports` section from `domhandler` makes Next.js load it as an ESM module.

<sub>[NEXT-780](https://linear.app/vercel/issue/NEXT-780/the-same-library-is-imported-as-both-esm-and-commonjs-module)</sub>
Repository: neovim
Issue: defaults, part 3
Labels: enhancement,defaults,needs:discussion

previous: #6289 

### Feature description

A few more proposals for defaults:

- [ ] 'shada' oldfiles exclude https://github.com/neovim/neovim/issues/21637
- [ ] change eob fillchar to middle-dot instead of tilde "~" https://github.com/neovim/neovim/issues/21694
- [X] `nnoremap & <Cmd>&&<CR>`
  - **Rationale**: The `&` key repeats the last `:s` command, but does not re-use the flags of the last command. Meaning if you last ran `:s/foo/bar/g` to replace all instances of `foo` in a line with `bar`, then move your cursor to a different line and press `&`, it will still only replace the first instance of `foo` with `bar`. The `:&&` ex command *does* re-use the flags, but is relatively more cumbersome (four key presses rather than one). The latter is much more useful and a more common operation. To regain the original behavior, users can still use the `:&` ex command.
  - **Status**: Done #19365 
- 🚫 ~~Swap `p` and `P` in visual mode (`xnoremap p P | xnoremap P p`)~~
  - **Rationale**: The fact that "pasting" in visual mode clobbers the yanked contents is a common footgun in Vim. The `P` key was added to avoid this: it preserves the contents of the unnamed register so that you can use `P` repeatedly to "paste" the same contents. This behavior is more intuitive and commonplace in other editing environments, so let's make it the default for `p`. If a user wants the original behavior, they can use `P` (or unmap the defaults).
  - **Status**: There are a number of good arguments against this; see [here](https://github.com/neovim/neovim/issues/19354#issuecomment-1184425231) and [here](https://github.com/neovim/neovim/issues/19354#issuecomment-1188301778).
- [ ] Map `gs` to `:sort`
  - **Rationale**: The default `gs` mapping is so utterly useless it almost seems like a joke. Instead, make `gs` an operator in normal mode that sorts the given range (in visual mode, make it sort the selection). I currently use this:
  ```vim
  function! Sort(...) abort
    '[,']sort
    call setpos('.', getpos("''"))
  endfunction
  nnoremap gs m'<Cmd>set operatorfunc=Sort<CR>g@
  xnoremap gs :sort<CR>
  ```
  - **Status**: Make `gs` some kind of "substitute" operator for consistency with the default `s` mapping. Example: `xnoremap gs mr:s/\%V` (and an equivalent operator in normal mode)
- [ ] 'title' and 'titlestring' ? https://github.com/neovim/neovim/issues/1248
- [x] `shortmess+=C` #23907
- [ ] `smoothscroll` #23939
- [x] `termguicolors` #26407