sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: excalidraw
Issue: feature request: opacity slider for crosshatch fills
Labels: discussion

I sometimes find myself wanting to be able to create a crosshatched box that sits on top of an arrow, but without the arrow being seen inside the box itself: this can be done by creating a background-filled box with no border and then another box on top as usual, but it is a bit cumbersome.

I was wondering if it would be possible to add this as a feature (say a separate checkbox/slider for the "fill background" opacity) which behind the scenes can do the same (create a no-border box the color of the background with configurable opacity sitting behind the box the user is creating) allowing non-solid boxes to hide other objects/text/... if so desired
Repository: rust
Issue: `target json file contains unused fields` unaffected by `-Dwarnings`
Labels: A-lints,T-compiler,E-medium,C-bug,needs-fcp

I tried this:

```sh
# t.json is a target spec file with an unknown field
$ cat t.json | grep foo
  "foo": "bar",
$ rustc -Dwarnings --target=t.json < /dev/null
```

I expected to see this happen: the `warning: target json file contains unused fields: foo` diagnostic to be an error.

Instead, this happened: the warning is still a warning, even with `-Dwarnings`.

If this is intended (i.e. if `-Dwarnings` is only intended for code-related diagnostics), then this issue would be a feature request: a way to control whether non-code warnings are (or not) errors for CI purposes.

### Meta

Happens in both stable (1.56.1) and the latest nightly:

```
rustc 1.58.0-nightly (dd549dcab 2021-11-25)
binary: rustc
commit-hash: dd549dcab404ec4c7d07b5a83aca5bdd7171138f
commit-date: 2021-11-25
host: x86_64-unknown-linux-gnu
release: 1.58.0-nightly
LLVM version: 13.0.0
```
Repository: electron
Issue: [Feature Request]: app.getPath("trash") should return the path to the OS-specific trash location, and shell.restoreItem(path) should restore deleted items from the trash back to their original locations.
Labels: enhancement :sparkles:

### Preflight Checklist

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

### Problem Description

Right now, shell.trashItem(path) moves a given item to the OS-specific trash location.

However, there is no easy way for an Electron app's author to know where that trash location is, so there is no easy way to write an Electron app that shows the contents of the trash or allows the user to restore items from the trash to their original location.

### Proposed Solution

app.getPath("trash") should return the path to the OS-specific trash directory.

It would also be fantastic if shell.restoreItem(path) restored deleted items from the trash back to their original locations.


### Alternatives Considered

No npm package seems able to offer this functionality, either.

### Additional Information

_No response_
Repository: rust
Issue: rustdoc: `broken_intra_doc_links` is incorrectly reported when linking to a proc macro
Labels: T-rustdoc,A-lints,C-bug,A-intra-doc-links,A-proc-macros

Rustdoc only emits a documentation page for `my_macro` as a macro; there's no function page for it.

Note that the link indeed fails to resolve.

### Code

```rust
//! Link to [`my_macro`].

#![crate_type = "proc-macro"]

extern crate proc_macro;

#[proc_macro]
pub fn my_macro(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
    input
}
```

### Output

```
warning: `my_macro` is both a function and a macro
 --> foo.rs:1:15
  |
1 | //! Link to [`my_macro`].
  |               ^^^^^^^^ ambiguous link
  |
  = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
help: to link to the function, add parentheses
  |
1 | //! Link to [`my_macro()`].
  |                       ++
help: to link to the macro, add an exclamation mark
  |
1 | //! Link to [`my_macro!`].
  |                       +

warning: 1 warning emitted
```
Repository: godot
Issue: Android inner line edit shown when transparent
Labels: bug,platform:android,topic:porting,topic:gui

### Godot version

3.4 Stable

### System information

Android

### Issue description

Godot 3.4 enabled transparency support for Android, so I finally added "normal" wallpaper support to my Android launcher. The new transparency support revealed a hidden android line-edit that was in the background and now it can be seen as a weird line. It's in the top left of the video below.

https://user-images.githubusercontent.com/57882701/143663866-6bdd1615-5f65-4a6a-8b93-2f80245aa236.mp4

It's easier to see in the MRP linked below:
![Screenshot from 2021-11-26 19-19-17](https://user-images.githubusercontent.com/57882701/143663974-43e27277-22ff-453c-a07b-33516162383f.png)



### Steps to reproduce

Enable transparency for an Android project and use a line edit node.

### Minimal reproduction project

https://github.com/likeich/LineEditTransparentIssue
Repository: godot
Issue: Sprite2D(With Region Enabled) from same parent disappears
Labels: bug,topic:rendering,topic:2d

### Godot version

4.0.dev(5efe80f)

### System information

Intel UHD Graphics, Vulkan

### Issue description

When using two **Sprite2D** in the same parent node, the moment you start the game, one of them disappears, it's still there but invisible. Apparently happens when changing one of the two **Sprite2D** names.

While writing this, I also discovered that this happens in scenes that have the scene has a child node
![image](https://user-images.githubusercontent.com/43357489/143667594-1d4fcbbb-3700-4e30-b48d-e4bf571bdd45.png)
![image](https://user-images.githubusercontent.com/43357489/143667616-93a0f320-bed4-47b4-9579-35864d62c6dc.png)

### Steps to reproduce

1. Create a CanvasLayer, Node2D, or Control
2. Add two sprites
3. Enable region
4. Change the name of one of the two sprites
5. Start the game or check a scene that has the scene has a child node

### Minimal reproduction project

_No response_
Repository: rust
Issue: rustdoc: unstable feature warning wraps early on iPad
Labels: T-rustdoc,A-rustdoc-ui

Visiting https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.assume_init_read on an iPad Pro results in the following:

![PXL_20211126_050244055](https://user-images.githubusercontent.com/220205/143671000-9d16e38c-24d3-4e89-8009-405819fe0e13.jpg)

The yellow box warning about an unstable feature is both too long and too short. If it were wider, it could accomodate all its text without wrapping. Given that it wraps, it shouldn't be so wide.

This reproduces on latest Chrome, Brave, and Safari on iPad, in landscape mode. Note that in landscape mode it looks fine. Also, the width of the yellow box in landscape mode is exactly the same size as when it's in portrait mode.

![PXL_20211127_063806912](https://user-images.githubusercontent.com/220205/143671182-7a63d1e5-7a06-4c03-946d-82b98824b11d.jpg)

Reproduces on stable as well as nightly.
Repository: rust
Issue: Tracking Issue for `ops::Residual` (feature `try_trait_v2_residual`)
Labels: T-libs-api,C-tracking-issue,F-try_trait_v2

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(try_trait_v2_residual)]`

This is a tracking issue for the `ops::Residual` trait.

This is used by `try_*` APIs that need to change from one member of a family to another, such as
- https://doc.rust-lang.org/nightly/std/array/fn.try_from_fn.html #89379
- https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.try_find #63178
- https://doc.rust-lang.org/nightly/std/primitive.array.html#method.try_map #79711

For example, the closure passed to `Iterator::try_find` returns `Foo<bool>`, but the method wants to be able to return `Foo<Option<<Self as Iterator>::Item>>`.

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// ops::Residual

trait Residual<O> {
    type TryTrait: Try<Output = O, Residual = Self>;
}

// with implementations for `Result`, `Option`, and `ControlFlow`.
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #91286
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- If `Try::Residual` is renamed (an open question in #84277), this this probably should be too.
Repository: opencv
Issue: UMat: support processing of ND arrays
Labels: optimization,feature,category: core,category: ocl,category: t-api

Epic ticket to track support of multidimensional arrays (ND-tensors) processing

They are widely used e.g., in DNN module.

We have gaps in these areas:
- element-wise "arithm_op"
- element-wise `convertTo()`
- element-wise `convertToFp16()`
- reduce functions (min/max/etc)
- norm
- ...

Current approach is fallback on CPU code (which cause performance issues).

There are two levels of implementations complexity:
- support contiguous ND arrays
- support ROI in ND arrays
Repository: PowerToys
Issue: Add setting in mouse utilities to disable "Enhance pointer precision" when game mode is on
Labels: Idea-Enhancement,Product-Mouse Utilities

### Description of the new feature / enhancement

When Game Mode is on, the setting in Mouse Properties -> Pointer Options Motion -> Enhance pointer precision be unchecked.  Or Checked if one needs this.
When Game Mode is off, restore the original setting. 


### Scenario when this would be used?

When I play a game that is very mouse centric, e.g. Shooter, MOBA and others, I need the distance that the mouse traveling the screen be constant regardless of the physical speed of my mouse device.

### Supporting information

_No response_
Repository: flutter
Issue: [webview_flutter] Resolving avoid_unused_constructor_parameters results into CI breaking.
Labels: p: webview,package,team-ecosystem,P3,triaged-ecosystem

The `abstract class WebViewPlatformController` (part of the webview_flutter_platform_interface package) defines a constructor that accepts a `WebViewPlatformCallbacksHandler` parameter which is never used in this class. Therefore code analysis is reporting the `avoid_unused_constructor_parameters` warning and suggest to remove the parameter from the constructor. Unfortunately the `class WebViewAndroidPlatformController` from the webview_flutter_android package is calling `super(callbacksHandler)` which makes removing the unused parameter a breaking change for the flutter/plugins CI. 

My suggestion is to:
1. Remove the call to `super(callbacksHandler)` from the `WebViewAndroidPlatformController` and publish the patch;
2. ~~Once the new version of the webview_flutter_android package is published remove the constructor from the `WebViewPlatformController` class in the webview_flutter_platform_interface package.~~

Involved files are:

- [webview_flutter_platform_interface/lib/src/platform_interface/webview_platform_controller.dart](https://github.com/flutter/plugins/blob/7760622ae0953155bdcb8436d9275efbce828378/packages/webview_flutter/webview_flutter_platform_interface/lib/src/platform_interface/webview_platform_controller.dart#L24)
- [webview_flutter_android/lib/webview_android_widget.dart](https://github.com/flutter/plugins/blob/7760622ae0953155bdcb8436d9275efbce828378/packages/webview_flutter/webview_flutter_android/lib/webview_android_widget.dart#L95)

EDIT: as suggested by @stuartmorgan in the comment below, we should ignore the warning and place a comment to remove the constructor the next time we do a breaking change on the interface.
Repository: godot
Issue: `Geometry::closest_distance_between_segments()` returns wrong result
Labels: bug,topic:core

### Godot version

Godot 3.4, 4.0

### System information

Windows 10 64 bits GLES3 GeForce GTX 1060 6GB/PCIe/SSE2

### Issue description

I noticed there existed a `closest_distance_between_segments` function in `Geometry`. I gave it a try, but it seems to be broken.
If you give it the following segment points:
```
Vector3(0, -2.5, 0),
Vector3(0, 2.5, 0),
Vector3(2.9888, -5.1938, 0),
Vector3(2.9888, 4.8062, 0)
```
It returns 0, which is not correct.

### Steps to reproduce

```cpp
print_line(String("Test: {0}")
				   .format(varray(
						   Geometry::get_closest_distance_between_segments(
								   Vector3(0, -2.5, 0),
								   Vector3(0, 2.5, 0),
								   Vector3(2.9888, -5.1938, 0),
								   Vector3(2.9888, 4.8062, 0)))));
```

### Minimal reproduction project

_No response_
Repository: rust
Issue: Lifetime mismatch with Option as_mut and map
Labels: A-lifetimes,A-inference

Consider the following code:

```rust
use std::ops::DerefMut;
use std::ops::Deref;

pub trait SectionData: std::io::Read + std::io::Write + std::io::Seek {}

pub struct SectionMut<'a>
{
    data: &'a mut Option<Box<dyn SectionData>>,
}

impl<'a> SectionMut<'a>
{
    pub fn open(&mut self) -> Option<&mut dyn SectionData>
    {
        //self.data.as_mut().map(|v| v.deref_mut()) //Lifetime mismatch
        match &mut self.data { //Works
            Some(v) => Some(v.deref_mut()),
            None => None
        }
    }

    pub fn open1(&self) -> Option<&dyn SectionData>
    {
        self.data.as_ref().map(|v| v.deref()) //Works
    }
}
```

I find it strange that a match statement works but not the map function with as_mut. On the IRC a user found a way to fix it by replacing `Option<&mut dyn SectionData>` with `Option<&mut dyn SectionData + 'static>`. Which is also weird considering 'static is supposed to be implicit. What's also weird is this works perfectly with as_ref alone.

EDIT: I could track the issue down to `dyn` (again). When removing the `dyn SectionData` and replacing it with a concrete struct everything works fine.
Repository: pytorch
Issue: Deterministic implementation for grid_sampler_2d_backward_cuda
Labels: feature,module: cuda,triaged,module: determinism

## 🚀 Feature
Provide a deterministic implementation for `grid_sampler_2d_backward_cuda`

## Motivation

I would like to have deterministic behaviour when training a network with a loss function that uses `torch.nn.functional.grid_sample` to warp images. When I add `torch.use_deterministic_algorithms(True)` in my training script, I get the following error:

`RuntimeError: grid_sampler_2d_backward_cuda does not have a deterministic implementation, but you set 'torch.use_deterministic_algorithms(True)'. You can turn off determinism just for this operation if that's acceptable for your application. You can also file an issue at https://github.com/pytorch/pytorch/issues to help us prioritize adding deterministic support for this operation`

Is it possible to add a deterministic implementation for this? Or is there a workaround that you can suggest me?



cc @ngimel @mruberry @kurtamohler
Repository: godot
Issue: Mesh.create_outline on CylinderMesh has gap
Labels: bug,topic:core,topic:3d

### Godot version

3.4-stable

### System information

Linux 5.15.4-arch1-1, nvidia 1080, GLES3

### Issue description

![1638028484](https://user-images.githubusercontent.com/2496231/143688240-d3418570-70da-45fa-ae93-70192ee87ed7.png)

An outline mesh generated for a cylinder has a gap.

### Steps to reproduce

1. Add a `MeshInstance`
2. Assign a `CylinderMesh` as the `mesh`
3. Select the "Create outline mesh" menu option
4. Increase the thickness to `0.2` (not necessary, but makes it more obvious)

### Minimal reproduction project

[example.zip](https://github.com/godotengine/godot/files/7612003/example.zip)
Repository: pytorch
Issue: Deterministic implementation for upsample_bilinear2d_backward_cuda
Labels: feature,module: cuda,triaged,module: determinism

## 🚀 Feature
Provide a deterministic implementation for `upsample_bilinear2d_backward_cuda`

## Motivation

I would like to have deterministic behaviour when training a network with upsampling and downsampling convolutional layers that use `torch.nn.functional.interpolate` in `bilinear` mode. When I add `torch.use_deterministic_algorithms(True)` in my training script, I get the following error:

`RuntimeError: upsample_bilinear2d_backward_cuda does not have a deterministic implementation, but you set 'torch.use_deterministic_algorithms(True)'. You can turn off determinism just for this operation if that's acceptable for your application. You can also file an issue at https://github.com/pytorch/pytorch/issues to help us prioritize adding deterministic support for this operation.`

Is it possible to add a deterministic implementation for this? Or is there a workaround that you can suggest me?


cc @ngimel @mruberry @kurtamohler
Repository: rust
Issue: Collapse the "missing lifetime specifier" error when there are multiple errors within a single item
Labels: A-diagnostics,A-lifetimes,T-compiler

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
struct Shape {
    name: &str,
    color: &str,
}

fn main() {
    let shape = Shape { name: "pentagon", color: "blue" };
    assert!(shape.name, "pentagon");
}
```

The current output is:

```
error[E0106]: missing lifetime specifier
 --> src/main.rs:2:11
  |
2 |     name: &str,
  |           ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct Shape<'a> {
2 ~     name: &'a str,
  |

error[E0106]: missing lifetime specifier
 --> src/main.rs:3:12
  |
3 |     color: &str,
  |            ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 ~ struct Shape<'a> {
2 |     name: &str,
3 ~     color: &'a str,
  |

For more information about this error, try `rustc --explain E0106`.
```

Ideally the output should look like:

```
error[E0106]: missing lifetime specifiers
 --> src/main.rs:2:11
  |
2 |     name: &str,
  |           ^ expected named lifetime parameter
  |
3 |     color: &str,
  |            ^ expected named lifetime parameter
  |
help: consider introducing named lifetime parameters
  |
1 ~ struct Shape<'a> {
2 ~     name: &'a str,
3 ~     color: &'a str,
  |

For more information about this error, try `rustc --explain E0106`.
```

Filing at the request of @estebank, after I made this mistake in a real project. [Brief discussion thread on Twitter](https://twitter.com/alexwlchan/status/1464508309688528904).
Repository: react
Issue: `Object.prototype` builtins should not be used directly
Labels: Type: Discussion

It is preferable to call certain Object.prototype methods through Object on object instances instead of using the builtins directly.

Objects can have properties that shadow the builtins on Object.prototype, potentially causing unintended behavior or denial-of-service security vulnerabilities.


It's better to always call these methods from ``Object.prototype``. For example, ``obj.hasOwnProperty("bar")`` should be replaced with ``Object.prototype.hasOwnProperty.call(obj, "bar")``.


Below is an example of  a bad practice 👇

```       
let hasBarProperty = obj.hasOwnProperty("property");

let isPrototypeOfBar = obj.isPrototypeOf(property);

let barIsEnumerable = obj.propertyIsEnumerable("property");

 ```

Below is an example of a good practice

```
let hasBarProperty = Object.prototype.hasOwnProperty.call(obj, "property");

let isPrototypeOfBar = Object.prototype.isPrototypeOf.call(obj, property);

let barIsEnumerable = {}.propertyIsEnumerable.call(obj, "property");

```

I have been able to find the same occurences in some files will go ahead and pull a PR only if its worthful.
Repository: godot
Issue: Advanced Import Settings: 3D lines from debug previews (such as collision generation) cast shadows
Labels: enhancement,topic:editor,topic:import,topic:3d

### Godot version

4.0.dev (52b7d5fa3)

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

3D lines cast by previews such as the simple convex decomposition will cast shadows:

![image](https://user-images.githubusercontent.com/180032/143718456-c2788e90-99f8-4baf-ba0e-34065a7df4ec.png)

The shadows should probably be disabled to improve performance on complex previews and avoid confusion.

### Steps to reproduce

- Import a 3D scene (glTF or an OBJ marked as 3D scene instead of mesh).
  - You can try `tesseract/waterworks.obj` from https://github.com/Calinou/game-maps-obj.
- Select the 3D scene in the FileSystem dock. Go to the Import dock and click **Advanced...**.
- Set the collision generation option to **Simple Convex**.
- Notice that blue lines cast directional shadows.

### Minimal reproduction project

N/A