sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: imgwarp error: invalid types 'short int[int]' for array subscript in function initInterTab2d after #if CV_SIMD128
Labels: category: imgproc,priority: low,category: build/install,platform: other

<!--
If you have a question rather than reporting a bug please go to https://forum.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 4.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2017
-->

- OpenCV => :grey_question:
- Operating System / Platform => :grey_question:
- Compiler => :grey_question:

##### Detailed description

<!-- your description -->

##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->

##### Issue submission checklist

 - [ ] I report the issue, it's not a question
   <!--
   OpenCV team works with forum.opencv.org, Stack Overflow and other communities
   to discuss problems. Tickets with question without real issue statement will be
   closed.
   -->
 - [ ] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found solution
   <!--
   Places to check:
   * OpenCV documentation: https://docs.opencv.org
   * FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://forum.opencv.org
   * OpenCV issue tracker: https://github.com/opencv/opencv/issues?q=is%3Aissue
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv
   -->
 - [ ] I updated to latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only latest release for each branch.
   The ticket is closed, if the problem is not reproduced with modern version.
   -->
 - [ ] There is reproducer code and related data files: videos, images, onnx, etc
   <!--
   The best reproducer -- test case for OpenCV that we can add to the library.
   Recommendations for media files and binary files:
   * Try to reproduce the issue with images and videos in opencv_extra repository
     to reduce attachment size
   * Use PNG for images, if you report some CV related bug, but not image reader
     issue
   * Attach the image as archive to the ticket, if you report some reader issue.
     Image hosting services compress images and it breaks the repro code.
   * Provide ONNX file for some public model or ONNX file with with random weights,
     if you report ONNX parsing or handling issue. Architecture details diagram
     from netron tool can be very useful too. See https://lutzroeder.github.io/netron/
   -->
Repository: rust
Issue: [ER] Iterator::zip_exact
Labels: T-libs-api,C-feature-request,A-iterators

Perhaps it's worth having an `Iterator::zip_strict` as in Python 3.10 in the stdlib:

https://www.python.org/dev/peps/pep-0618/
Repository: godot
Issue: transform.basis not constant with changes to global_transform.origin
Labels: topic:core

**Godot version:**
3.3-stable

**OS/device including version:**
Windows 10

**Issue description:**
I have two Spatial nodes, one a child of the other, and the following script which sets the upper node's rotation and the lower node's global origin.  

```GDScript
var t = 0
func _process(dt):
	t += dt
	get_parent().rotation_degrees.z = t
	global_transform.origin = Vector3(t, 2*t, 1)
	print(transform.basis.x)
```

After a few seconds the vectors that make up `transform.basis` -- which I do not expect to change at all -- begins to drift:

```
(1.000024, 0.000001, 0)
(1.000024, 0, 0)
(1.000025, 0, 0)
(1.000025, 0, 0)
(1.000025, 0, 0)
(1.000025, 0.000001, 0)
```
It does not take long before this basis is no longer orthonormal, which can create problems.  

If I replace it with `transform.origin = Vector3(t, 2*t, 1)` then there is no longer a drift.

I believe `global_transform.origin = p` is equivalent to `transform.origin = get_parent().global_transform.inverse()*p`, so there is no reason for there to be any change to the value of `transform.basis`.

**Steps to reproduce:**
See above

**Minimal reproduction project:**
[transformtest.zip](https://github.com/godotengine/godot/files/6488102/transformtest.zip)
Repository: rust
Issue: Less helpful compiler error upon module/trait name clashes
Labels: A-diagnostics,T-compiler,C-bug,D-confusing

<!--
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.
-->

I was encouraged [1] to report this and filing as a bug seemed the most appropriate.  The issue is of course clear to the experienced user, but it was very confusing.  The issue is that moving a trait into a module with the same name leads to confusing compiler errors.  It's possible this could be improved by noticing the clash which is bound to lead to problems.  The full repro [2] has not been boiled down as it's simple enough and I wanted to give the context to motivate why I would have done this, however the gist is this:

[1] https://twitter.com/ekuber/status/1393605930483388416
[2] https://github.com/tommythorn/bp/tree/newb-struggles

```rust

```

I expected to see this happen: telling me that what I thought was a trait was now a module

Instead, this happened:
```
  error[E0599]: no function or associated item named `new` found for struct `Boolish::TwoBitCounter` in the current scope
     --> src/main.rs:179:39
      |
  37  |     pub struct TwoBitCounter {
      |     ------------------------ function or associated item `new` not found for this
  ...
  179 |         let pht = vec![TwoBitCounter::new(true); 1 << addr_bits];
      |                                       ^^^ function or associated item not found in `Boolish::TwoBitCounter`
      |
      = help: items from traits can only be used if the trait is in scope
  help: the following trait is implemented but not in scope; perhaps add a `use` for it:
      |
  2   | use crate::Boolish::Boolish;
      |
 ```


```
mod Boolish { // XXX
    pub trait Boolish {
        fn update(&mut self, taken: bool) -> &mut Self;
        fn value(&self) -> bool;
        fn new(b: bool) -> Self;
    }
...
    impl Boolish for TwoBitCounter {
        fn update(&mut self, taken: bool) -> &mut Self {
            ...
        }
...
} // XXX
use Boolish::*; // XXX
...
    fn new(addr_bits: usize) -> LocalBp {
        let pht = vec![TwoBitCounter::new(true); 1 << addr_bits];
```

Without the lines marked with XXXs this works perfectly.

### 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.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: aarch64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0
Repository: rust
Issue: strong performance issue when using struct instead of multiple variables
Labels: I-slow,C-enhancement,T-compiler,C-optimization

I ran into an issue when working on a prime sieve.
I grouped three related variables (two arrays and an integer) into a struct to have less variables being passed around.
While profiling I noticed that the execution time went up from 2.8s to 7s when using the struct.
Based on some Discord hint´s I guess that shouldn´t be the case: https://discord.com/channels/273534239310479360/273541522815713281/843272480852672513

Here is my actual struct:
```Rust
pub struct Aux {
    pub sieve: [u64;_AUX_SIEVE_WORDS_ as usize], 
    pub primes: [u32;_NUMBER_OF_AUX_PRIMES_],
    pub base: u32,
}
```
I created a gh repo, showing the different versions: https://github.com/ZuseZ4/perf_comp

Branch with_struct: I´m passing the struct by ref => 7s
Branch no_struct: I´m passing both arrays by ref, integer by value => 2.8s
Branch no_struct_ref: I´m passing both arrays and the integer by ref => 2.8s

**Setup:**
I use release mode, lto=true and target=native. (The last two seem to have no effect.)
rustc 1.52.1 (9bc8c42 2021-05-09)
(1.54.0-nightly (fe72845f7 2021-05-16) gives the same performance)
Ubuntu 20.04 (5.4.0-73-generic)
AMD® Athlon 200ge with 2x16 GB DDR4-3200

I could understand that an extra layer of indirection and therefore (if not removed by optimizations) pointer deref. could cause some performance cost, but I´m surprised about the large difference. 

Did I miss something?
Repository: create-react-app
Issue: typscript incremental builds?
Labels: stale,needs triage

What is the status of CRA with TypeScript support for `incremental` builds? I did a couple of tests without changing much aside from setting `incremental` and `outDir` in my tsconfig.json, but they seem to have no effect.

Seeing as how both snowpack and vitejs promise greatly faster start times during development, I think supporting `incremental` would go a long way in keeping CRA up to par somewhat (potentially?) in terms of speed.

I've read at least one issue recommending the use of something like CRACO to configure fork-ts-checker-webpack-plugin (alas no examples), but I think this is way more work than should be required for something that the ts compiler supports with a flag.
Repository: godot
Issue: BulletPhysicsDirectSpaceState is not registered with ClassDB, thus not exported for GDNative 3.x
Labels: bug,topic:gdextension

In 3.x, I'm using godot-nim.  Using Bullet, try to get the PhysicsDirectSpaceState from World from Spatial.

```nim
  self.getWorld().directSpaceState # error no constructor for BulletPhysicsDirectSpaceState
```
The api.json returned from godot does not contain BulletPhysicsDirectSpaceState.  

The Bullet module register_type.cpp needs to register BulletPhysicsDirectSpaceState.

This should affect all GDNative 3.x bindings.
Repository: flutter
Issue: [Proposal] Add Missing Cupertino Icons
Labels: framework,a: fidelity,f: cupertino,a: quality,has reproducible steps,P2,found in release: 2.3,p: cupertino_icons,team-design,triaged-design

car and car_fill look a bit wonky

This issue is a consolidated proposal to add missing Cupertino icons and fix incorrect icons

### Incorrect icons

- [ ] `car`icon is incorrect https://github.com/flutter/flutter/issues/82634
- [ ] `gear` displays the same icon as `gear_icon` https://github.com/flutter/flutter/issues/80868
- [ ] `settings_solid` displays the same icon as `settings` https://github.com/flutter/flutter/issues/88885
- [ ] `square_pencil` and `square_pencil_fill` are the same #68436
- [ ] `create` icon is incorrect https://github.com/flutter/flutter/issues/116594

### Proposal 

- [ ] Add AirPlay icons https://github.com/flutter/flutter/issues/91786
- [ ] Add missing clipboard icons https://github.com/flutter/flutter/issues/116565
Repository: godot
Issue: Implement Cull Mask for DirectionalLight2D
Labels: enhancement,topic:rendering,confirmed,topic:2d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
4.0.dev.custom_build.2295d3eba


**OS/device including version:**
Ubuntu 20.04.2 LTS


**Issue description:**
It seems only possible to either affect all layers by a DirectionalLight2D or none of them. 
This behavior is controlled by setting or not setting the Layer Min value
of the DirectionalLigh2Ds Range-Property to either 0 or any other value. 
If I exclude 0 of the Min and Max range, none of the layers is affected, otherwise every layer is affected. 
E.g. I do not want my Backgroundtexture to be affected, but no matter which Light-Mask-Layer-Combination 
I try for this node, it either is affected by the DirectionalLight2D or it is not. 
And this seems to solely depend of the RangeProperty-Settings of the DirectionalLight2D node.
I would expect the Texture to be affected only by the light node if the light masks are matching, but this is not the case.



**Steps to reproduce:**
Create a new project and add a Sprite and a DirectionalLight2D node. Under Visibility choose different options for the Light Mask Layer of your Sprite Node. The DirectionalLight2D will always affect your Sprite-Node, no matter if its Light Mask matches the Item Cull mask of the DirectionalLight2D or not.



**Minimal reproduction project:**
[2dDirectionalLightGodot4.zip](https://github.com/godotengine/godot/files/6488948/2dDirectionalLightGodot4.zip)
Repository: rust
Issue: Vec::pop() sometimes returns value inefficiently.
Labels: I-slow,A-collections,C-bug,T-libs

<!--
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.
-->

I tried this code:

```rust
#[repr(align(32))]
#[derive(Copy, Clone)]
pub struct Data {
    u64s: [u64; 4],
    options: Option<(u64, u8, Option<u8>)>
}

pub fn len_minus_one(mut vec: Vec<Data>, value: &mut Data) {
   *value = vec[vec.len() - 1];
   vec.pop();
}

pub fn pop(mut vec: Vec<Data>, value: &mut Data) {
   *value = vec.pop().unwrap();
}
```

I expected to see this happen: The two functions generate similar assembly.

Instead, this happened: `Vec::pop()` uses far less efficient copying.

### 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`: 
```
<version>
binary: rustc
commit-hash: 88f19c6dab716c6281af7602e30f413e809c5974
commit-date: 2021-05-03
host: x86_64-pc-windows-msvc
release: 1.52.0
LLVM version: 12.0.0
```

It also happens on Nightly, although the generated assembly is much better.

Edit: It appears to be related to an `Option` holding the value, because the same behaviour is observed when using `vec.get(vec.len() - 1).copied().unwrap()` but not `*vec.get(vec.len() - 1).unwrap()`.
[Playground Link](https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=30690a4a0439a3836f30c6e29c7f5daf)
Repository: flutter
Issue: Consider a test suite that compiles all of our sample code
Labels: team,framework,d: api docs,a: quality,P2,team-framework,triaged-framework

I've seen quite a few issues go by over time where someone finds that our sample code doesn't compile. Some causes include:
- Breaking changes in our APIs
- Stronger type restrictions in Dart over time
- NNBD
We'll also have a lesser version of this as the new standard lint options roll out; the code may still compile, but show issues in a clean new project, which still isn't a great experience.

We should consider having a policy of having all of our sample code be copied from a test suite (annotated with comments linking to the page containing it) that we run on every stable release of Flutter, so that we catch these proactively rather than them building up as issues that are found later by consumers of the docs.

/cc @Hixie
Repository: rust
Issue: Tracking Issue for `async {}` blocks in const expressions
Labels: C-tracking-issue,A-const-eval,F-const_async_blocks

This is a tracking issue for use of `async {}` expressions in const contexts.
The feature gate for the issue is `#![feature(const_async_blocks)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implement the feature (https://github.com/rust-lang/rust/pull/85353)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->


### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->
Repository: vscode
Issue: [folding]  highlight folding range when hovering over the collapse button
Labels: feature-request,editor-folding

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
In other editors like Visual Studio the region you are about to collapse gets highlighted when you are hovering over the "-" button to collapse it:
![image](https://user-images.githubusercontent.com/42123497/118400319-6c4cfd80-b661-11eb-9ca7-73a4e86ea83a.png)

VS code does not have a way to do this as far as I can tell.
Repository: PowerToys
Issue: Disabling Windows Task View including edge swipe
Labels: Idea-New PowerToy,Product-Tweak UI Design

### Provide a description of the new feature / enhancement

Windows allows you to remove the task view button from the taskbar but there are still multiple ways task view itself can be triggered often unintentionally, including by swiping 3/4 fingers on the touchpad (an accidental brush with the hand in passing) or dragging across the left edge of a touch screen (it's very easy to trigger this accidentally by selecting and dragging something that is partially off screen like a jigsaw piece placed next to the puzzle in Microsoft Jigsaw). There is also a Logitech keyboard that causes task view to trigger frequently. 
Some users also wish to prevent deliberate activation on eg a tablet used as a kiosk device. 

There are numerous support requests in official and unofficial forums from users wanting to turn off task view (usually the response is to turn off the task view button on the taskbar and the OP then explains in some frustration that they want to remove the feature, not the button).

Although you can turn off the multifinger touchpad features, this doesn't turn off edge swipe and other accidental triggers and it doesn't block the feature for kiosk cases.
Currently users have to edit the registry to set (or usually create) the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\EdgeUI\AllowEdgeSwipe DWORD and set it to 0. 

This seems like exactly the kind of thing PowerToys is there for.
Repository: rust
Issue: Orphan rules work differently when supertrait is specified in trait bounds
Labels: C-bug,T-types,A-coherence

The following code is expected to compile without errors.

```rust
pub trait Foo {}
pub trait Bar<T>: Foo {}

pub trait Foo2 {}
pub trait Bar2<T>: Foo2 {}


impl<T> Foo2 for T where T: Foo {}
impl<U, T> Bar2<U> for T where T: Bar<U> {}

impl<T> Foo2 for Option<T> where T: Foo2 {}
impl<U, T> Bar2<U> for Option<T> where T: Bar2<U> {}
```

However possible conflict implementation in upstream crates is detected.

Rewriting 2nd impl as:
```rust
impl<U, T> Bar2<U> for T where T: Bar<U> + Foo {}
```
i.e. adding `Foo` bound,
solves the issue. Which should not be required as `Foo` is supertrait of `Bar`.

### Meta

`rustc --version --verbose`:
```
rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: x86_64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0
```

[playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8c75cb5cd282f0ebe3bf30b29dc773c5)
Repository: rust
Issue: rustdoc: make [-] invisible in most cases
Labels: T-rustdoc,C-enhancement,A-rustdoc-ui,A-rustdoc-js

The toggles (`[-]` / `[+]`) on rustdoc pages are needed for a couple of reasons:

 - Some sections are closed by default and need a `[+]` to open them.
 - Some sections are open by default, but can be default-closed by a setting. Those need a `[+]` to open them.
 - The user might close all sections with the "collapse all docs" button. Those need a `[+]` to open them.
 
Note that these all involve the `[+]`, not the `[-]`. But we show lots of `[-]` all over the page, which is visually distracting. In theory these allow users to collapse a single section at a time, but I don't think that's very useful.
 
I propose that we make `[-]` invisible. With one exception: If someone has opened a section with `[+]`, it would be confusing and frustrating to not be able to close that section again. So, when someone clicks a `[+]`, we would added a "perma-visible" class to that `<summary>` tag, which would cause the `[-]` to be visible.

cc @GuillaumeGomez
Repository: vscode
Issue: [html] allow to configure html formatter for other languages
Labels: feature-request,html

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

This would allow users to, for example, force the default HTML formatter to format variations of the language, such as Django HTML.

For example, VSCode won't run the default HTML formatter if the file I'm working on is associated with Django HTML. However, if I tell it it's just regular HTML the formatter will run fine, without any problem. This feature would allow to skip the middle step of telling the editor it's something else just to format the file.

I think a good way to have this work would be to have something similar to the editor.defaultFormatter property, or just have it consider whatever is given to it the formatter that should be used.
Repository: pytorch
Issue: Add better python operators annotations for IDE type checking
Labels: high priority,feature,module: typing,triaged

🚀 Feature

Back in the days you had a nice mapping from `__lt__ ` to ` torch.lt`  like in [this version](https://github.com/pytorch/pytorch/blob/fa8044d92f8a77b8008ca5e295a341abb9d26f13/torch/tensor.py#L292), and IDE got it just fine, 

But current implementation of tensor hides its python magic operators so IDE's like Pycharm highligh an error when used in comparison with floats or bools like this one: "Expected type 'float', got 'Tensor' instead". However it doesn't highlight it if use torch comparison functions like `torch.lt` function which suggests that proplem is in dynamic method loading or something like this. So the request is to add any kind of operator definition to eliminate typechecker highlight. 


cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @anjali411 @malfet @rgommers @xuzhao9 @gramster