sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Consider re-tuning the lifetime elision rules for trait objects
Labels: A-lints,A-lifetimes,T-lang,C-feature-request,A-maybe-future-edition,A-trait-objects

The lifetime elision rules for functions are willing to fail sometimes, and that's good because `-> &i32` defaulting to `-> &'static i32` would not be what people generally want, and having the error say "hey, what lifetime did you mean?" is way better than getting borrowck errors about "that's not `'static`".

It might be worth taking inspiration from that to improve the elision rules for `dyn Trait`, as lints for now and possibly as hard changes in a future edition.

For example, `impl dyn Trait` is currently `impl dyn Trait + 'static`, but it's not clear that's good.  It might be better to require that the user write `impl dyn Trait + '_` or `impl dyn Trait + 'static` to say which they want.  Inspired by this thread: https://users.rust-lang.org/t/why-do-associated-functions-in-impl-dyn-trait-require-static-lifetime/67548/2?u=scottmcm

Similarly, the `+ 'static` default applies even inside a struct with a lifetime.  For example, https://github.com/rust-lang/rust/issues/91292 had
```rust
pub struct SectionMut<'a> {
    data: &'a mut Option<Box<dyn SectionData>>,
}
```
where the implicit `+ 'static` is more restrictive than needed because it's behind the `&'a` -- but being in the `Box` hides that from elision.

I don't have any concrete proposal here right now, but I figured I'd open this as a place to track it.

---

Other examples (feel free to edit this post to add more down here):
- https://users.rust-lang.org/t/how-to-derive-debug-for-struct-with-a-dyn-trait/69086/3?u=scottmcm
Repository: rust
Issue: Syntax errors in assembly included from another file produce confusing output
Labels: A-diagnostics,T-compiler

The following is a sufficiently supported pattern in Rust to get [a mention in the unstable book](https://doc.rust-lang.org/nightly/unstable-book/library-features/global-asm.html).

```rust
#![feature(global_asm)]
global_asm!(include_str!("something_neato.s"));
```

However, if the included assembly contains a syntax error (such as the ARM instruction `push {r2, r3, r12, lr}` - the solution* is to double the curly brackets to prevent the compiler from interpreting them as a template string) the error you get is somewhat confusing since it blames a seemingly arbitrary point potentially in a completely different source file from the actual error.

```
error: invalid asm template string: expected `'}'`, found `','`
  --> src\bit_utils.rs:36:18
   |
36 |   let mask = (((1_u64 << (H - L + 1)) - 1) << L) as u16;
   |               -  ^ expected `}` in asm template string
   |               |
   |               because of this opening brace
   |
  ::: src\lib.rs:6:13
   |
6  | global_asm!(include_str!("rt0.S"));
   |             --------------------- in this macro invocation
   |
   = note: if you intended to print `{`, you can escape it using `{{`
```

The correct error here would presumably look something like this.

```
error: invalid asm template string: expected `'}'`, found `','`
  --> src\rt0.S:98:12
   |
98 |   push  {r2, r3, r12, lr}
   |         -  ^ expected `}` in asm template string
   |         |
   |         because of this opening brace
   |
  ::: src\lib.rs:6:13
   |
6  | global_asm!(include_str!("rt0.S"));
   |             --------------------- in this macro invocation
   |
   = note: if you intended to print `{`, you can escape it using `{{`
```

This may be related to #81751 - I'm not familiar enough with compiler internals to say, so I erred on the side of posting a new issue.

*or at least *a* solution - another would be to special-case this pattern as unable to use template strings
Repository: rust
Issue: Make rustdoc icons more consistent
Labels: E-easy,T-rustdoc,E-help-wanted,A-rustdoc-ui

Here's a sample of some icons used in rustdoc:

<img width=40 src="https://user-images.githubusercontent.com/220205/143731240-24f94d7f-1655-4752-9450-a0f647b0b8f7.png">
<img width=40 src="https://user-images.githubusercontent.com/220205/143731245-25934400-ccea-4c5d-a90a-c4faad3d78d9.png">

<img width=60 src="https://user-images.githubusercontent.com/220205/143731203-e01e9a7b-0b4a-4976-aec8-54859e7d133e.png">
<img width=40 src="https://user-images.githubusercontent.com/220205/143731208-df68e96a-79d0-47ec-bae2-099da36abf16.png">
<img width=80 src="https://user-images.githubusercontent.com/220205/143731217-8bc17c90-dcee-4041-8c87-2f7e1df710b6.png">
<img width=80 src="https://user-images.githubusercontent.com/220205/143731231-11ecf14d-a652-47bb-a077-2e5c2204084c.png">

![image](https://user-images.githubusercontent.com/220205/143731341-223321e7-2be1-4dca-98e5-8380b716a1d5.png)

Here are some used in docs.rs:

![image](https://user-images.githubusercontent.com/220205/143731194-fdcac621-db1e-4b81-a170-0799cc064aa6.png)

Here are some used on crates.io:

![image](https://user-images.githubusercontent.com/220205/143731309-16a7cd8a-b448-487c-8885-a36195d76805.png)

We should make the rustdoc icons internally consistent, and ideally consistent with related Rust sites as well. It looks like both docs.rs and crates.io are using SVGs from fontawesome's free set: https://github.com/rust-lang/docs.rs/tree/master/crates/font-awesome-as-a-crate/fontawesome-free-5.14.0-web/svgs/regular.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: puppeteer
Issue: [Bug]: Protocol error (Target.createTarget): Failed to open a new tab, in launching with '--guest'
Labels: bug,upstream,confirmed,P3

### Bug description

Steps to reproduce the problem:

Here is a minimum example for reproducing this issue:

```js
const puppeteer = require('puppeteer-core')

puppeteer.launch({ channel: 'chrome', headless: false, args: ['--guest'] }).then(async (browser) => {
    const page = await browser.newPage()
})
```

then get an error:

```
ProtocolError: Protocol error (Target.createTarget): Failed to open a new tab
    at /Users/yusuke-iwaki/Desktop/pup-js/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:75:24
    at new Promise (<anonymous>)
    at Connection.send (/Users/yusuke-iwaki/Desktop/pup-js/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:71:16)
    at Browser._createPageInContext (/Users/yusuke-iwaki/Desktop/pup-js/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Browser.js:261:53)
    at BrowserContext.newPage (/Users/yusuke-iwaki/Desktop/pup-js/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Browser.js:520:30)
    at Browser.newPage (/Users/yusuke-iwaki/Desktop/pup-js/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Browser.js:254:37)
    at /Users/yusuke-iwaki/Desktop/pup-js/main.js:4:32
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  originalMessage: 'Failed to open a new tab'
}
```

### Puppeteer version

12.0.0

### Node.js version

16.10.0

### npm version

7.24.0

### What operating system are you seeing the problem on?

macOS

### Relevant log output

_No response_
Repository: rust
Issue: Hint possible ambiguous derive macros for extern crate
Labels: C-enhancement,A-diagnostics,A-macros,T-compiler,D-terse,A-proc-macros

Given the following code:

```rust
#[macro_use]
extern crate num_enum; // adds derive macro for `Default`

#[derive(Default)]
pub struct Foo {
    bar: i32
}
```

The current output is:

```
error: Expected enum but found struct
 --> src/main.rs:5:5
  |
5 | pub struct Foo {
  |     ^^^^^^
```

Ideally the output should look like:
Hint that derive macros from `std::prelude::*` are overridden by extern crate.
It already hints if glob import is used:

```
error: Expected enum but found struct
 --> src/main.rs:6:5
  |
6 | pub struct Foo {
  |     ^^^^^^

error[E0659]: `Default` is ambiguous (glob import vs any other name from outer scope during import/macro resolution)
   --> src/main.rs:5:10
    |
5   | #[derive(Default)]
    |          ^^^^^^^ ambiguous name
    |
note: `Default` could refer to the derive macro imported here
   --> src/main.rs:1:5
    |
1   | use num_enum::*;
    |     ^^^^^^^^^^^
    = help: consider adding an explicit import of `Default` to disambiguate
    = help: or use `crate::Default` to refer to this derive macro unambiguously
note: `Default` could also refer to the derive macro defined here
   --> /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:129:13
    |
129 |     pub use super::v1::*;
    |             ^^^^^^^^^^^^
```
Repository: angular
Issue: Change detection is not fired on forms updates when using the `OnPush` strategy. 
Labels: area: forms,P3

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

Everything can found here : 

https://stackblitz.com/edit/angular-ivy-paseta?file=src/app/app.component.ts

Explanation : 

When using an async validator with a delayed observable, in a reactive form, with the change detection set to OnPush, the UI does not get updated after the validator has ended its call. 



### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ivy-paseta?file=src/app/app.component.ts

### Please provide the exception or error you saw

```true
No exception, no error, just the UI not updating correctly
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
All can be found on the provided stackblitz
```


### Anything else?

Screenshots for the lazy ones out there : 

First blur : 

![image](https://user-images.githubusercontent.com/46892394/143771758-e8884969-7588-471c-a105-19710dd9553a.png)

Second blur : 

![image](https://user-images.githubusercontent.com/46892394/143771772-7479ac51-f089-450a-9354-f3e266cefed4.png)
Repository: godot
Issue: X11 DisplayServer does not set correct `_NET_WM_WINDOW_TYPE` for dialogs, causing issues with tiling window managers (DisplayServer regression)
Labels: bug,platform:linuxbsd,topic:porting,confirmed,regression

### Godot version

v4.0.dev.custom_build [69a194f05]

### System information

Linux, x11, nvidia

### Issue description

Many new windows what is created  has `_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL` what creates jarring user experience with Tiling Window Managers. 

I would recommend change `_NET_WM_WINDOW_TYPE(ATOM)` set to `_NET_WM_WINDOW_TYPE_DIALOG` for all dialog windows.

Places where this should be changed to `_NET_WM_WINDOW_TYPE_DIALOG` as I found out in fast testing is:
- Add child
- Instantiate Child Scene
- Open Scene
- Save (When selecting place where to save)
- In right click menu basically all selections creates new dialogs but has `_NET_WM_WINDOW_TYPE` = `NORMAL`.
- Quick Load
- When creating new scene and selecting `Other Node` as base type.

On many applications only main window type is set to `_NET_WM_WINDOW_TYPE_NORMAL` and all others are set to other ones (mostly to `_NET_WM_WINDOW_TYPE_DIALOG`). And this is how most of tiling window managers are coded to handle `_NET_WM_WINDOW_TYPE_DIALOG` as floating window automatically.

Here is one possible fix for this.
```diff --git a/platform/linuxbsd/display_server_x11.cpp b/platform/linuxbsd/display_server_x11.cpp
index 74ec8b6..97f603e 100644
--- a/platform/linuxbsd/display_server_x11.cpp
+++ b/platform/linuxbsd/display_server_x11.cpp
@@ -4179,10 +4179,17 @@ DisplayServerX11::WindowID DisplayServerX11::_create_window(WindowMode p_mode, V
                        if (wt_atom != None && type_atom != None) {
                                XChangeProperty(x11_display, wd.x11_window, wt_atom, XA_ATOM, 32, PropModeReplace, (unsigned char *)&type_atom, 1);
                        }
-               } else {
+               } else if (MAIN_WINDOW_ID == id){
                        Atom type_atom = XInternAtom(x11_display, "_NET_WM_WINDOW_TYPE_NORMAL", False);
                        Atom wt_atom = XInternAtom(x11_display, "_NET_WM_WINDOW_TYPE", False);

+                       if (wt_atom != None && type_atom != None) {
+                               XChangeProperty(x11_display, wd.x11_window, wt_atom, XA_ATOM, 32, PropModeReplace, (unsigned char *)&type_atom, 1);
+                       }
+               } else {
+                       Atom type_atom = XInternAtom(x11_display, "_NET_WM_WINDOW_TYPE_DIALOG", False);
+                       Atom wt_atom = XInternAtom(x11_display, "_NET_WM_WINDOW_TYPE", False);
+
                        if (wt_atom != None && type_atom != None) {
                                XChangeProperty(x11_display, wd.x11_window, wt_atom, XA_ATOM, 32, PropModeReplace, (unsigned char *)&type_atom, 1);
                        }
```

### Steps to reproduce

- Install tiling window manager (For example: QTile)
- Build godot (master)
- Open any dialog window

### Minimal reproduction project

_No response_
Repository: deno
Issue: Built-in error prototypes are printed as "undefined" through Deno.inspect/console.log
Labels: bug,ext/console

All of the built-in error classes, besides `Error`, have `prototype` objects that show as `"undefined"` when logged, ***yet*** they're not *actually* `undefined`!

Example test code:
```js
console.log(
  [
    Error,
    EvalError,
    RangeError,
    ReferenceError,
    SyntaxError,
    TypeError,
    URIError,
    AggregateError,
  ].map((ErrorClass) => ErrorClass.prototype),
);
```

Yet, observe that they're objects:
```js
console.log(
  [
    Error,
    EvalError,
    RangeError,
    ReferenceError,
    SyntaxError,
    TypeError,
    URIError,
    AggregateError,
  ].map((ErrorClass) => typeof ErrorClass.prototype),
);
```

Very misleading, and threw me off while messing with the error prototypes :sweat_smile:
Repository: deno
Issue: `console.log` accesses Proxy interceptors
Labels: suggestion,needs discussion,ext/console

I was using a Proxy instance that conditionally threw upon accessing properties, and when logging the object in Firefox, it was shown correctly; in Deno, the `console.log` implementation accesses the Proxy's object access interceptors, and causes the error to be thrown.

I narrowed this down to simply the following:
```js
const throw_ = () => {
  throw new Error();
};
console.log(
  new Proxy({}, {
    get: throw_,
    has: throw_,
  }),
);
```
Having *either*, `get` or `has` will cause the error to be thrown.
Repository: pytorch
Issue: `torch.ldexp` generated tests fail on call to `torch.mul`
Labels: module: autograd,triaged

See expected failures [in the OpInfo](https://github.com/pytorch/pytorch/pull/68853/files#diff-18a0c3e7cd07089b34760028c387d39de1aa393172f1d5f123692106b3a3d144R9480) for `torch.ldexp`.

`test_variant_consistency_eager`, `test_conj_view`, and `test_neg_view` all encounter the following error:

```
RuntimeError: mul(): functions with out=... arguments don't support automatic differentiation, but one of the arguments requires grad.
```

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: pytorch
Issue: [feature request] torch.argminmax
Labels: feature,triaged

Similar to torch.aminmax, it's sometimes needed to get both argmin and argmax, so computing them in one go would be faster / expressive and elegant. I haven't seen it in other frameworks, but it's also useful (and symmetric to torch.aminmax). Maybe torch.minmax returning both values and indices can also be imagined
Repository: godot
Issue: Tooltips behave identical when Control mouse filter is set to "Pass" or "Stop"
Labels: discussion,topic:gui

### Godot version

3.4.1.rc1

### System information

Win 64, Nvidea 765M

### Issue description

"Stop" and "Ignore" behave exactly like you would expect: The top Control nodes tooltip shows up everwhere if it has "stop" mouse filter, and it does not show up if mouse filter is set to "ignore".

However "Pass" currently just mimics "Spot" behaviour.

I would expect the tooltip from the Control below to show up when the top Control has the "pass" mouse filter and I hover with my mouse over both. If the top Control has "Pass" mouse filter, it should only show up in the region where there is no other Control tooltip below it.

Green Control (top) has set mouse filter to "Pass", but behaves like "Stop":

https://user-images.githubusercontent.com/47016402/143816292-3916572a-abbd-44ce-af13-aa9132b37a7f.mp4

In regions where there is a Control with tooltip below it, imho either both tooltips should show up or just the bottom one.

Very likely directly related to https://github.com/godotengine/godot/issues/55432
Possible similarities to #54529

### Steps to reproduce

1. Add two Control Nodes, and set unique Tooltips for both. Make sure the Controls rects overlap.
2. Set the mouse filter of the top Control to "Pass".
3. Observe how the top Control actually stops the bottom Tooltip from appearing.

### Minimal reproduction project

_No response_
Repository: flutter
Issue: Flutter UIKitView widget wrapped native wkwebview Click event is ignored
Labels: platform-ios,framework,f: gestures,a: platform-views,has reproducible steps,P2,found in release: 2.5,found in release: 2.6,team-ios,triaged-ios

When I use  UiKitView wrap Native WKWebview, Click the button twice quickly
, the second click event works。

The seems like `FlutterTouchInterceptingView`  prevented delivery event of second click event 


this is my demo:
 https://github.com/ammmmmmmmmmmmm/flutter_test_webview.git




<details>
<summary>flutter doctor -v</summary>
[✓] Flutter (Channel stable, 2.5.3, on macOS 11.6 20G165 darwin-x64, locale zh-Hans-CN)
    • Flutter version 2.5.3 at /Users/xuejian/dev/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 18116933e7 (6 weeks ago), 2021-10-15 10:46:35 -0700
    • Engine revision d3ea636dc5
    • Dart version 2.14.4
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/xuejian/Library/Android/sdk
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 13.0, Build version 13A233
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.62.3)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.28.0

[✓] Connected device (3 available)
    • iPhone (mobile) • 00008055-001984DE3C43802E • ios            • iOS 15.1 19B74
    • macOS (desktop)     • macos                     • darwin-x64     • macOS 11.6 20G165 darwin-x64
    • Chrome (web)        • chrome                    • web-javascript • Google Chrome 96.0.4664.55
</details>
Repository: godot
Issue: Control node "Pass" mousefilter is not passing input
Labels: discussion,confirmed,topic:input,topic:gui

### Godot version

3.4.1 rc1

### System information

Win64 Nvidea 765M

### Issue description

Control node "Pass" mouse filter behaves like "Stop".

The white Control has `mouse_enter`, `mouse_exit` and `input_event` signals connected. When the mouse hovers over it, it should turn green:

```
extends ColorRect

func _on_Control_mouse_entered():
	color = Color.green

func _on_Control_mouse_exited():
	color = Color.white

func _on_Control_gui_input(event):
	print(event)
```

However if there is a Control node above with a "Pass" mouse filter, it will stop the input, instead of passing it through.

https://user-images.githubusercontent.com/47016402/143825790-5d9b7234-adbf-472e-a22a-8c37b9c775e1.mp4


Possibly related: 
https://github.com/godotengine/godot/issues/55430
https://github.com/godotengine/godot/issues/54529

### Steps to reproduce

1. Add a Control Node and connect input mouse input signals such as mouse_enter, mouse_exit, input_event to a script.
2. In the script print something or change color when event occurs.
3. Add another Control node, overlapping the first and set it's mouse filter to "Pass"
4. Observe the top Control consuming the input and not passing it on despite being set to "Pass".


### Minimal reproduction project

[control_not_passing_input_issue.zip](https://github.com/godotengine/godot/files/7616299/control_not_passing_input_issue.zip)