sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Add `DartIntegrationTest` annotation to `integration_test`
Labels: team,platform-android,c: proposal,f: integration_test,P3,team-android,triaged-android

See https://github.com/flutter/plugins/pull/4188#discussion_r688608735 (and that PR in general) for context.

The `tl;dr` is that it is useful to be able to annotate Android plugin native tests that are run via `FlutterTestRunner` from those that are just standard (fully native) tests, for test filtering. To facilitate that, it would be great if we could add the following to `integration_test`:

```
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface DartIntegrationTest {}
```

Currently in flutter/plugins we're just duplicating that in every plugin, which isn't ideal.

/cc @bparrishMines
Repository: godot
Issue: KinematicCollision much less accurate in GodotPhysics compared to Bullet
Labels: bug,confirmed,topic:physics,topic:3d

### Godot version

3.4.beta4

### System information

Windows10

### Issue description

Using KinematicCollision to get a Vector between the Player and the KinematicCollision.position seems to be much more accurate in Bullet compared to GodotPhysics.

Going straight left until colliding with a straight wall and using 

`	if collision:
		print(collision.position.direction_to(self.global_transform.origin))	`

returns (0.987696, 0, 0.156385) in Bullet and (0.894458, 0, -0.447152) in GodotPhysics with default values.

You have to increase the Collision.SafeMargin to a very large number to get similar Results in GodotPhysics.

### Steps to reproduce

Download the Project, go left until the wall is hit, switch between Bullet and GodotPhysics.

### Minimal reproduction project

[PhysicsTest.zip](https://github.com/godotengine/godot/files/7108066/PhysicsTest.zip)
Repository: rust
Issue: Spurious E0282 'type annotations needed' when other compile errors exist
Labels: A-diagnostics,T-compiler,A-inference

Given [the following code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=82d48342a112b2808e5acf17961e995f):

```rust
fn troublesome() {
    does_not_exist();
}

fn innocent_bystander() {
    // Approximately what assert_eq! does, inlined for the sake of simplicity
    if "x".as_bytes() != &[] {
        panic!();
    }
}
```

The current output is:

```
   Compiling playground v0.0.1 (/playground)
error[E0425]: cannot find function `does_not_exist` in this scope
 --> src/lib.rs:2:5
  |
2 |     does_not_exist();
  |     ^^^^^^^^^^^^^^ not found in this scope

error[E0282]: type annotations needed
 --> src/lib.rs:7:23
  |
7 |     if "x".as_bytes() != &[] {
  |                       ^^ cannot infer type
```

However, if `does_not_exist();` is commented out, not only does its error E0425 disappear, the type inference error E0282 also does. This results in a frustrating situation where, whenever you have an error of the first sort, any `==`s or `assert_eq!()`s elsewhere in your crate that are fragile in this way also flood the error output. This makes it unnecessarily difficult to practice the workflow of “change something in a breaking way, then fix all the now-erroneous call sites”. It could also mislead beginners because the compiler is confidently stating a falsehood.

Ideally, these “type annotations needed” errors would not appear unless the annotations were _actually needed._ An approximation of this would be to not show them when any other errors appear. An even better approximation, I speculate in ignorance of the compiler internals, would be to not show them if whatever inference pass would have resolved the concrete type is known to have been skipped due to previous errors.

Or, perhaps this code is inherently fraught, and it would be wise for the programmer to actually provide a type annotation. In that case, it would be nice if there was a warning about that when the code compiles successfully.

---

Tested on rustc 1.54.0 stable, also current nightly.

I previously mentioned this problem [in #44345](https://github.com/rust-lang/rust/issues/44345#issuecomment-853517371), but got no response there, and I also now think that this situation is significantly different. In particular, **no trait implementations are being added**, and the error is entirely spurious rather than being a newly-ambiguous trait implementation selection.
Repository: PowerToys
Issue: Distraction Dimmer - Haze Over / dim all but
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

A tool like [HazeOver](https://hazeover.com/) to dim inactive windows, to help reduce distraction and increase focus.

![Example](https://media.idownloadblog.com/wp-content/uploads/2015/06/HazeOver.png)

### Scenario when this would be used?

* Workflow with a lot of context-switching, like switching back and forth between terminal and code editor.
* Big screens, where you have multiple windows opened at the same time.
* Presentations and screen casts.

### Supporting information

I found a windows alternative called [LeDimmer](https://sites.google.com/site/llemarie/ledimmer), but it's abandoned and not open-source. It also lacks a lot of options.
Repository: flutter
Issue: flutter_markdown: Please add example how to use in showDialog
Labels: d: examples,package,team-ecosystem,P3,p: flutter_markdown,triaged-ecosystem

Hi,

could you please add an example how to use **Markdown** or **MarkdownBody** within _showDialog()_. If I use **Markdown** like Text in _showDialog()_ then Flutter throws an exception.

Markdown would be really useful for help texts and other information but not within **Column**!?!

An alternative could be to provide a **MarkdownDialog** in addition to **AlertDialog** which only includes the markdown display and must be dismissed by border tap.
Repository: vscode
Issue: Bracket pair show bracket in gutter editor.bracketPairColorization.showBracketsInGutter
Labels: feature-request,bracket-pair-colorization

<!-- ⚠️⚠️ 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. -->
Love the new feature ❤
```json
"editor.bracketPairColorization.enabled": true, 👌❤
```

### Can we have this small complementary option?
_suggestion name_ ```.showBracketsInGutter```

```json
"editor.bracketPairColorization.showBracketsInGutter": true 👈👀
```

![image](https://user-images.githubusercontent.com/27288406/132083684-91b6fdba-8e5b-4518-aceb-4720d9f29905.png)
Repository: pytorch
Issue: [numpy] torch.nonzero is similar to np.argwhere not np.nonzero
Labels: triaged,module: numpy

```python
import torch
import numpy as np

t = torch.tensor([1, 0, 1, 0])
# t = torch.tensor([[1, 0, 1, 0], [0, 1, 0, 0]])
# t = torch.ones(3, 3, 1)

torch.testing.assert_allclose(torch.nonzero(t), np.argwhere(t.numpy()), rtol=0, atol=0)
torch.testing.assert_allclose(torch.nonzero(t), np.nonzero(t.numpy()), rtol=0, atol=0) # error
```

cc: @mruberry 

cc @mruberry @rgommers @heitorschueroff
Repository: rust
Issue: Diagnostics for unimported `decl_macro`
Labels: A-diagnostics,T-compiler,requires-nightly

Currently the error output for this:
```rust
#![feature(decl_macro)]

mod foo1 {
    pub macro foo() {}
}

mod foo3 {
    fn bar() {
        foo!();
    }
}
```
is
```text
error: cannot find macro `foo` in this scope
 --> src/lib.rs:9:9
  |
9 |         foo!();
  |         ^^^
  |
  = note: consider importing this macro:
          crate::foo1::foo
```
However the "consider importing this macro" part should be
`use crate::foo1::foo;` to be consistent. (Maybe this change should happen only when `decl_macro` feature gate is enabled)
Repository: godot
Issue: `project.godot` is not saved after a plugin is automatically disabled on load due to a script error
Labels: bug,discussion,topic:editor,topic:plugin,needs testing

### Godot version

v3.4.beta4.mono.official [6a058cbf3]

### System information

Debian 11

### Issue description

When I open one project I receive this error:

![image](https://user-images.githubusercontent.com/13235119/132091480-bde41c1b-fa58-4ea7-9a5b-52ed9fa2e612.png)

In project settings I have:

![image](https://user-images.githubusercontent.com/13235119/132091531-ead5924f-bd1b-4a30-860f-2f8340041f58.png)

but in project.godot I have:

![image](https://user-images.githubusercontent.com/13235119/132091573-08c73346-6029-46b6-a72a-e4ba75681fe6.png)

I guess I can delete the "editorsettings" from project.godot manually.. Right? 
After I delete it the editor ask me to act against...


### Steps to reproduce

Happen in one project only. I have same plugin in others but the error is in this one.
Can be a weird bug?

### Minimal reproduction project

NA
Repository: deno
Issue: Introduce a format flag for subcommands
Labels: good first issue,feat,help wanted

 Coverage, test, lint etc have different output formats, adding flags for each isn't scalable.
We should collapse these into a single enum selector, something along the lines of `--format=<name>` for 2.0.

Usage:
```sh
deno test --format=pretty # (default)
deno test --format=terse
deno test --format=json
deno coverage --format=pretty # (default)
deno coverage --format=lcov
deno coverage --format=json
deno lint --format=pretty # default
deno lint --format=json
```
Repository: rust
Issue: Incorrect hint for `decl_macro` import.
Labels: A-diagnostics,T-compiler,requires-nightly

In this program:
```rust
#![feature(decl_macro)]

mod foo1 {
    pub macro foo() {}
}

mod foo2 {
    pub macro bar() {
        foo!();
    }
   
}

mod foo3 {
    fn bar() {
        crate::foo2::bar!();
    }
    use crate::foo1::foo;
}
```
The compilation output is:
```text
error: cannot find macro `foo` in this scope
  --> src/lib.rs:9:9
   |
9  |         foo!();
   |         ^^^
...
16 |         crate::foo2::bar!();
   |         -------------------- in this macro invocation
   |
   = note: consider importing this macro:
           crate::foo3::foo
   = note: this error originates in the macro `crate::foo2::bar` (in Nightly builds, run with -Z macro-backtrace for more info)
```
However the hint is wrong - `crate::foo3::foo` is inaccessible to `foo2`. The correct hint should be suggesting `crate::foo1::foo`.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"FabianWolff"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: TypeScript
Issue: Property 'X' does not exist on type Y
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about "does not exist on type"

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.4.2#code/C4TwDgpgBAMglgZ2BAdhATlAvFA3gKCiKgGMBDAGwoCMySBrACgEoAuKage04ojJQDc+AL5D8JTiiRQAZimxQAPABUoEAB7IUAEwSxEWjAD5GFA6gztlzbEbxRR+fAHpnUYAAtEUAO6d09Aj4cowExKSSyJrsaD5QALJkYIpI6HAoAOYANFAoAK4AttTGLFmExORUtAwseOXhRBJSwLmFCp6IAHRNUcCdGRDAjADk+UUYwzYA-FNQAAxiDcRwMlCMY1B2czbog3no8sDoeRBCS0QQFAjQu8D78jKU12fEwmXCzGKu7l562pwQPQoTjAYIoUL1CIoXoxCBxRLJVLpbKtcboEzMMrhSo0OhMGxhc5NaQbHAdBDdSIaPoDIajQrFdCTKAzeYvJa3e6ozZsyFvESffBAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Listener = {
    callback(): boolean;
};

const fn = <T extends Listener>(listener: T) => { };

// this works
fn({
    context: new Map<string, number>(),
    callback() {
        const num = this.context.get('number') ?? 0;

        if (num > 0) return true;
        else return false;
    },
});

// this does not
fn({
    context: new Map<string, number>(),
    callback() {
        const num = this.context.get('number') ?? 0; // Property 'context' does not exist on type 'Listener'.(2339)
        return num > 0;
    },
});
```

### 🙁 Actual behavior
It is giving a compilation error as soon as I change the return variable.
<!-- What happened, and why it was wrong -->

### 🙂 Expected behavior
Should not give compilation errors.
<!-- What you expected to happen instead, and why -->
Repository: PowerToys
Issue: Remaped keys CTRL+C/V to ALT+C/V insert @copiedString@ into PowerShell 7.1.4 console
Labels: Issue-Bug,Product-Keyboard Shortcut Manager

### Microsoft PowerToys version

0.45.0

### Running as admin

- [X] Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

Beeing a MacOS / MacBook user I'm acustomed to use ALT+C and ALT+V for copy & paste operations.  So I remapped CTRL+C and CTRL+V to ALT+C and ALT+V. While it appears to work with all my other applications, it fails with PowerShell 7.1.4.

Running on Windows 10 21H1 US-English (with a German keyboard, tho, but that shouldn't matter).

### ✔️ Expected Behavior

Copying "LoremIpsum" (without the quotes) from Windows Notepad to the clipboard no matter if using ALT+C or CTRL+C should make it possible to paste the same text into a PowerShell 7.1.4 console with the remapped ALT+V (pointing to CTRL+V).

### ❌ Actual Behavior

Copy "LoremIpsum" from Windows Notepad with either Ctrl+C or ALT+C and paste it into the Psh 7.1.4 console with ALT+V inserts "@LoremIpsum@" (without the quotes). Note the added "@" characters at the beginning and end of the string.

Using CTRL+V to paste into the Psh 7.1.4 console works as expected.

### Other Software

_No response_
Repository: storybook
Issue: Markdown formatting across multiple lines does not render correctly
Labels: bug,addon: docs,block: description,needs triage

**Describe the bug**
When writing markdown in a JSDoc, the emphasis (bold) tags can be written across multiple lines. VSCode detects this and correctly formats the text when previewing the docstring.

Example JSDoc string: 
```
/**
 * This is a string **that has a line of text that when it's really long, will
 * be broken onto a new line**.
 */
```

How it is rendered in Storybook:
![image](https://user-images.githubusercontent.com/12599555/132094196-46434418-e38f-4eac-843c-1f4fbfb6b1bf.png)

How it should render:
![image](https://user-images.githubusercontent.com/12599555/132094214-08bc620a-dd94-4327-8a7a-91eab9b3df00.png)



<!--
**To Reproduce**
Please create a reproduction by running `npx sb@next repro` and following the instructions. Read our [documentation](https://storybook.js.org/docs/react/contribute/how-to-reproduce) to learn more about creating reproductions.
Paste your repository and deployed reproduction here. We prioritize issues with reproductions over those without.
-->

**System**

```
  System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Binaries:
    Node: 14.17.0 - ~/.nvm/versions/node/v14.17.0/bin/node
    Yarn: 1.22.10 - ~/Cytera/code/app/node_modules/.bin/yarn
    npm: 6.14.13 - ~/.nvm/versions/node/v14.17.0/bin/npm
  Browsers:
    Chrome: 93.0.4577.63
    Safari: 14.1.2
  npmPackages:
    @storybook/addon-actions: ^6.3.4 => 6.3.4 
    @storybook/addon-essentials: ^6.3.4 => 6.3.4 
    @storybook/addon-links: ^6.3.4 => 6.3.4 
    @storybook/node-logger: ^6.3.4 => 6.3.4 
    @storybook/preset-create-react-app: ^3.2.0 => 3.2.0 
    @storybook/react: ^6.3.4 => 6.3.4 
```
Repository: create-react-app
Issue: remove ie9 stuff
Labels: issue: proposal,needs triage

- ie9 is pretty much dead already?
- time to put it at rest?
- remove stuff like 
https://github.com/facebook/create-react-app/blob/bb64e31a81eb12d688c14713dce812143688750a/packages/react-app-polyfill/ie9.js and https://github.com/facebook/create-react-app/blob/bb64e31a81eb12d688c14713dce812143688750a/packages/react-app-polyfill/package.json#L27
Repository: rust
Issue: confusable_idents lint should cover lifetime annotations
Labels: A-lints,A-diagnostics,T-compiler,L-confusable_idents

Confusable identifiers for variables and types elicits a warning from the compiler:

```rust
pub fn types<p, ρ>(_: p) -> ρ { unimplemented!() }
```

```none
warning: identifier pair considered confusable between `p` and `ρ`
 --> src/lib.rs:1:17
  |
1 | pub fn types<p, ρ>(_: p) -> ρ { unimplemented!() }
  |              -  ^
  |              |
  |              this is where the previous identifier occurred
  |
  = note: `#[warn(confusable_idents)]` on by default
```

But do not for lifetime parameters:

```rust
pub fn lifetimes<'p, 'ρ, T>(_: &'p T) -> &'ρ T { unimplemented!() }
```

Ideally, the compiler would emit a similar warning here.

Additionally, the case where a type or variable identifier starts with an apostrophe confusable (i.e. `ʻa`) should similarly clash with the typical lifetime parameter (i.e. `'a`). Originally sourced from this Reddit post: [An evil type signature](https://www.reddit.com/r/rust/comments/pfd15h/an_evil_type_signature/).

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: node
Issue: Readable._construct behaviour contradicts docs
Labels: doc,stream

### Version

v16.8.0

### Platform

Microsoft Windows NT 10.0.19043.0 x64

### Subsystem

stream

### What steps will reproduce the bug?

Returning a promise from `Readable._construct` has the same effect as calling the callback. This is not documented and may be a bug?

This leads to the following strange behaviour:
```js
const {Readable} = require('stream');

const stream = new Readable({
    async construct(callback) {
        callback();
    },
    read(size) {
        console.log('read', size);
    },
    destroy(err, callback) {
        console.log('destroy', err);
    }
});
```
Output:
```
destroy Error [ERR_MULTIPLE_CALLBACK]: Callback called multiple times
    at new NodeError (node:internal/errors:371:5)
    at onConstruct (node:internal/streams/destroy:255:37)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  code: 'ERR_MULTIPLE_CALLBACK'
}
```

Similarly:
```js
const {Readable} = require('stream');

const stream = new Readable({
    async construct(callback) {
        // don't call the callback
    },
    read(size) {
        console.log('read');
    }
});

stream.read();
```
Output:
```
read
```

### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior?

Flow should not proceed to `Readable._read` until after the callback passed to `Readble._construct` has been called.

[The docs](https://nodejs.org/dist/latest-v16.x/docs/api/stream.html#stream_readable_construct_callback) state:
> This optional function will be scheduled in the next tick by the stream constructor, delaying any _read() and _destroy() calls until callback is called.

### What do you see instead?

* In the first example, an error is thrown for calling the callback twice (despite only calling it once)
* In the second example, flow passes to `Readable._read` despite the callback not being called yet.

### Additional information

It is desirable to be able to be able to use `await` within `Readable._construct`, but labelling this function as `async` (and therefore returning a Promise) appears to cause the `callback` function to be implicitly called (which is sometimes unwanted).

As a workaround, I can return my own Promise from `Readable._construct` and use its resolve/reject functions in lieu of the callback.

In summary, either this is expected behaviour and the docs are incorrect - or vice versa.  It's hard to tell.
Repository: pytorch
Issue: Return attention weights in nn.Transformer
Labels: feature,module: nn,triaged

## 🚀 Feature

Currently, nn.Transformer and related modules return only outputs. I suggest returning attention weights as well.

## Motivation

For all purposes -- demos, tutorials, and practical applications it's very useful to visualize attention weights, for model interpretation and debugging. Also, it would be easier to integrate with explanation/visualization tools like Captum.

## Pitch

Encoder and decoder forward methods would return  tuples of (output, attentions), where  attentions are dictionaries of attention weights, saved per all layers
nn.Transformer would integrate all returned attentions and also return a tuple (output, attentions).

## Additional context

Depends on #34537 for returning non-averaged attentions, but can start with returning avreaged.

An example of the implementation (only for encoder in this case):
https://buomsoo-kim.github.io/attention/2020/04/27/Attention-mechanism-21.md/
Captum tutorial that includes attention visualization:
https://captum.ai/tutorials/Bert_SQUAD_Interpret2
Another example:
http://nlp.seas.harvard.edu/2018/04/03/attention.html#attention-visualization

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch