sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Content Security Policy failure caused by is-generator-function dependency
Labels: bug

### What version of Next.js are you using?

10.1.2

### What version of Node.js are you using?

15.12.0

### What browser are you using?

Firefox

### What operating system are you using?

macOS

### How are you deploying your application?

Other

### Describe the Bug

"Content Security Policy: The page’s settings blocked the loading of a resource at eval (“script-src”)."

Caused by `is-generator-function`.

Output of `npm why is-generator-function`:

```
is-generator-function@1.0.8
node_modules/is-generator-function
  is-generator-function@"^1.0.7" from util@0.12.3
  node_modules/util
    util@"^0.12.0" from assert@2.0.0
    node_modules/assert
      assert@"2.0.0" from next@10.1.2
      node_modules/next
        next@"^10.1.2" from the root project
    util@"0.12.3" from next@10.1.2
    node_modules/next
      next@"^10.1.2" from the root project
```

### Expected Behavior

No CSP warnings.

### To Reproduce

When this code is run by next.js in Firefox, the warnings appears:

```js
	try {
		return Function('return function*() {}')();
	} catch (e) {
	}
```

It isn't clear what causes this to run, but you can see it in action in our app https://wormhole.app
Repository: PowerToys
Issue: FancyZones - Support for quick profile Layout template apply from systray icon options or right click on taskbar entry to support quick changes based on use case
Labels: Idea-Enhancement,Product-FancyZones

While working from home I would like to be able to change my applied monitor profile based on whether I am in "productivity mode" or "meeting mode" etc.  To support this use case I have different  layouts that I apply depending on whether I'm coding / attending a meeting etc.  

Currently:

- I have to dive into settings -> click Fancy zones -> lauch layout editor -> select monitor -> apply template

Desired Behavior:
1. Click FancyZones Systray Icon -> Select Montor (1,2 etc.) -> click profiles to apply to the monitor 

or 

2. right click fancy zones entry in task bar (assuming its been loaded) and have options available to quick apply a profile without having to go into settings.


#2 solution implies that you are already running fancyzones, so I think #1 would be preffered as it has less friction for entry point given that fancy zones entry will always be in the system tray.


Thanks Team for improving my home work setup !
-Chris

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: [JIT][Testing] Replace use of `assertRaisesRegex` with `assertRaisesRegexWithHilight`
Labels: oncall: jit

## Pitch

Source range highlighting is critical to having actionable message. A well-written error message can be extremely confusing when incorrect portion of source code is highlighted. One recent example I have seen:

```
a = foo(b, c)
      ~~~~~~

Expecting type T1 while getting T2
```

This error message is misleading because it highlighted only the RHS of assignment, which happens to be a function call with arguments that can have type mismatch errors, while the actual issue is the left side of assignment has incorrect type.

What made the problem worse is that in most of our unit tests, only the error message itself is checked while the source range is not. 

`assertRaisesRegexWithHighlight` [[link](https://github.com/pytorch/pytorch/blob/8a170fbacd72359b51828c2cb07dabc7e8b6a3df/torch/testing/_internal/jit_utils.py#L374)] was added a while ago to address this issue. It does all the same check as `assertRaisesRegex` and also verifies that correct part of source code is highlighted. Unfortunately, adopting it means rewriting many existing unit tests, therefore it is not yet widely used.

I propose:

- We should pay the one-time cost of rewriting unit tests by replacing `assertRaisesRegex` with `assertRaisesRegexWithHighlight`
- Mark `assertRaisesRegex` as deprecated when rewriting is done so that future unit test writers would use the right utility.



cc @gmagogsfm
Repository: pytorch
Issue: [JIT][Testing] Split up test_jit.py and test_jit_py3.jit
Labels: oncall: jit,triaged

## 🚀 Feature
These test files are huge and unwieldy. We should split them up into more manageable pieces (like we have started to do in `test/jit/...`.

## Motivation
The test files are huge.

## Pitch
Let's move individual tests into other files already in `test/jit` or create new ones for them, as appropriate.


cc @gmagogsfm
Repository: TypeScript
Issue: "Holey" behavior on differently-typed getter/setter properties
Labels: Suggestion,In Discussion

I was asked to provide an example of separate read/write types that doesn't necessarily use classes, and here's what I ended up finding. 😅

Take the following:

```ts
interface Thing {
    get name(): string
    set name(value: string | null | undefined);
}

function makeThing(): Thing {
    let name = "";
    return {
        get name() {
            return name;
        },
        set name(value) {
            name = value.toString();
        }
    }
}
```

In this example, you might think that you're writing type-safe code, but in fact you've got a bug. Our `get`/`set` accessors don't have type annotations, so TypeScript assumes the `name` setter has the type `string`. Because only the reading type of the `name` property is validated against `Thing`, TypeScript thinks that the given object conforms to the type `Thing`; however, a user can pass write a `null` or `undefined`, and a user won't know that they haven't handled it correctly.

This was one of the known tradeoffs when we implemented this feature - we acknowledged this. But I hit this surprisingly quickly. It seems like if you're using this pattern without classes, it's pretty easy to run into this issue.
Repository: storybook
Issue: argTypes mapping doesn't work with Vue props
Labels: question / support,vue,has workaround,addon: controls

**Describe the bug**
When using the new `mapping` feature for an argType that corresponds to a prop of a Vue component, the mapping is applied to the value that is passed to `args`, but is not applied to the value of the prop that is passed to the component.

**To Reproduce**
Steps to reproduce the behavior:

1. Create a story for a Vue component, with automatic prop detection (using the docs addon)
1. For one of the props, add an entry to the story's argTypes that includes `options` and `mapping` keys
1. Open the story in the browser, and change the value of this prop back and forth

**Expected behavior**
The mapping should be applied to the value of the prop, but it's not.

**Code snippets**

```ts
import MyButton from './Button.vue`;
import Vue from 'vue';
import { Args, StoryContext } from '@storybook/addons';

export default {
	title: 'Components/Button',
	component: MyButton,
	argTypes: {
		label: {
			options: [ 'short', 'medium', 'long' ],
			mapping: {
				short: 'Short',
				medium: 'Medium text',
				long: 'Very long text that is meant to demonstrate how the button wraps text'
			},
			defaultValue: 'short',
			control: 'inline-radio'
		}
	}
};

export const SimpleStory = ( _args: Args, { argTypes } : StoryContext ) : Vue.Component =>
	Vue.extend( {
		components: { MyButton },
		props: Object.keys( argTypes ),
		template: `<my-button v-bind="$props" />`
	} );
```

With this snippet, I expect the label of the button to change between `Short`, `Medium text` and `Very long text that...` (the mapped values) when the user clicks the radio buttons in the controls panel. Instead, the label of the button changes between `short`, `medium` and `long` (the unmapped values).

Interestingly, if you put `console.log( _args.label )` somewhere (either in the arrow function above `Vue.extend`, or in a `mounted` lifecycle hook), it prints `Short`, indicating that the values in `_args` are mapped correctly. That mapping just isn't applied to the props that are passed to the Vue component.

(I'm using Vue 2 here, I haven't tested this with Vue 3.)

**System**

```
$ npx sb@next info

Environment Info:

  System:
    OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    npm: 7.6.0 - ~/.nvm/versions/node/v14.16.0/bin/npm
  Browsers:
    Chrome: 89.0.4389.90
    Firefox: 87.0
  npmPackages:
    @storybook/addon-a11y: 6.2.1 => 6.2.1 
    @storybook/addon-actions: 6.2.1 => 6.2.1 
    @storybook/addon-backgrounds: 6.2.1 => 6.2.1 
    @storybook/addon-controls: 6.2.1 => 6.2.1 
    @storybook/addon-docs: 6.2.1 => 6.2.1 
    @storybook/addon-links: 6.2.1 => 6.2.1 
    @storybook/addon-storysource: 6.2.1 => 6.2.1 
    @storybook/addon-viewport: 6.2.1 => 6.2.1 
    @storybook/vue: 6.2.1 => 6.2.1 
```



┆Issue is synchronized with this [Asana task](https://app.asana.com/0/1199622255231368/1200139911146422) by [Unito](https://www.unito.io)
Repository: pytorch
Issue: Make it possible to skip only one hop of __torch_function__ override
Labels: triaged,module: __torch_function__

@rgommers @hameerabbasi and I have argued about whether or not DisableTorchFunction should be public API or not. Despite being undocumented and unsupported, there have been a few uses of it in the wild https://github.com/search?l=Python&q=disabletorchfunction&type=Code mostly for when people want to delegate to an underlying implementation.

I want to float an alternative idea for how to expose DisableTorchFunction in a user friendly way, and it stems from thinking about the following situation. Suppose you have a Python program that looks like this:

```
def foo(self):
    if has_torch_function_unary(self):
        return handle_torch_function(foo, (self,), self)
    return bar(self) + bar(self)

def bar(self):
    if has_torch_function_unary(self):
        return handle_torch_function(bar, (self,), self)
    return torch.built_in(self) * 2
```

Today, if I define a torch function, calling foo always shunts me off to the torch function. I cannot choose to *partially delegate* the implementation of foo in terms of my implementation of bar; if I re-call the passed in foo on torch function, I'll infinite loop; if I use DisableTorchFunction, I completely disable torch function handling (and just rely on the intrinsic meaning of tensor computation).  What I'd like to do is disable torch function handling *only* for foo.

This isn't really possible to do in the way we write has torch function today. But a small modification would work:

```
    if has_torch_function_unary(foo, self):
...
    if has_torch_function_unary(bar, self):
```

This would allow the has_torch_function to then selectively return false if a torch function advertised that it didn't have support for foo. Although we could do this by adding `__has_torch_function__` magic method, it might just be simpler and more obvious if we let `DisableTorchFunction(op)` take an operator (and then have `has_torch_function` query it).  The set shouldn't be too large so it should be a few pointer comparisons in the common case.

The main deal is if we do this, we'll have to update all the `has_torch_function` call sites again. We've done it before, we can probably do it again.

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @anjali411 @hameerabbasi @rgommers @peterbell10
Repository: pytorch
Issue: Python dispatch key and backend fallback
Labels: triaged,module: __torch_function__

Today, `__torch_function__` exists purely as a concept in the Python binding layer. One downside of this is that composite implementations in C++ are inaccessible to torch function clients (e.g., FX); this includes aliasing and default arguments, which have previously been discussed in #45565. This proposal is to make it possible to call into `__torch_function__` from the C++ dispatcher, by way of the Python dispatch key.

Here's how it would work:

* We define a new dispatch key, Python, which represents Tensors whose backend implementation lives in Python. This dispatch key would be ordered with other backends (e.g., CPU, Meta)
* Subclasses of Tensor (via `make_subclass`) get tagged with this dispatch key. These tensors are guaranteed to have `pyobj_` set.
* Unlike other custom backend dispatch keys, the Python key only has a single backend fallback implementation. This implementation takes all of the C++ arguments and reboxes them into Python, and then calls into `__torch_function__` on them (unless torch function is disabled, in which case we fall through to the underlying implementation). The reboxing to Python is via the proposed infrastructure at https://github.com/pytorch/pytorch/issues/45565#issuecomment-766897075 ; the translation from JIT operator schema to Python binding must be done by some other layer (hopefully not too hard to do, since we programatically generate Python bindings for most JIT schema functions)
* A bell and whistle would be to make this work for things that are not actually subclasses of Tensor (maybe expose some sort of OpaqueTensor Python class binding that guarantees not having any data associated with it, and just requires you to specify all of the necessary Tensor data)

Combined with selective torch function disabling (proposed in #55093), this would also solve #45565, as operators you needed to be canonicalized you would simply delegate to the C++ dispatcher layer (but anything that you didn't want canonicalized, you still have the option of overriding at the higher level).

cc @hameerabbasi @rgommers @peterbell10 @jamesr66a @Chillee @ailzhang @smessmer
Repository: pytorch
Issue: Alternative backend fallback like mechanism which has higher precedence than operator-specific composite implementations
Labels: module: internals,triaged

Today, composite registrations for an operator always take precedence over backend fallback. This makes it difficult to register a backend fallback where you also want to override a composite (you would have to do an actual operator specific registration). In some potential use cases, e.g., #55095, this makes it impossible to do a higher level override of the composite (because the backend fallback is the *only* mechanism by which users can do the override). 

What would help in this situation is an alternative to backend fallback that has torch function style semantics: it overrides everything, including composites, and it's up to the backend implementor to choose to fall back to the composite implementation if they want it. This fall back mechanism also doesn't exist, but logically it would make sense to have a backup kernel registered in OperatorEntry that you could invoke from the backend fallback (I don't think we need this for unboxed kernels, as they can only be written for specific functions, so you can just hardcode where you need to go).

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang
Repository: TypeScript
Issue: Expected token errors should display all expected tokens, not just the first
Labels: Help Wanted,Effort: Moderate,Experience Enhancement

### 🕗 Version & Regression Information

Pretty sure this has been the behaviour since the rewrite.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ssl=2&ssc=25&pln=1&pc=1#code/AQMwrgdgxgLglgewsAhgBgBQG0UBpgBG+WWUAuhQFzBYRgC2BApgE752Ov4DOMLcEAOZYyIsgEpgAb2ABfAFCpMWAIz4ATMSwAiAO4IWAGwAm2iuIDcQA)

### 💻 Code
```ts
function a0([a, b, [[c]]]: [number, number, string[][]]) { }
a0([1, 2, [["world"]]);
```

### 🙁 Actual behavior

On the last `)`, "Expected ','."

### 🙂 Expected behavior

On the last `)`, "Expected ',' or ']'."

Right now the parser only shows the first error that starts at each location. This is an OK approach, especially when parsing has gone badly wrong, but often the parser will expect multiple tokens. The parser should report all the tokens in one error that were previously issued as multiple Expected_0 errors.
Repository: vscode
Issue: dragging tabs to remote-ssh teminal window pastes paths with backslashes
Labels: bug,label-provider

Issue Type: <b>Bug</b>

When using remote-ssh (Windows->linux), if you drag an editor's window tab into the terminal window it pastes the filename into the terminal (👍), but the path separators are backslashes (👎).

VS Code version: Code 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8, 2021-03-15T10:55:45.459Z)
OS version: Windows_NT x64 10.0.19042
Remote OS version: Linux x64 5.4.72-microsoft-standard-WSL2
Remote OS version: Linux x64 3.10.0-957.1.3.el7.x86_64
Remote OS version: Linux x64 5.4.72-microsoft-standard-WSL2

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>protected_video_decode: enabled<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|47.66GB (8.94GB free)|
|Process Argv|--crash-reporter-id 70645636-42ae-4864-b371-1810b42a2956|
|Screen Reader|no|
|VM|24%|

|Item|Value|
|---|---|
|Remote|WSL: CentOS7|
|OS|Linux x64 5.4.72-microsoft-standard-WSL2|
|CPUs|Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904)|
|Memory (System)|37.35GB (15.48GB free)|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: dev9.corp.grid-net.com|
|OS|Linux x64 3.10.0-957.1.3.el7.x86_64|
|CPUs|Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz (2 x 2299)|
|Memory (System)|3.70GB (1.04GB free)|
|VM|0%|

|Item|Value|
|---|---|
|Remote|WSL: CentOS7|
|OS|Linux x64 5.4.72-microsoft-standard-WSL2|
|CPUs|Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 x 2904)|
|Memory (System)|37.35GB (15.48GB free)|
|VM|0%|
</details><details><summary>Extensions (10)</summary>

Extension|Author (truncated)|Version
---|---|---
remote-ssh|ms-|0.65.1
remote-ssh-edit|ms-|0.65.1
remote-wsl|ms-|0.54.6
gitlens|eam|11.3.0
php-debug|fel|1.14.12
autoscrolldown|fox|1.1.1
svn-scm|joh|2.13.5
cpptools|ms-|1.2.2
edit-with-shell|ryu|1.2.0
plsql-language|xyz|1.8.2


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt700cf:30270857
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vstry914:30276682
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt875:30259475
pythontbcf:30265426
pythonvspyt943:30280189
wslfolderdoccf:30282075
vspre833cf:30267465
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820cf:30276953

```

</details>

<!-- generated by issue reporter -->
Repository: flutter
Issue:  [webview_flutter] Add support for pdf generation of webview content
Labels: c: new feature,platform-ios,p: webview,package,c: proposal,P3,team-ios,triaged-ios

In my opinion this is a very necessary function for the development of many applications.
Repository: flutter
Issue: integration_test library has no top-level documentation
Labels: framework,d: api docs,f: integration_test,P2,team-framework,triaged-framework

This should have many paragraphs explaining how to use the library:
https://master-api.flutter.dev/flutter/package-integration_test_integration_test/package-integration_test_integration_test-library.html
Repository: transformers
Issue: ReduceLROnPlateau-like functionality?
Labels: Feature request

# 🚀 Feature request

<!-- A clear and concise description of the feature proposal.
     Please provide a link to the paper and code in case they exist. -->

**Description:** Dynamic learning rate reduction upon metric saturation, as in `torch.optim.lr_scheduler.ReduceLROnPlateau`, integrated into the `Trainer` API.

Alternately, if there's any way (if hacky) to get dynamic learning rate reduction using the `Trainer` API as it is, that would be extremely helpful as well.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request
     related to a problem? e.g., I'm always frustrated when [...]. If this is related
     to another GitHub issue, please link here too. -->

LR schedules are a commonly used trick for ML optimization, and the `transformers` library already provides a significant number of baseline schedules (i.e. linear, cosine schedulers, warmup/no-warmup, restarts). However, these schedules are all static: updates to them occur at fixed steps in the optimization -- one can always tell what the learning rate at, say, step 1000 will be given these fixed schedules.

Reducing learning rate dynamically is also a common practical technique, usually applied when loss saturates (fails to improve after N iterations).

The difficulty is that dynamic learning rate reduction follows a non-fixed update schedule, meaning that working within the `LambdaLR` framework used by the other scheduler is less straightforward.

## Your contribution

I don't have a working implementation yet. At a high level, I tried to implement this myself as a `TrainerCallback` modeled on both the `EarlyStoppingCallback` in the `transformers` library as well as the `ReduceLROnPlateau` implementation in PyTorch. I was able to modify the optimizer object; however, learning rate updates to the optimizer would get overwritten by the scheduler. In any case, I also don't know if it's good style/even possible to modify the optimizer and scheduler in this way using a Callback -- seems like the `control` object is the only thing that changes within a `TrainerCallback`.

<!-- Is there any way that you could help, e.g. by submitting a PR?
     Make sure to read the CONTRIBUTING.MD readme:
     https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md -->
Repository: TypeScript
Issue: No auto-complete for things in `@link` tags
Labels: Suggestion,Experience Enhancement

```ts
/**
 * This function depends on {@link $}
 */
function foo() {

}

function bar() {

}
```

**Expected:** Completions of locally-accessible things, or things in other modules that are completed with `import("...")` paths.
**Actual:** No completions
Repository: flutter
Issue: ExpansionTile + TextField => undesirable behavior when backspace 
Labels: a: text input,framework,f: material design,f: focus,has reproducible steps,found in release: 2.1,team-design,triaged-design


Combining TextField + ExpansionTile (standalone or in a ListView)
<details>
  <summary>Code</summary>


```dart
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: LandPage(),
    );
  }
}

class LandPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text("Title"),
      ),
      body: Column(
        children: [
          Text("In android: Type <backspace>."),
          Text("In Web (DartPad): Tap for focus."),
          Text("The Tile becomes grey as if selected."),
          ExpansionTile(
            leading: SizedBox(),
            title: TextField(),
            children:<Widget>[Text("Empty")]
          ),
          SizedBox(height: 60.0,),
          Text("ListTile: No problem"),
          ListTile(title: TextField(),),
        ],
      ),
    );
  }
}

```
</details>

Running in Android:
1. Type a Backspace on the empty textfield inside ExpansionTile (tested with soft-keyboard)
2. The Tile turns grey as if selected
3. Tested with Channel dev, 2.1.0-12.1.pre

Running in Web:
1. Requesting the focus turns the tile grey
2. Tested in dartPad and locally with 2.1.0-12.1.pre

This issue looks similar to #63722 (marked as duplicate from #47156) 
but triggered differently.
Both issues are marked closed.