sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Emmet with percentage unit does not trigger in CSS-in-JS
Labels: bug,emmet,emmet-parse

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.60.0 (user setup)
- OS Version: Windows_NT x64 10.0.19042

Steps to Reproduce:

1. Create style.js file.
2. Create a CSS class in CSS-in-JS style (see example below).
3. Write `w100p` to inspect the autocomplete suggestion list.

<table>
<tr valign="top">
<td>
<img src="https://user-images.githubusercontent.com/26019822/132638818-afde1847-1016-4796-9567-7a9f76b6c793.gif" alt="CSS in JS" />
</td>
<td>
<img src="https://user-images.githubusercontent.com/26019822/132638835-128aea37-bf93-41a7-959a-bd22ed66be89.gif" alt="Regular CSS" />
</td>
</tr>
<tr>
<td>CSS in JS</td>
<td>Regular CSS</td>
</tr>
</table>


I'm sorry if this is a duplicate, I googled but ended up with no solution being found. How can I have Emmet expand my snippet to `width: 100%;`?
Repository: flutter
Issue: Official Flutter Devcontainer for vscode
Labels: c: new feature,tool,a: first hour,a: quality,c: proposal,P3,team-tool,triaged-tool

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Allow easier adoption of flutter with official Flutter vscode remote container

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Create an official flutter container, and `devcontainer.json` file with the setup needed to start developing flutter apps right away using vscode remote containers https://code.visualstudio.com/docs/remote/containers

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
I am new to mobile development, and to me there is a bit of a barrier to start developing apps, also using Flutter.

When trying out new tech I often go for a devcontainer in vscode as this allows me to very quickly and easily test the tech without having to download and configure lots of stuff. I have seen vscode has an official container to get you started with dart, but there is no official one for Flutter. 

I think making this easier would significantly lower the barrier of just trying and thus possibly also getting more devs over to try and use Flutter. 

With a container plus the `devcontainer.json` handling all the setup one would be able to start developing right away. It might be a bit out of scope for these issues, but I''ll try my luck :)
Repository: tauri
Issue: Custom Mouse Pointer disappearing when contextMenu deactivated
Labels: type: bug,platform: macOS

### **Describe the bug**
I am building a phaser game and I wish to ship it with Tauri.
I have a custom mouse pointer and when I hit a key on the keyboard the mouse disappear until I move it.

### **To Reproduce**
Steps to reproduce the behavior:
1. Add a html page with a custom cursor
```css
* {
    cursor: url(assets/myCursor.cur), pointer;
}
```
2. Prevent display of `contextmenu`
```js
document.body.addEventListener('contextmenu', function (event) {
    event.preventDefault();
    return false;
});
```
3. Hit a key on keyboard
4. See error, mouse pointer disappearing. If you move the mouse and still hit a key you should see it flickering.

### **Expected behavior**
The cursor should stay in place with the custom cursor.  
It works well with standard cursor (ie. no diseappearing)

### **Screenshots**
If applicable, add screenshots to help explain your problem.

### **Platform and Versions (required):**
<!-- Use `yarn tauri info` or `cargo tauri info` command to get this information, and paste it here: -->
```sh

> test@0.0.1 tauri /Users/path/of/my/dev
> tauri "info"

 app:spawn Running "/Users/path/of/my/dev/node_modules/@tauri-apps/cli/bin/tauri-cli tauri info" +0ms


Operating System - Mac OS, version 10.15.7 X64

Node.js environment
  Node.js - 14.17.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 7.21.1
  yarn - Not installed

Rust environment
  rustc - 1.54.0
  cargo - 1.54.0

App directory structure
/dist
/node_modules
/public
/src-tauri
/.git
/.vscode
/.cache
/src

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../dist
  devPath - http://localhost:8000
  framework - React
```
Repository: pytorch
Issue: Enable BatchNorm to use running mean/variance during train
Labels: feature,module: nn,triaged,needs research,module: norms and normalization

## 🚀 Feature

As the title says:
Enable BatchNorm to use running mean/variance during train

## Motivation

There are cases where the mean/variance of one piece of data going through a BatchNorm layer is not representative of the mean/variance of all data it expects to receive, such as the following cases:

1. **Small batch size**: mean/variance calculated from 2 samples will almost always be skewed, yet a small batch size could be necessary depending on the model
2. **Different types of data all go through the same layer instance**: When training some types of model, it becomes necessary to feed different sets of input through the model one-by-one (such as, for example, when using a GAN cycle-type loss where the data stream goes: noise --decoder--> image --encoder--> embedding --decoder--> image2). In these kinds of cases, some BatchNorm layers of such models experience two different distributions with different mean/variance, but will normalize them into the same distribution during train (since the stats of each distribution is taken), while normalizing them differently during eval (due to using the estimated stats of the union of both distribution).

## Pitch

In order of importance as I see it currently, this is what is needed:
1.  Enable BatchNorm to use some form of running mean/variance during train, with an optional argument that can default to preserve current behavior
2.  The stats could be calculated from a sliding window, so that different sets of data can have equal weight (for the case where different sets of data have to go through the same layer within the same batch)
3. Create a convenience function to apply this setting to all batchnorm layers of a network, so that pretrained models built without this consideration can be retrofitted.
4. In train mode, a warning could be raised by BatchNorm if it detects that it has been used more than once before a .backward() pass and this feature is not turned on.

## Alternatives

1. Concatenate all tensors before feeding them into the network. (not always possible)
2. Switch to using another type of norm

## Additional context

I have recreated a minimal case where this issue can be observed in this notebook (I might not keep it public forever on my own google account, please advise on how best to permanently share a jupyter notebook):
https://colab.research.google.com/drive/16heLOdeL61e2_X7BD9Xotv05BG4QKVGF?usp=sharing

You will be able to see that in my extreme setup, the network should theoretically only be able to reach 75% accuracy, but actually performs 100% train accuracy with only 25% val accuracy


cc @albanD @mruberry @jbschlosser @walterddr
Repository: deno
Issue: Support CSS Modules
Labels: suggestion

Chromium is shipping CSS Modules unflagged in v93: https://chromestatus.com/feature/5948572598009856

We should consider how this applies to Deno.

The relevant commit to the HTML Living Spec: https://github.com/whatwg/html/commit/3d45584d286e9455cc24ebae1f3aca3db120dc9d

The biggest challenge is that a constructed [`CSSStyleSheet`](https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet) object is returned on the import which then is inserted into the DOM.  Deno doesn't have a DOM or the `CSSStyleSheet` object, nor is it clear what expectations would be for users and varies greatly from what a front-end bundler would consider a "CSS module".

Personal opinion is that everything is very vague that it really is unimplementable.  (Plus we are also blocked on having import assertions, which are still not supported by tsc)
Repository: go
Issue: encoding/json: add an example for InputOffset() function
Labels: Documentation,NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go go1.16.4 darwin/amd64

</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you expect to see?

Add an example for it.
Repository: flutter
Issue: alwaysUse24HourFormat in MediaQuery should be renamed
Labels: c: new feature,framework,f: material design,a: internationalization,d: api docs,c: proposal,team-design,triaged-design


## Use case

The showTimePicker API accepts a boolean input called alwaysUse24HourFormat that is used to control the input time clock being displayed in 12 hour (am/pm) or 24 hour format.

## Expected behaviour

When time picker is invoked with alwaysUse24HourFormat set to false, the input time clock should "not always have 24 hour format", and therefore should obey the locale (if locale uses 24 hour clock, so should the clock even when alwaysUse24HourFormat=false ).

## Actual behaviour
When time picker is invoked with alwaysUse24HourFormat set to false, the input time clock "always has 12 hour format", regardless of the locale.

## Proposal
Rename alwaysUse24HourFormat to use24HourFormat to avoid confusion. In that way, it is clear that use24HourFormat=false means that 12h format is always used / enforced.

If that is not possible, the current behaviour of alwaysUse24HourFormat should at least be documented.
Repository: pytorch
Issue: Named Tensors to support custom unify functions
Labels: triaged,enhancement,module: named tensor

## 🚀 Feature
Enable custom definition of unify operation over named tensors

## Motivation

Enabling physical quantity units tracking and validation.
For deep logic physics simulations, propagating tensors with physical quantities through some multi step computation can be hard to track.
Given named tesnors with custom unify function, one can implement physical units propagation.  

## Pitch

Physics simulation can get complex. One powerful tool for tracking and validating the logic of some physics computation is by analyzing the units of a given quantity in the computation graph.

If one can sample the computation graph at any point and check the units of a tensor, the development, validation and maintainability of physics simulations will increase significantly.


## Additional context

This idea can be extended so it can also be also useful for tracking other types of information in some computational graph. for example distance from input, distance from some specific operation, etc..


cc @zou3519
Repository: rust
Issue: Could we point out cases of `&'a mut S<'a>` that could be re-written to `&mut S<'a>`?
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,A-suggestion-diagnostics

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4376e96d47d7a35b1858c769744fedef

```rust
struct B<'a> {
    val: &'a str,
}

fn foo<'f>(msg: &'f mut B<'f>) -> String {
    msg.val.to_string()
}

fn main() {
    let s = "hello".to_string();
    let mut b = B{ val: s.as_str() };
    foo(&mut b);
    drop(b);
}
```

The current output is:

```
error[E0505]: cannot move out of `b` because it is borrowed
  --> src/main.rs:13:10
   |
12 |     foo(&mut b);
   |         ------ borrow of `b` occurs here
13 |     drop(b);
   |          ^
   |          |
   |          move out of `b` occurs here
   |          borrow later used here
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0505]: cannot move out of `b` because it is borrowed
  --> src/main.rs:13:10
   |
12 |     foo(&mut b);
   |         ------ borrow of `b` occurs here
13 |     drop(b);
   |          ^
   |          |
   |          move out of `b` occurs here
   |          borrow later used here
note: the borrow of `b` has the lifetime `'a` (from the type `b: B<'a>`), due to the signature of `fn foo`:
    fn foo<'f>(msg: &'f mut B<'f>) -> String
                    ~~~~~~~                    
note: The borrow could choose a different lifetime if the signature of `fn foo` were rewritten to:
    fn foo<'f>(msg: &mut B<'f>) -> String
                    ~~~~
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

**Motivation**: When people are learning Rust, they sometimes do not know the best place to insert explicit lifetimes. We can help them by providing suggestions for ways to modify their code when the functions that need to be changed are local to the crate they are developing. (I do not think this suggestion would be as helpful if it were applied to external crate dependencies.)
Repository: material-ui
Issue: TS Module augmentation for adding variants to components not working
Labels: docs,typescript

It says in the docs here: https://next.material-ui.com/customization/theme-components/, adding a variant to a component when using typescript requires you add this:

```
declare module '@mui/material/Button' {
  export interface ButtonPropsVariantOverrides {
    actionHover: true;
  }
}
```

However, this doesn't work. You'll still get an error in your `createTheme()`:

```
Type '"actionHover"' is not assignable to type '"contained" | "outlined" | "text"'.ts(2322)
Button.d.ts(83, 5): The expected type comes from property 'variant' which is declared here on type 'Partial<ButtonProps<"button", {}>>'
(property) variant?: "text" | "outlined" | "contained"
```

In order to fix this you need to also add the line to your definitions file:

`import '@mui/material/Button';`

I'm not sure why this is the case but this should probably be added to the docs.
Repository: node
Issue: WritableStream leaks a descriptor if it is not ended
Labels: stream

### Version

12-14-16

### Platform

All

### Subsystem

Streams

### What steps will reproduce the bug?

Consider this code:
```js
const axios = require('axios');
const fs = require('fs');
const stream = require('stream');
const { promisify } = require('util');
const streamFinished = promisify(stream.finished);

const dl = axios.create({
	responseType: 'stream'
});

(async () => {
	do {
		console.log('iteration');
		try {
			const writer = fs.createWriteStream('temp');
			const reader = await dl.get('https://www.google.com/give_me_404');
			reader.data.pipe(writer);
			await streamFinished(writer);
		} catch (e) {
			console.log(e.message);
		}
	} while (true);
})();
```

It will leak a descriptor at every iteration. This has nothing to do with `axios` - in fact this is enough to leak:
```js
const fs = require('fs');

do {
	console.log('iteration');
	const writer = fs.createWriteStream('temp');
} while (true);
```

### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior?

Destruction of  `WritableStream` that is not piped (by going out of scope) should free the file descriptor

### What do you see instead?

The problem is that in the first example the only way to not leak a descriptor is:
```js
const axios = require('axios');
const fs = require('fs');
const stream = require('stream');
const { promisify } = require('util');
const streamFinished = promisify(stream.finished);

const dl = axios.create({
	responseType: 'stream'
});

(async () => {
	do {
		console.log('iteration');
                let writer, reader;
		try {
			writer = fs.createWriteStream('temp');
			reader = await dl.get('https://www.google.com/give_me_404');
			reader.data.pipe(writer);
			await streamFinished(writer);
		} catch (e) {
                        try {
                             reader.close();
                        } catch () {}
                        try {
                             writer.close();
                        } catch () {}
			console.log(e.message);
		}
	} while (true);
})();
```

This is the only way to never leak a descriptor and to handle all type of errors that can happen.

### Additional information

_No response_
Repository: pytorch
Issue: Consolidate ProcessGroup allreduce_coalesced and allreduce
Labels: oncall: distributed,module: bootcamp,triaged,better-engineering,module: c10d

## Background

Today, `torch.distributed.all_reduce` and `torch.distributed.all_reduce_coalesced` both have their dedicated C++ operators. See code pointers below. The logic of `all_reduce_coalesced` is simply: 1) flatten tensors before comm, 2) conduct allreduce comm, 3) copy result back to user-provided tensors, where step 2) is the same as `all_reduce` and step 1) and 3) can be easily implemented in Python. The reason that we had two different C++ cores was that, previously, we don't have `torch.futures.Future` and the existing `ProcessGroup::work` does not support chaining callbacks. As a result, there is no easy way to implement step 3) for asynchronous `all_reduce_coalesced` from Python. Today, we can use the `ProcessGroup::Work->getFuture()` API to get a future from the work (see #64722), and chain step 3) there. 

Python `all_reduce`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/distributed/distributed_c10d.py#L1225

Python `all_reduce_coalesced`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/distributed/distributed_c10d.py#L1295

C++ cores for `allreduce` and `allreduce_coalesced`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/csrc/distributed/c10d/ProcessGroup.hpp#L212-L220


## Proposed Change

Implement `all_reduce_coalesced` using `ProcessGroup::allreduce` in the following fashion, and remove `ProcessGroup::allreduce_coalesced` API to simplify the C++ c10d extension API. 

```python
def all_reduce_coalesced(tensors, op=ReduceOp.SUM, group=None, async_op=False):
    # this is pseudo code
    tensor = flatten_tensors(tensors)
    work = default_pg.allreduce([tensor])
    fut = work.get_future().then(copy_values_back_to_input_tensors)
    return fut if async_op else fut.wait()
```


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @cbalioglu @gcramer23
Repository: pytorch
Issue: Consolidate ProcessGroup allgather_coalesced and allgather
Labels: oncall: distributed,module: bootcamp,triaged,better-engineering,module: c10d

## Background

Today, `torch.distributed.all_gather` and `torch.distributed.all_gather_coalesced` both have their dedicated C++ operators. See code pointers below. The logic of `all_gather_coalesced` is simply: 1) flatten tensors before comm, 2) conduct allgather comm, 3) copy result back to user-provided tensors, where step 2) is the same as `all_gather` and step 1) and 3) can be easily implemented in Python. The reason that we had two different C++ cores was that, previously, we don't have `torch.futures.Future` and the existing `ProcessGroup::work` does not support chaining callbacks. As a result, there is no easy way to implement step 3) for asynchronous `all_gather_coalesced` from Python. Today, we can use the `ProcessGroup::Work->getFuture()` API to get a future from the work (see #64722), and chain step 3) there. 

Python `all_gather`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/distributed/distributed_c10d.py#L1940

Python `all_gather_coalesced`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/distributed/distributed_c10d.py#L2075-L2077

C++ cores for `allgather` and `allgather_coalesced`:

https://github.com/pytorch/pytorch/blob/d4b1016850170deba98c026d1c8494de821b91c7/torch/csrc/distributed/c10d/ProcessGroup.hpp#L226-L247


## Proposed Change

Implement `all_gather_coalesced` using `ProcessGroup::allgather` in the following fashion, and remove `ProcessGroup::allgather_coalesced` API to simplify the C++ c10d extension API. 

```python
def all_gather_coalesced(output_tensor_lists, input_tensor_list, group=None, async_op=False):
    # this is pseudo code
    tensor = flatten_tensors(input_tensor_list)
    out_tensors = allocate_out_tensors()
    work = default_pg.allgather(out_tensors, [tensor])
    fut = work.get_future().then(copy_values_to_output_tensor_lists)
    return fut if async_op else fut.wait()
```


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @cbalioglu @gcramer23