sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Event viewer update
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

Event viewer is a super powerful tool and has a ton of bells and whistles

Imagine what a next generation event viewer could do and improve your workflows.  Be able to quickly create filters for instance

### Scenario when this would be used?

Any time you're trying to see errors that have thrown

### Supporting information

_No response_
Repository: flutter
Issue: Clarify ButtonThemeData usage and documentation
Labels: framework,f: material design,d: api docs,a: quality,a: annoyance,P2,team-design,triaged-design

Feedback from @rydmike in https://github.com/flutter/flutter/issues/98537#issuecomment-1042524899


## ButtonThemeData

The `ButtonThemeData` class is marked as obsolete in the docs, but not as deprecated.

In its theme `ButtonTheme`:
https://github.com/flutter/flutter/blob/adafd66d9cc7796214404c8117395e207bf23d01/packages/flutter/lib/src/material/button_theme.dart#L53

And in its theme data `ButtonThemeData`:
https://github.com/flutter/flutter/blob/adafd66d9cc7796214404c8117395e207bf23d01/packages/flutter/lib/src/material/button_theme.dart#L170

In addition to the buttons that will be removed [FlatButton, OutlineButton, RaisedButton], the theme and theme data is used by the buttons' parent class `MaterialButton` and the `ButtonBar` and its theme `ButtonBarTheme`, plus as far I could notice `DropdownButton` uses one property from it as well.

Instead of having the docs above mention that it is used by buttons that will no longer exist, maybe consider updating the doc comment and instead mention the usage by `ButtonBar`, `DropdownButton` and `MaterialButton`, if it will remain. It kind of will have to, but more on that below.

Perhaps for the update also consider updating the doc comment for the `buttonTheme` property in `ThemeData` to better reflects its remaining usage in `ButtonBar`, `DropdownButton` and `MaterialButton`

**Some of these doc updates will be completed in the course of resolving #98537**

https://github.com/flutter/flutter/blob/adafd66d9cc7796214404c8117395e207bf23d01/packages/flutter/lib/src/material/theme_data.dart#L1322

---

In general, I think the current use case is unclear to users, `obsolete` is not deprecated, but it's not really `obsolete` either if other parts of the framework still use ButtonThemeData. There is definitely some opportunity for better clarity and guidance here - even if that is just to say we plan to make more changes in the future that will eventually remove this class.

cc @HansMuller @darrenaustin
Repository: flutter
Issue: Clarify MaterialButton usage and documentation
Labels: framework,f: material design,d: api docs,a: quality,a: annoyance,P2,team-design,triaged-design

From @rydmike in https://github.com/flutter/flutter/issues/98537#issuecomment-1042524899

## MaterialButton

Next comes the question of the fate of the `MaterialButton` the parent class for the buttons to be removed.

It is also in the docs marked as **obsolete** but not deprecated. 

https://github.com/flutter/flutter/blob/adafd66d9cc7796214404c8117395e207bf23d01/packages/flutter/lib/src/material/material_button.dart#L22

Will it remain available or be removed? My conclusion is, it will stay, even if it does not correctly implement or enable users to create Material buttons, plus its children will be gone due to same reasons. Considering this, it seems a bit illogical for it to remain, but it would be difficult to remove without a number of other changes discussed further below.

My search did no reveal any other usages and mentions of `MaterialButton` than in its child buttons that will be removed, and in `ButtonThemeData` itself, in a large number of odd looking getters.

<br>

> Removed quoted section here as a separate issue: https://github.com/flutter/flutter/issues/98692

<br>

The fact that `ButtonThemeData`, that needs to remain for `ButtonBar` and `DropdownButton`, itself depends on `MaterialButton`, also makes it impossible to remove the "obsolete" `MaterialButton` parent of all the 3 buttons now being removed.

In `Material` there is in the `MaterialType` enum a doc comment to `MaterialButton` in enum value `button`. 
https://github.com/flutter/flutter/blob/8a6d0d62f3257e74e2850e68bd97b98877c78e2e/packages/flutter/lib/src/material/material.dart#L35

So I checked for references to `MaterialType.button`, other than in `Material` it is only used by `RawMatererialButton` and `ButtonStyleButton`. maybe consider updating the above doc ref to them instead of `MaterialButton`.

If the `MaterialButton` is considered and marked as **obsolete** in the docs, which imo is correct, thus maybe consider deprecating it and plan for changes need to be able to remove it.


---

Similar to #98691, `obsolete` is not a term folks know what to do with. What does it mean when other parts of the framework still depend on it? Some guidance would be helpful to add. cc @HansMuller & @darrenaustin
Repository: flutter
Issue: ButtonBar uses two different theme classes
Labels: framework,f: material design,a: quality,a: annoyance,P2,team-design,triaged-design

From @rydmike in https://github.com/flutter/flutter/issues/98537#issuecomment-1042524899 discussing obsolete button theming

## ButtonBar

Since `ButtonBar` uses the `ButtonThemeData` and it is still a component with a "kind of" legit claim to do so, then `ButtonThemeData` does indeed need to remain for it to work.

The setup with `ButtonBar` using two different component themes `ButtonThemeData` and `ButtonBarThemeData` with the later overriding 6 properties, if defined in "parent" `ButtonThemeData` plus having 3 extra properties, and using some others from the 1st one too, "may" be a bit confusing for users trying to style it with the component themes.

> I used a similar approach with custom themes for custom components. It was confusing to users to have two partially overlapping themes used in similar manner for effective result. I ended up simplifying it by just using one component theme per component. In retrospect I was just being lazy and reusing props from another kind of "parent" component theme, instead of defining them separately also in the other similar component. The refactored version ended up being cleaner by keeping the theme concerns separated.

Later on, maybe consider deprecating the properties `ButtonBar` uses in `ButtonThemeData` and provide replacements in `ButtonBarThemeData`, it would imo be simpler and cleaner to use it then.

---

Work along these lines may already be planned, not sure. @HansMuller and @darrenaustin may know. :)
Repository: flutter
Issue: Add DropdownButtonTheme/Data
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

From @rydmike in https://github.com/flutter/flutter/issues/98537#issuecomment-1042524899

## DropdownButton

Lastly, and yes I did not see it first, you were right, the Dropdown button also uses `ButtonThemeData`, but apparently only one property from it: `ButtonTheme.of(context).alignedDropdown`, twice, here:

https://github.com/flutter/flutter/blob/8d25ddde1937edcf391decf7bda336c5a14d846c/packages/flutter/lib/src/material/dropdown.dart#L1266

and here

https://github.com/flutter/flutter/blob/8d25ddde1937edcf391decf7bda336c5a14d846c/packages/flutter/lib/src/material/dropdown.dart#L1405

So there is indeed that too. Maybe later consider if `DropdownButton` should get its own component theme as well one day. It could then have some more and independent styling capabilities too.

---

cc @HansMuller & @darrenaustin
Repository: pytorch
Issue: Is it intentional that PyTorch linux binaries aren't manylinux1 compliant?
Labels: module: binaries,triaged

### 🐛 Describe the bug

I might just be reading the output wrong, but the last sentence "This constrains the platform tag to "manylinux_2_17_x86_64" seems to suggest that the binary isn't manylinux1 compatible?
```
(/raid/rzou/pt/quick-env) [2] rzou@devfair0317:~/binaries_test  $ auditwheel show torch-1.10.2-cp39-cp39-manylinux1_x86_64.whl

torch-1.10.2-cp39-cp39-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".

The wheel references external versioned symbols in these
system-provided shared libraries: librt.so.1 with versions
{'GLIBC_2.2.5'}, libgcc_s.so.1 with versions {'GCC_4.2.0', 'GCC_3.0',
'GCC_3.3', 'GCC_3.4'}, libdl.so.2 with versions {'GLIBC_2.2.5',
'GLIBC_2.3.3'}, libgomp-a34b3233.so.1 with versions {'OMP_1.0',
'GOMP_1.0', 'GOMP_4.0'}, libm.so.6 with versions {'GLIBC_2.2.5'},
libpthread.so.0 with versions {'GLIBC_2.3.4', 'GLIBC_2.3.2',
'GLIBC_2.2.5', 'GLIBC_2.3.3', 'GLIBC_2.12'}, libc.so.6 with versions
{'GLIBC_2.3.4', 'GLIBC_2.15', 'GLIBC_2.9', 'GLIBC_2.3.2', 'GLIBC_2.4',
'GLIBC_2.3.3', 'GLIBC_2.16', 'GLIBC_2.17', 'GLIBC_2.10', 'GLIBC_2.6',
'GLIBC_2.3', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.14', 'GLIBC_2.11'},
libstdc++.so.6 with versions {'GLIBCXX_3.4.13', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.14', 'GLIBCXX_3.4.5', 'GLIBCXX_3.4.19', 'GLIBCXX_3.4.18',
'GLIBCXX_3.4.17', 'CXXABI_1.3.3', 'CXXABI_1.3', 'GLIBCXX_3.4.9',
'CXXABI_1.3.1', 'CXXABI_1.3.2', 'GLIBCXX_3.4.15', 'CXXABI_1.3.7',
'GLIBCXX_3.4', 'CXXABI_1.3.5'}, libcudart-80664282.so.10.2 with
versions {'libcudart.so.10.2'}, libnvrtc-08c4863f.so.10.2 with
versions {'libnvrtc.so.10.2'}, libnvToolsExt-3965bdd0.so.1 with
versions {'libnvToolsExt.so.1'}

This constrains the platform tag to "manylinux_2_17_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.
```

### Versions

n/a

cc @ezyang @seemethere @malfet
Repository: go
Issue: go/types, cmd/compile: "invalid type loop" depending on declaration order
Labels: NeedsFix,early-in-cycle

types2 currently rejects the test case below with "invalid recursive type A". Swapping the order of declarations for A and B makes the error go away.

```
package p

type A interface{ M(B[T]) }
type B[_ A] struct{}

type T struct{}
func (T) M(B[T]) {}
```

/cc @findleyr @griesemer @ianlancetaylor
Repository: opencv
Issue: HighGUI gets stuck in mutithreaded environments with other gtk window
Labels: category: highgui-gui,RFC,category: 3rdparty

##### System information (version)
- OpenCV => 4.2.0
- Gtkmm => 3.24.2
- Operating System / Platform => Ubuntu 20.04
- Compiler => g++

##### Detailed description
I was creating a multi-threaded app in which i wanted a GUI and the option to look at camera footage.  After the Gtk GUI loads up, waitKey() will not return although it is being run in a separate thread. using GDB i saw that the code was stuck in waitKey() in main_iteration_do. 

##### Steps to reproduce
```.cpp
#include <gtkmm.h>
#include <opencv2/highgui.hpp>
#include <opencv2/videoio.hpp>
#include <thread>

void cameraLoop()
{
    cv::VideoCapture cap;
    cap.open(0);
    cv::Mat frame;
    while(true)
    {
        cap.read(frame);
        cv::imshow("ligma",frame);
        if(cv::waitKey(1)=='q')
            break;
    }

}

int main()
{
    std::thread runCamLoop(cameraLoop);

    std::this_thread::sleep_for(std::chrono::seconds(1));

    auto app = Gtk::Application::create();
    Gtk::Window testWindow;
    app->run(testWindow); 

    std::this_thread::sleep_for(std::chrono::seconds(10));

    runCamLoop.join();
    return 0;
}    
```
Repository: TypeScript
Issue: JSDoc @param quick fix to rename reformats entire comment
Labels: Bug,Domain: Quick Fixes,Domain: JSDoc,Fix Available,Rescheduled,Effort: Casual

```js
/**
 * 
 * @param eks {string} the first param
 * @param y {number} the second param
 */
function foo(x, y) {
}
```

Use the `Rename '@param' tag name 'eks' to 'x'` refactoring.

**Expected**

```js
/**
 * 
 * @param x {string} the first param
 * @param y {number} the second param
 */
function foo(x, y) {
}
```

**Actual**

```js
/**
 * @param {string} x the first param
 * @param {number} y the second param
 */
function foo(x, y) {
}
```

Notice that

* A newline was deleted in the comment
* The parameter names and types are swapped
Repository: next.js
Issue: Upgrading from next@11 to next@12 breaks css-loader support
Labels: bug,Webpack

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

Operating System:
 - Platform: win32
 - Arch: x64
 - Version: Windows 10 Pro

Binaries:
 - Node: 16.13.1
 - npm: 8.1.2
 - Yarn: 1.22.10
 - pnpm: N/A

Relevant packages:
 - next: 12.0.11-canary.21
 - react: 17.0.2
 - react-dom: 17.0.2

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

The monaco editor comes with CSS files. Up until next@12, it has been possible to include these with the `css-loader`-package. After upgrading from next@11 to next@12, that is no longer possible, and I get the following error message:
```
./node_modules/css-loader/dist/cjs.js!./node_modules/monaco-editor/esm/vs/base/browser/ui/codicons/codicon/codicon.css
Module not found: ValidationInvalid generator object. Asset Modules Plugin has been initialized using a generator object that does not match the API schema.
 - generator has an unknown property 'filename'. These properties are valid:
   object { dataUrl? }
   -> Generator options for asset/inline modules.
```

### Expected Behavior

I'd expect it to build as it would in next@11

### To Reproduce

Try building next-11 and next-12 here: https://github.com/bragle/css-loader-issue-example. next-11 builds as expected, while next-12 does not. The only difference between the files in the folders are the next version
Repository: pytorch
Issue: [Main Issue] FSDP Model Checkpoint
Labels: oncall: distributed,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

FSDP model checkpointing APIs will support 3 different checkpoint APIs:

1. `full_state_dict` - returns state dict of full model parameters, much like DDP and local model training.
2. `local_state_dict` - returns local shards, ShardedTensor compatible, to be reloaded by FSDP module. 
3. `sharded_state_dict` - to support other parallelism type approaches and resharding. 

This is mainly a tracking/main issue, additional details around design and implementation to be added. 

Current follow up tasks: 

- [x] https://github.com/pytorch/pytorch/issues/73044
- [ ] https://github.com/pytorch/pytorch/issues/73046
- [ ] https://github.com/pytorch/pytorch/issues/73048
- [ ] https://github.com/pytorch/pytorch/issues/73080
- [ ] https://github.com/pytorch/pytorch/issues/73303
- [x] https://github.com/pytorch/pytorch/issues/73383
- [ ] https://github.com/pytorch/pytorch/issues/73446
- [x] https://github.com/pytorch/pytorch/issues/73384
- [x] https://github.com/pytorch/pytorch/issues/73518
### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: Run test_fsdp_core parity test for FSDP model checkpoint
Labels: oncall: distributed,module: fsdp

### 🚀 The feature, motivation and pitch

See comment https://github.com/pytorch/pytorch/pull/72469#discussion_r807171710

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: Enhanced local_state_dict FSDP checkpoint tests
Labels: oncall: distributed,module: fsdp

### 🚀 The feature, motivation and pitch

See discussion: https://github.com/pytorch/pytorch/pull/72469#discussion_r807228620

### Alternatives

_No response_

### Additional context

_No response_

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: aten::batch_norm schema does not mention mutation of running_mean/running_var
Labels: triaged

### 🐛 Describe the bug

aten::batch_norm's schema has the following arguments:

```
  arguments:
    arg: {'name': 'input', 'type': 'Tensor', 'pytype': 'Tensor'}
    arg: {'name': 'weight', 'type': 'Tensor?', 'pytype': 'Optional[Tensor]'}
    arg: {'name': 'bias', 'type': 'Tensor?', 'pytype': 'Optional[Tensor]'}
    arg: {'name': 'running_mean', 'type': 'Tensor?', 'pytype': 'Optional[Tensor]'}
    arg: {'name': 'running_var', 'type': 'Tensor?', 'pytype': 'Optional[Tensor]'}
    arg: {'name': 'training', 'type': 'bool', 'pytype': 'bool'}
    arg: {'name': 'momentum', 'type': 'float', 'pytype': 'float'}
    arg: {'name': 'eps', 'type': 'float', 'pytype': 'float'}
    arg: {'name': 'cudnn_enabled', 'type': 'bool', 'pytype': 'bool'}
```

Note that `running_mean` and `running_var` don't have `alias_info`. This makes some sense, since aliases to them are not returned, so there is no need for "alias" info per se, but currently `alias_info` also is the structure that contains the `is_write` flag. This makes it hard for downstream to automatically understand the semantics of the op.

Context: In the [Torch-MLIR](https://github.com/llvm/torch-mlir) project, we [generate](https://github.com/llvm/torch-mlir/blob/ed9bd556b3f59feb0fe1cca9776a3c2eb82fe826/python/torch_mlir/dialects/torch/importer/jit_ir/build_tools/torch_ods_gen.py#L1) MLIR operation descriptions (called "ODS") for the operators in the JIT registry. We infer various information and annotate the MLIR operations based on the schema. Two such properties are:
- HasValueSemantics (i.e., is it purely functional). We currently use the absence of alias_info to indicate that, but that seems to be incorrect for aten::batch_norm, which is not purely functional
- ReadOnly (not yet implemented) - a weaker version of HasValueSemantics -- it may introduce aliases, but it is guaranteed not to mutate any operands. Suitable for view-like ops, list getitem, etc.

How can we correctly infer these properties from the registry?



@bdhirsh

### Versions

Currently working off nightly at the time of this bug report.
Repository: TypeScript
Issue: Fields should inherit deprecation status
Labels: Suggestion,Awaiting More Feedback

# Bug Report

It doesn't affect the primary request, but the backstory here is API evolution: an intentionally overridable base class field needed to be renamed.  Derived classes are spread across packages, so we can't perform this change atomically. To avoid a breaking change, we introduce a field with the new name and mark the old one deprecated.  Unfortunately the deprecation status does not get inherited by fields declared in derived classes.  So derived classes are left unaware of the deprecation status.

### 🔎 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.
-->
`deprecated` `strikethrough` `field` `initializer`

### 🕗 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.  Technically you could call this a feature request.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?useDefineForClassFields=true&target=99#code/PTAEAEBcEMCcHMCmkBcpEGcB2iAekBYAKGIGMAbaDDUAISsVAG9jRRgAqDiAE0QAdYiUtEiIeoAArlEDUDwD2WAOSRQAVwyNIACwCWNAGZ7E5HgEJQHYK1CkF6rGoC8oAAwBuYgF9iZStSgAMJKGJCw6qSQCrAAqhjQSOj4iFg8NPRazLb2WGERUTGgABQAlNlEbGwY6vyIsGVelVW6BgB09o4uoACMHlW2VWwgAHpjY6DwCgo8aPl6ANbIOrAO8DqggLwbgLI7tr5E+-5UNABiJmbxiYx4YmkZcizNnU6grgBMTaPjI6AARtCzUBYBSgeZLXSrdTrLaAOR2fEA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
class Base {
  /** @deprecated Please don't use this field! */
  count = 0;
}

class ConstructorUsage extends Base {
  constructor () {
    super();
    this.count = 1;   
       //^^^^^ good: strikethrough 👍
  }
}

class FieldUsage extends Base {
  count = 2;
//^^^^^ bad: no strikethrough 👎
}
```

### 🙁 Actual behavior

Usage of the deprecated field does not trigger strikethrough formatting in `FieldUsage`.  This is because the new declaration is treated as non-deprecated.  It has not inherited the deprecated status.

### 🙂 Expected behavior

We should see strikethrough formatting when `FieldUsage` accesses the deprecated `count` field.

<code>&nbsp;&nbsp;~~count~~ = 2;</code>
Repository: neovim
Issue: View does not reset when navigating away from long lines
Labels: enhancement,needs:discussion

### Neovim version (nvim -v)

0.6.1

### Vim (not Nvim) behaves the same?

No, vim 8.2.4106

### Operating system/version

Arch Linux (Kernel 5.16.9-arch1-1)

### Terminal name/version

alacritty 0.11.0-dev (60ef17e8)

### $TERM environment variable

xterm-256color

### Installation

System package manager (pacman)

### How to reproduce the issue

nvim --clean
:nowrap
Type any long line that exceeds the split or window width
Type another line below that is shorter than the window width
Navigate to long line
$ to go to the end of long line
j to navigate down to short line

### Expected behavior

View to reset to column 0 to show the full short line as it fits within the window width. I specifically mean column 0 and **not** the first non-whitespace character.

As can be seen below with a bit of sample code Vim 8.2.4106 handles it in a way I would expect.
![vim_01](https://user-images.githubusercontent.com/8584482/154588790-baee6150-13ea-4568-9eab-58d094dc076a.png)
Navigating to the end of the long line using $:
![vim_02](https://user-images.githubusercontent.com/8584482/154588844-20ca6f76-6f61-4aa1-881d-9960044aaab5.png)
Moving down (only pressing j, no other inputs were made) to the line below:
![vim_03](https://user-images.githubusercontent.com/8584482/154588868-4d07f01c-f5f2-4d4b-88be-a531a4f979e2.png)



### Actual behavior

The cursor just pulls the view back to the first visible character but no further so the rest of the line can't be seen.

Same code as above:
![nvim_01](https://user-images.githubusercontent.com/8584482/154589287-81d00a2c-fdce-415b-bc9a-6fe4edd79ace.png)
Navigating to the end of the long line with $:
![nvim_02](https://user-images.githubusercontent.com/8584482/154589306-9e0af915-de87-4921-a864-529bd2373eef.png)
Moving down (once again only pressing j):
![nvim_03](https://user-images.githubusercontent.com/8584482/154589334-2105bc3e-d69c-4edc-b48c-84999cf22480.png)