sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: [Python] getOptimalNewCameraMatrix
Labels: bug,category: calib3d

### System Information

Hello, 

## Setup
- win10
- anaconda Python 3.8.16 
- opencv: 4.7.0.72


### Detailed description

If I follow the example here: https://docs.opencv.org/4.x/dc/dbb/tutorial_py_calibration.html, the code will look something like that:

```
h, w = img.shape[:2]
newcameramtx, roi = cv.getOptimalNewCameraMatrix(mtx, dist, (w,h), 1, (w,h))
dst = cv.undistort(img, mtx, dist, None, newcameramtx)
x, y, w, h = roi
dst = dst[y:y+h, x:x+w]

```
In my case, this code would compress my image along the x axis (width). 
### Solution:
i had to swap h and w.

```
h, w = img.shape[:2]
newcameramtx, roi = cv.getOptimalNewCameraMatrix(mtx, dist, (h,w), 1, (h,w))
dst = cv.undistort(img, mtx, dist, None, newcameramtx)
x, y, h, w = roi
dst = dst[y:y+h, x:x+w]
```
### c++
- https://docs.opencv.org/4.x/d9/d0c/group__calib3d.html#ga7a6c4e032c97f03ba747966e6ad862b1
- https://docs.opencv.org/4.x/d6/d50/classcv_1_1Size__.html
- This clearly indicates the order should be (w,h)

### I assume, this person, reports a similiar issue in his code: 
- https://www.programcreek.com/python/?code=ddavid%2Ffsoco%2Ffsoco-master%2Fscripts%2Fundistortion%2Fget-undistortion-maps.py#


### Steps to reproduce

## outcome of code snippet 1 (Issue)

> img.shape[:2]
> (3008, 4112)
> mtx
> [[3.56304601e+03 0.00000000e+00 2.03658996e+03]
>  [0.00000000e+00 3.56356170e+03 1.51566482e+03]
>  [0.00000000e+00 0.00000000e+00 1.00000000e+00]]
> dist
> [[-2.35104973e-01  3.78737802e-01 -2.87183413e-04 -7.50335119e-05
>   -1.28754387e+00]]
> newcameramtx
> [[1.02083179e+03 0.00000000e+00 9.75096045e+02]
>  [0.00000000e+00 1.65601965e+03 1.19057120e+03]
>  [0.00000000e+00 0.00000000e+00 1.00000000e+00]]
> newcameramtx_roi
> (392, 486, 1178, 1398)

## outcome of code snippet 2 (Solution)
> img.shape[:2]
> (3008, 4112)
> mtx
> [[3.56304601e+03 0.00000000e+00 2.03658996e+03]
>  [0.00000000e+00 3.56356170e+03 1.51566482e+03]
>  [0.00000000e+00 0.00000000e+00 1.00000000e+00]]
> dist
> [[-2.35104973e-01  3.78737802e-01 -2.87183413e-04 -7.50335119e-05
>   -1.28754387e+00]]
> newcameramtx
> [[2.99030005e+03 0.00000000e+00 2.12380702e+03]
>  [0.00000000e+00 2.96091479e+03 1.41623971e+03]
>  [0.00000000e+00 0.00000000e+00 1.00000000e+00]]
> newcameramtx_roi
> (415, 157, 2524, 3417)



### 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
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: TypeScript
Issue: Preserve properties descriptions when converting @typedef's to interfaces
Labels: Suggestion,Help Wanted,Experience Enhancement

# Suggestion

Codefix `convertTypedefToType` doesn't preserve type and property descriptions.

For example in the [test case](https://github.com/microsoft/TypeScript/blob/main/tests/cases/fourslash/codeFixConvertTypedefToType3.ts) properties `id`, `name`, and `age` have descriptions, but they are dropped when codefix is applied.

Suggest to preserve that description after converting @typedef to interface as properties descriptions like `/** description */`

## 🔍 Search Terms

Searched for typedef issues reported after [March 1st](https://github.com/microsoft/TypeScript/pull/51430/files)

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Preserve `@property` description after converting `@typedef` to interfaces (as `/** description */`)


## 📃 Motivating Example

Converting 
```
 /**
  * @typedef Foo
  * type {object}
  * @property {string} id - person's ID
  * @property name {string} // person's name
  * @property {number|undefined} age - person's age
  */
```
to 
```
interface Foo {
    /** person's ID */
    id: string;
    
    /** person's name */
    name: string;
    
    /** person's age */
    age: number | undefined;
}
```
instead of 
```
interface Foo {
    id: string;
    name: string;
    age: number | undefined;
}
```

## 💻 Use Cases

Applying suggested codefix in IDEs

```[tasklist]
### Tasks
```
Repository: neovim
Issue: Wrong position information after calling redrawstatus! and creating a floating window
Labels: bug,ui,has:workaround,floatwin

### Problem

After `redrawstatus!` is called and a floating window is created, relative to a window that's not the topleft window, the position information is not accurate immediately after.
(the problem does not occur if the floating window is created relative to the topleft window)

### Steps to reproduce

```
nvim --clean
```

Create and `:source` the following script:
```vim
split
resize 5
redrawstatus!
let buf = nvim_create_buf(v:false, v:true)
let opts = {
      \   'relative': 'win',
      \   'win': win_getid(2),
      \   'width': 30,
      \   'height': 2,
      \   'col': 50,
      \   'row': 0,
      \   'style': 'minimal'
      \ }
let win = nvim_open_win(buf, 0, opts)
echom nvim_win_get_position(win)
```

That script splits the editor into two windows, resizes the top window to have a height of 5, redraws that status line, then creates a new floating window. The reported position immediately after creating is not correct, as echo'd:
```
[12, 50]
```

The `resize 5` command is not necessary to reproduce the issue, but makes it easier to figure out the expected line that should be reported.


### Expected behavior

I expected the position information to be:
```
[6, 50]
```
which is what's shown if `echom nvim_win_get_position(win)` is ran _after_ the script.

### Neovim version (nvim -v)

v0.9.1

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Kubuntu 23.04

### Terminal name/version

Konsole 22.12.3

### $TERM environment variable

xterm-256color

### Installation

appimage
Repository: godot
Issue: Deleting a Bone2D that is referenced by a PhysicalBone2D crashes the editor
Labels: bug,topic:editor,crash,topic:2d

### Godot version

4.0.3 stable

### System information

Godot v4.1.beta1 - Windows 10.0.22621 - Vulkan (Forward+) - dedicated AMD Radeon RX 5700 XT (Advanced Micro Devices, Inc.; 31.0.14057.2005) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

Deleting a Bone2D that is associated with a PhysicalBone2D crashes the editor.
However, if you go and remove the reference to the Bone2D from the PhysicalBone2D and try to delete the Bone2D, it still crashes the editor.

Expected behavior would be that deleting the Bone2D would just reset the PhysicalBone2D to a null reference.

![Screenshot 2023-06-20 115812](https://github.com/godotengine/godot/assets/4535064/1aa80830-edd6-4b24-b68b-12c14afd7d68)


### Steps to reproduce

1. Load the attached project
2. Delete this bone
![Screenshot 2023-06-20 120605](https://github.com/godotengine/godot/assets/4535064/4a8b427b-0de8-4d3e-9acb-533b7d99afc4)
3. Godot crashes


### Minimal reproduction project

[ragdoll-tests (2).zip](https://github.com/godotengine/godot/files/11803860/ragdoll-tests.2.zip)
Repository: PowerToys
Issue: (Request) FancyZones take over default drag/drop and use mod key for normal drag/drop window
Labels: Idea-Enhancement,Product-Settings,FancyZones-Settings,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

Have an option to default using zones for all drag window operations, and then to use shift (or modifier key) to change to non-zone drag operation.

in essence reversing the drag/drop behavior for windows

### Scenario when this would be used?

All the time, i am constantly using my zones and rarely do i just want to move a window and not drop it in a whole zone.

### Supporting information

personal use experience.
Repository: vscode
Issue: Saving creates "end of file" issues
Labels: bug,editor-core

Type: <b>Bug</b>

When I use VSC to edit a .sh file, it creates "syntax error: unexpected end of file" crashes.

All I need to do is open a working .sh file in VSC, make a trivial change (add an extra space inside a comment), then save the file. Then when I run the file (with any input arguments), it says:

SHELLSCRIPT.sh: line 347: syntax error: unexpected end of file
(Where 347 is the last line of the file)

If I change the .sh file in a plain text editor, no problem. So it's something in how VSC is saving the file.

Functioning version:
[COFFEEstructpipeSETUP.sh_230612_stable.txt](https://github.com/microsoft/vscode/files/11804627/COFFEEstructpipeSETUP.sh_230612_stable.txt)
Broken version:
[COFFEEstructpipeSETUP.sh_230612_crash.txt](https://github.com/microsoft/vscode/files/11804623/COFFEEstructpipeSETUP.sh_230612_crash.txt)

VS Code version: Code 1.79.0 (Universal) (b380da4ef1ee00e224a15c1d4d9793e27c2b6302, 2023-06-07T14:29:00.206Z)
OS version: Darwin arm64 22.4.0
Modes:

<details>
<summary>System Info

</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 (8 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>metal: disabled_off<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|1, 1, 2|
|Memory (System)|16.00GB (0.16GB free)|
|Process Argv|--crash-reporter-id 8c929aab-d0c0-4713-9ace-62e8c8da045d|
|Screen Reader|no|
|VM|0%|
</details>Extensions: none<details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
3biah626:30602489
pyind779:30671433
89544117:30613380
vscrpc:30673769
pythonsymbol12:30671437
2i9eh265:30646982
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
a2ce3375:30757347
pythonfmttext:30731395
pythoncmv:30756943
fixshowwlkth:30771522
pythongtdpath:30769146
dh2dc718:30770000
e537b577:30772215

```

</details>

<!-- generated by issue reporter -->
Repository: rust
Issue: OOB index in async fn evades linter
Labels: A-diagnostics,P-low,A-async-await,AsyncAwait-Polish,AsyncAwait-Triaged

I am hitting `index out of bounds` panics when indexing into arrays in macros inside `aync` functions.  An example is the following. 
```
async fn foo() {
    let x: [u8; 1] = [0];
    rprintln!("{:x} {:x}", x[0], x[1]);
}
```

```
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', src/main.rs:18:34
```

This [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d9cb4c0d1e339d1cc46864b119b93d) showcases the issue.  The actual macro I am using is [rprintln](https://docs.rs/rtt-target/latest/rtt_target/macro.rprintln.html) from [rtt-target](https://docs.rs/rtt-target/latest/rtt_target/index.html)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: inspector can not edit elements of typed color array at runtime
Labels: bug,topic:core,topic:gdscript

### Godot version

v4.0.3.stable.official.5222a99f5

### System information

Kubuntu 22.04 OpenGL API 4.6 (Core Profile) Mesa 22.2.5 - Compatibility - Using Device: Intel

### Issue description

Pardon my english.

It looks like the inspector's color picker has some problems when trying to edit a color
which is inside typed array.

'problem' node 'repro_a.gd':
```var COLORS : Array[Color] = []```

'no problem' node 'repro_b.gd':
```var COLORS : Array = []```

### Steps to reproduce

1. open and run repro project.
2. select 'problem' node in the remote tree
3. expand the 'COLORS' member (inspector > members > colors)
4. click on any colored rect in the inspector
5. pick new color inside the color picker that should pop up
6. observe that the color stays the same and the color picker closes

the same steps but for child 'no problem' node give semi expected result of setting the color
but draging in the color picker closes it on mouse release (which is ok but adds 1 extra click 
to open color picker again if not satisfied with the result)

### Minimal reproduction project

[repro.zip](https://github.com/godotengine/godot/files/11804720/repro.zip)
Repository: next.js
Issue: Rendering Suspense in server component throws React error 419 in production builds
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
λ npx next info

    Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 22.5.0: Mon Apr 24 20:51:50 PDT 2023; root:xnu-8796.121.2~5/RELEASE_X86_64
    Binaries:
      Node: 19.6.0
      npm: 9.4.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 13.4.7-canary.1
      eslint-config-next: 13.4.6
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

_No response_

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/fervent-snowflake-9fzx7p?file=%2Fapp%2Flayout.tsx%3A9%2C19

### To Reproduce

Implement the [NavigationEvents component](https://nextjs.org/docs/app/api-reference/functions/use-router#router-events) exactly as it's described in the docs into a new Next app. It causes errors unless I unwrap the Suspense boundary.

### Describe the Bug

I'm using the [NavigationEvents component straight out of the docs](https://nextjs.org/docs/app/api-reference/functions/use-router#router-events).

When I wrap the component in a Suspense boundary, as is recommended, it throws a hydration error. In prod builds, it seems to work fine, but it throws [React error #419](https://legacy.reactjs.org/docs/error-decoder.html/?invariant=419) silently in the console. If I take away the Suspense boundary, then everything seems to work fine and I get no errors. However, the docs seem to imply that the parenting server component is going to rerender on search param updates if I `useSearchParams` in a static render without the boundary. I would want the NavigationEvents to be in the layout, and this would mean that all search param changes trigger full rerenders.

### Expected Behavior

Suspense boundaries should not throw hydrations errors in dev or silent React errors in prod.

### Which browser are you using? (if relevant)

Chrome 114.0.5735.133 (Official Build) (x86_64) 

### How are you deploying your application? (if relevant)

Local & Vercel
Repository: rust
Issue: Passing mutating async function gives unhelpful duplicate type error
Labels: A-diagnostics,T-compiler

### Code

```Rust
async fn mutate(t: &mut i64) {
    *t += 1000;
}

fn use_async_fn<A, U>(_fun: A)
where
    A: Fn(&mut i64) -> U,
    U: futures::Future<Output = ()>,
{
}

fn main() {
    use_async_fn(mutate);
}
```


### Current output

```Shell
error[E0308]: mismatched types
  --> src/main.rs:13:5
   |
13 |     use_async_fn(mutate);
   |     ^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
   |
   = note: expected trait `for<'a> <for<'a> fn(&'a mut i64) -> impl futures::Future<Output = ()> {mutate} as FnOnce<(&'a mut i64,)>>`
              found trait `for<'a> <for<'a> fn(&'a mut i64) -> impl futures::Future<Output = ()> {mutate} as FnOnce<(&'a mut i64,)>>`
note: the lifetime requirement is introduced here
  --> src/main.rs:7:24
   |
7  |     A: Fn(&mut i64) -> U,
   |                        ^
```

### Desired output

Rather than show the same type twice, rustc should explain what the actual mismatch between the two types is.

If you want to get fancy, it could explain how to pass async mutating functions properly :D


### Rationale and extra context

If we find that we'll show the same type twice to the user after stringifying it, we may want to give additional context to help the user better understand what is being shown.

### Other cases

_No response_

### Anything else?

_No response_
Repository: go
Issue: x/mod/modfile: document which fields in a parsed modfile may be nil
Labels: Documentation,help wanted,NeedsInvestigation,modules

We've had several crashes in gopls related to `modfile.File.Module` being nil.

On the other hand, we have a bunch of code checking if `modfile.File.Module.Syntax` is nil -- is that possible if `modfile.File.Module` is non-nil?

It would be nice if the `modfile` API documented which fields may be nil.

CC @bcmills @adonovan
Repository: rust
Issue: `((), !)` and `((), ())` are considered incompatible types
Labels: P-low,T-compiler,regression-from-stable-to-stable,C-bug,F-never_type

[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d9cb4c0d1e339d1cc46864b119b93d)

### I tried this code:

```rust
fn main() {
    let a = if true {
        ((), todo!())
    } else {
        ((), ())
    };
}
```

### I expected to see this happen:
Code compiles, runs, and panics.
`a` has type `((), ())`.

### Instead, this happened:
```
   Compiling example v0.1.0 (/tmp/exmaple)
warning: unreachable expression
 --> src/main.rs:3:9
  |
3 |         ((), todo!())
  |         ^^^^^-------^
  |         |    |
  |         |    any code following this expression is unreachable
  |         unreachable expression
  |
  = note: `#[warn(unreachable_code)]` on by default

error[E0308]: `if` and `else` have incompatible types
 --> src/main.rs:5:9
  |
2 |       let a = if true {
  |  _____________-
3 | |         ((), todo!())
  | |         ------------- expected because of this
4 | |     } else {
5 | |         ((), ())
  | |         ^^^^^^^^ expected `((), !)`, found `((), ())`
6 | |     };
  | |_____- `if` and `else` have incompatible types
  |
  = note: expected tuple `((), !)`
             found tuple `((), ())`

For more information about this error, try `rustc --explain E0308`.
warning: `example` (bin "example") generated 1 warning
error: could not compile `example` (bin "example") due to previous error; 1 warning emitted
```
### The following changes have no effect:
* Removing `let a = `.
* Changing `true` to some runtime-only condition.
* Swapping the two branches.
* Replacing `if`-`else` with `match`.
* Swapping `todo!()` and `()` inside of the tuple.
* Replacing `todo!()` with `loop{}` or `std::process::exit(0)`.
* Replacing `todo!()` with a call to a function returning `std::convert::Infallible` (though this makes the warning about the unreachable code go away).
* Using `u8` or any other "normal" type instead of `()`.

### The following changes make the error go away.
*
```rust
let x = todo!();
((), x)
```
*
```rust
fn foo() -> () { todo!() }
((), foo())
```
*
```rust
let foo = || todo!();
((), foo())
```
*
```rust
((), (||todo!())())
```


### Meta
`rustc --version --verbose`:
```rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2
```
Same on nightly and beta.

Must be related to #35121.
Repository: TypeScript
Issue: Auto-imports with NodeNext + isolatedModules missing type qualifier for decorated types
Labels: Bug,Help Wanted,Effort: Moderate,Domain: Auto-import

# Bug Report

### 🔎 Search Terms

- isolatedModules
- type
- import

### 🕗 Version & Regression Information

It's happening in 5.1.3, but it's surely been present since the 4.x version where `"moduleResolution": "NodeNext"` was supported.

### 💻 Code

See example below. The tsconfig should have the following configuration:
```json
"isolatedModules": true,
"moduleResolution": "NodeNext",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
```

### 🙁 Actual behavior

When typing out the code on the last line and accepting the suggested import, you get the following import:

```typescript
import { SomeType } from "apackage";

@a
const s: SomeType;
```

This import won't compile with this TS project configuration.

### 🙂 Expected behavior

Instead, you should get an import like this, since explicit type imports are required (compiler error) when `isolatedModules` is set to `true`, when `moduleResolution` is set to `NodeNext` and using decorators.

```typescript
import type { SomeType } from "apackage";

@a
const s: SomeType;
```

Today, the workaround is to use an [eslint rule](https://typescript-eslint.io/rules/consistent-type-imports/) to help auto-fix these issues.
Repository: kubernetes
Issue: Idea: EOL "apply" in favor of more descriptive verbs
Labels: sig/cli,sig/architecture,triage/accepted

https://github.com/kubernetes/kubernetes/issues/118725 illustrates some surprising behavior with `kubectl apply`.  I have found, repeatedly, that humans are bad at predicting what apply will do (made worse by client-side and server-side being different).

From talking to a lot of people, the `apply` action feels like it means `create-or-replace`, but it's really not.  It's a much more sophisticated resource co-ownership system.  If you don't keep that in mind, it will almost certainly NOT do what you expect it to do, which has led to many bugs over the years (as @apelisse can attest).

In hindsight, I wonder if "apply" was the right name for this.  Perhaps we really want 2 distinct operations - something like "kubectl set" (simple create-or-replace) and "kubectl merge" (what we call "apply" today).  I suspect that vast majority of issues reported with "apply" would be avoided because humans would mostly use "set", and "merge" would be much more clearly a variant of patch, left for "advanced" cases.

Saying `kubectl set -f deploy.yaml` intuitively means one thing, while `kubectl merge -f deploy.yaml` clearly means something else.  I don't know if we want to extend that to `edit`, too.

I wonder if it is possible to steer towards a future where this is clearer.  @apelisse @soltysh @KnVerey @eddiezane @jpbetz
Repository: go
Issue: x/tools/gopls: update package and imports on willRenameFiles/didRenameFiles
Labels: FeatureRequest,gopls,Tools,Refactoring

when I move go file between folders I want VSCode to automatically update package name and imports in go files that reference file being moved. Like it happens in Intellij Goland

Many thanks in advance for any feedback.