sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [material-ui][Button] Variants don't consume the size prop
Labels: support: question,component: button,package: material-ui,v6.x,customization: theme

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

Creating a button variant doesn't seem to use the size prop. When a button and a variant button are placed next to each other they look misaligned.

```ts
export const components = {
  MuiButton: {
    defaultProps: {
      variant: 'contained'
    },
    variants: [
      {
        props: { variant: 'action' },
        style: {
          background: 'red'
        }
      }
    ]
  }
} as Components;
```

```html
<div>
  <Button color="primary" size="large">
    Normal Button
  </Button>
  <Button color="secondary" size="large" variant="action">
    Variant Button
  </Button>
</div>
```

![image](https://user-images.githubusercontent.com/4462478/164885670-4fd27bc2-38bd-4a65-bb47-cec3fa8c7360.png)


### Expected behavior 🤔

I assumed size would be consumed so buttons and their variants could still be grouped together to have the same font sizes and padding etc.

### Steps to reproduce 🕹

Steps:

1. Create a button variant
2. Try and use different sizes on the variant while comparing font size and padding to the normal button

### Context 🔦

Create a button variant with different styles while still being able to consume the existing props like size. I'd like to be able to position the buttons next to each other and have them using the same font sizes and padding without looking misaligned.

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>
  System:
      OS: Windows 10 10.0.19044
    Binaries:
      Node: 16.13.2 - C:\Program Files\nodejs\node.EXE
      Yarn: 1.22.15 - C:\Program Files\nodejs\yarn.CMD
      npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
    Browsers:
      Chrome: Not Found
      Edge: Spartan (44.19041.1266.0), Chromium (100.0.1185.44)
    npmPackages:
      @emotion/react: ^11.9.0 => 11.9.0
      @emotion/styled: ^11.8.1 => 11.8.1
      @mui/base:  5.0.0-alpha.77
      @mui/material: ^5.6.2 => 5.6.2
      @mui/private-theming:  5.6.2
      @mui/styled-engine:  5.6.1
      @mui/system:  5.6.2
      @mui/types:  7.1.3
      @mui/utils:  5.6.1
      @types/react: ^18.0.6 => 18.0.6
      react: ^18.0.0 => 18.0.0
      react-dom: ^18.0.0 => 18.0.0
      typescript: ^4.6.3 => 4.6.3
</details>
Repository: create-react-app
Issue: How can I disable no-unused-vars
Labels: needs triage

How can I disable eslint's no-unused-vars in create-react-app? I tried changing the eslint config in package.json but it didn't work.

"eslintConfig": {
	"rules": {
		"no-unused-vars": "off"
	}
}

And I tried tens of other changes and nothing works. I cant believe that this create-react app has this sh*it config by default
Repository: rust
Issue: [NLL] Lifetimes errors in a function can mask later errors in same function
Labels: A-diagnostics,T-compiler,A-NLL,NLL-diagnostics

For test [src/test/ui/regions/region-multiple-lifetime-bounds-on-fns-where-clause.rs](https://github.com/rust-lang/rust/tree/master/src/test/ui/regions/region-multiple-lifetime-bounds-on-fns-where-clause.rs), under NLL, a `lifetime may not live long enough` error is missing.
This is a behavior change which should be investigated.

See comment posted by @jackh726 in https://github.com/rust-lang/rust/pull/96212#discussion_r853109019
Repository: rust
Issue: [NLL] Loss of span for `consider adding an explicit lifetime bound` suggestions
Labels: A-diagnostics,T-compiler,A-NLL,NLL-diagnostics

In tests like:
* [src/test/ui/regions/regions-close-object-into-object-5.rs](https://github.com/rust-lang/rust/tree/master/src/test/ui/regions/regions-close-object-into-object-5.rs)
* [src/test/ui/regions/regions-close-over-type-parameter-multiple.rs](https://github.com/rust-lang/rust/tree/master/src/test/ui/regions/regions-close-over-type-parameter-multiple.rs)

Under NLL we rightfully suggest to add a lifetime bound:
```
   |
LL |     Box::new(B(&*v)) as Box<dyn X>
   |              ^^^^^^
   |
   = help: consider adding an explicit lifetime bound `T: 'static`...
```

but the actual span where the lifetime bound should be added is lost when we compare to non-nll mode:
```
LL | fn f<'a, T, U>(v: Box<A<T> + 'static>) -> Box<X + 'static> {
   |          - help: consider adding an explicit lifetime bound...: `T: 'static`
```

This is a diagnostic regression that should be fixed.

@rustbot label +A-NLL +NLL-diagnostics
Repository: rust
Issue: [NLL] Improve error spans for `regions-bounded-by-trait-requiring-static.rs` ui test
Labels: A-diagnostics,T-compiler,A-NLL,NLL-diagnostics

For test [src/test/ui/regions/regions-bounded-by-trait-requiring-static.rs](https://github.com/rust-lang/rust/tree/master/src/test/ui/regions/regions-bounded-by-trait-requiring-static.rs) the error spans are not very precise when compared to non-nll mode.
This should be improved.

See comment posted by @jackh726 in https://github.com/rust-lang/rust/pull/96212#discussion_r853116301

@rustbot label +A-NLL +NLL-diagnostics
Repository: create-react-app
Issue: Support for decorators (now stage 3)
Labels: issue: proposal,needs triage

Hello,

Since ES decorators are finally in stage 3 https://github.com/tc39/proposal-decorators is there any chance CRA would now add this feature ?

we could then update the answer in the [FAQ _**"Can I use decorators in CRA"**_](https://create-react-app.dev/docs/can-i-use-decorators/)  to "YES" 😄
Repository: flutter
Issue: macOS project template should support Cmd+W shortcut to close the window
Labels: tool,platform-mac,c: proposal,a: desktop,P3,team-macos,triaged-macos

## Proposal

`Cmd + W` is my most used keyboard shortcut on macOS. I believe most macOS users also do that. Project created with `flutter create` currently doesn't support `Cmd + W`.

Here's a screenshot of an Electron app which has `Cmd + W` support.
<img width="188" alt="image" src="https://user-images.githubusercontent.com/11565096/164894185-f18aa565-8701-482c-91ac-dec2b8de8d09.png">
Repository: excalidraw
Issue: support importing multiple excalidrawlib files at once
Labels: enhancement

Either via file picker or drag & drop.
Repository: angular
Issue: Convert [ngClass]="{x: ...}" to [class.x]="..." during prod build
Labels: area: common,area: core,core: styling bindings,P3,compiler: extended diagnostics

### Which @angular/* package(s) are relevant/related to the feature request?

common, compiler

### Description

I noticed that [ngClass]="..." syntax is heavier and slower than [class.x]="..." syntax.
...if I made tests in the right way =)

I did some tests here: https://github.com/IvanBisultanov/angular_bundle_size

case1 - ngClass:1_className
case2 - class.:1_className
case3 - ngClass:5_classNames
case4 - class.:5_classNames
case5 - ngClass:10_classNames_x_2000
case6 - class.:10_classNames_x_2000

These are the results:
Prod bundle size | size 1/3/5 | size 2/4/6 | Diff 
---|------------|------------|--- 
case1 vs case2 | 158110     | 158051     | -59
case3 vs case4 | 158483     | 158117     | -366
case5 vs case6 | 164574     | 164357     | -217
  
`npm run start-prod` scripting time performance tab

Attempt | 1  | 2  | 3  | 4  | 5  | Average
--- |-----|-----|-----|-----|-----|---------
case5, ms | 242 | 237 | 231 | 236 | 234 | 236
case6, ms | 185 | 186 | 185 | 176 | 180 | 183
Diff| | | | | |-53

### Proposed solution

Is it possible during production build to convert [ngClass] to [class.] and then bundle the code?
As result, we will have a smaller bundle and seems a bit faster application.

### Alternatives considered

None.
Repository: rust
Issue: E0207 occurs even though the generic type is bound as an associated type
Labels: A-type-system,A-diagnostics,T-compiler,C-bug,D-confusing,T-types

I tried this code:

```rust
struct Struct<T>(T);

trait Trait1<'a> {
    type Item;
}

impl<'a, T, U> Struct<T> where T: Trait1<'a, Item=U> {}
```

I expected to see this happen: Compilation completes without error.

Instead, this happened: E0207 occurs.
```
Compiling playground v0.0.1 (/playground)
error[E0207]: the type parameter `U` is not constrained by the impl trait, self type, or predicates
 --> src/lib.rs:7:13
  |
7 | impl<'a, T, U> Struct<T> where T: Trait1<'a, Item=U> {}
  |             ^ unconstrained type parameter

For more information about this error, try `rustc --explain E0207`.
error: could not compile `playground` due to previous error
```
Since U is bound as an associated type of T, it appears to be compilable code. As shown below, E0207 does not seem to occur when the trait T has no lifetime parameter
```
impl<T, U> Struct<T> where T: Iterator<Item=U> {}
```

This may be related to #67623. The intent of the post seems to be different than mine.

### Meta

`rustc --version --verbose`:
```
rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-pc-windows-msvc
release: 1.60.0
LLVM version: 14.0.0
```

This also occurs in rust playground
```
Stable channel
Build using the Stable version: 1.60.0

Beta channel
Build using the Beta version: 1.61.0-beta.3
(2022-04-17 2431a974c2dcf82ba513)

Nightly channel
Build using the Nightly version: 1.62.0-nightly
(2022-04-22 f4ec0e7cff545e932ce3)
```

### Backtrace
Not provided
Repository: godot
Issue: Runtime Crash/Editor reload fail when a material directly uses imported .ctex instead of source picture
Labels: bug,topic:editor,crash

### Godot version

4.0 Alpha 6

### System information

Windows 11, Vulkan, Nvidia GTX 1050 Ti, 512.15

### Issue description

Loading a .ctex file (with the correct compression format) works fine in the editor, however it fails to run the scene, or reload the scene in the editor. Applying the Texture in a Script at runtime also works.

Note: This would be desirable to be able to use the .ctex directly and trash the original source files for game install size reasons

### Steps to reproduce

Set a texture to .ctex file and try to run scene or reload it

### Minimal reproduction project

[Texture.zip](https://github.com/godotengine/godot/files/8547538/Texture.zip)
Repository: rust
Issue: Consider warning on `--exclude src/tools/tidy` if the exclude isn't used
Labels: C-enhancement,T-bootstrap

Not quite sure how to implement this, but it seems like a nice QoL thing.

@rustbot label +A-rustbuild +C-enhancement
Repository: godot
Issue: Vulkan: Using main Viewport as Sprite2D texture causing artefacts and error
Labels: bug,topic:rendering,confirmed

### Godot version

v4.0.alpha6.official [e4f0fc50f]

### System information

Windows 11, Vulkan, Nvidia 3080Ti (511.79)

### Issue description

Using main Viewport as Sprite2D texture causing artefacts and error:

E 0:00:02:0993   draw_list_bind_uniform_set: Attempted to use the same texture in framebuffer attachment and a uniform (set: 3, binding: 0), this is not allowed.
  <C++ Error>    Condition "attachable_ptr[i].texture == bound_ptr[j]" is true.
  <C++ Source>   drivers/vulkan/rendering_device_vulkan.cpp:7419 @ draw_list_bind_uniform_set()

![image](https://user-images.githubusercontent.com/35319858/164916044-36a9d3b8-6623-41d6-9011-f6c5a34f7fb3.png)

![image](https://user-images.githubusercontent.com/35319858/164915694-257b2980-69cb-48d9-b3e1-c497fc05b2ec.png)


### Steps to reproduce

Create sprite 2d, assign main viewport texture to it.

### Minimal reproduction project

[Viewport.zip](https://github.com/godotengine/godot/files/8547668/Viewport.zip)
Repository: TypeScript
Issue: JSDoc types with class / namespace not combined correctly
Labels: Suggestion,Awaiting More Feedback,Domain: JSDoc

# Bug Report

The AWS-SDK has this type:

```ts
export class ManagedUpload {
  // class def
}
export namespace ManagedUpload {
    // etc
    export interface SendData {
        Location: string;
        ETag: string;
        Bucket: string;
        Key: string;
    }
}
```
I'm importing `ManagedUpload` in a TS-checked JSDoc file like:
```js
/** @typedef {import('aws-sdk/lib/s3/managed_upload').ManagedUpload} ManagedUpload */
```
But referencing `ManagedUpload` produces an error, when used like:
```js
      /** 
       * @param {Error} s3Err
       * @param {ManagedUpload.SendData} data
       */
      function uploadFunction(s3Err, data) {
        if (s3Err) reject(s3Err)
        resolve(data)
      }
```
I get an error / underline on `ManagedUpload` which says, `'ManagedUpload' only refers to a type, but is being used as a namespace here.`

### 🔎 Search Terms
JSDoc, namespace, class

### 🕗 Version & Regression Information
Embedded TypeScript version in VSCode (1.66.0)
Repository: godot
Issue: Deleting binds in connections dialog could be improved
Labels: enhancement,topic:editor,usability

### Godot version

7d6f878

### System information

Windows 10 x64

### Issue description

This:
![image](https://user-images.githubusercontent.com/2223172/164916467-7b2e094b-dc73-4f27-be6a-ed81242bd05b.png)
The connection dialog has a type selector and Add button that adds a bind, which is then edited in a micro inspector. This is ok, but the odd part is the Remove button. It removes the currently selected argument and does nothing if nothing is selected. This is somewhat intuitive, but still feels weird.

Instead we could maybe add a delete button next to each property:
![image](https://user-images.githubusercontent.com/2223172/164916586-c912b0ff-1d23-4d86-ae30-d6e508e7890e.png)
But not sure how it can be implemented, as the property list is an inspector.

### Steps to reproduce

1. Try to connect something
2. Go to Advanced and add extra arguments
3. Try to remove argument

### Minimal reproduction project

_No response_
Repository: neovim
Issue: Lua equivalent of `vim.b.undo_ftplugin`
Labels: enhancement

### Feature already in Vim?

No

### Feature description

First of all thanks for this project, it's literally a life-changer. My issue about whether or not there is a plan about vim's `b:undo_ftplugin` feature. As far as I know currently there is no way to control it with Lua without setting the variable itself with Vimscript string. It would be nice to have a callback function option like keymap module.
Repository: create-react-app
Issue: Windows 11 unknown spawn error code - 4094 while creating a react app 
Labels: needs triage,issue: bug report

<!--
    Please note that your issue will be fixed much faster if you spend about
    half an hour preparing it, including the exact reproduction steps and a demo.

    If you're in a hurry or don't feel confident, it's fine to report bugs with
    less details, but this makes it less likely they'll get fixed soon.

    In either case, please use this template and fill in as many fields below as you can.

    Note that we don't provide help for webpack questions after ejecting.
    You can find webpack docs at https://webpack.js.org/.
-->

### Describe the bug

When I was running "npx create-react-app my-app" I'm facing this error and it's asking me to report it as a bug . The react app is not created. 

### Environment : 

<!--
  To help identify if a problem is specific to a platform, browser, or module version, information about your environment is required.
  This enables the maintainers quickly reproduce the issue and give feedback.

  Run the following command in your React app's folder in terminal.
  Note: The result is copied to your clipboard directly.

  `npx create-react-app --info`

  Paste the output of the command in the section below.
-->

### Environment Info:

  current version of create-react-app: 5.0.1
  running from C:\Users\91868\AppData\Local\npm-cache\_npx\c67e74de0542c87c\node_modules\create-react-app

  ### System:
    OS: Windows 10 10.0.22000
    CPU: (8) x64 Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz
  ### Binaries:
    Node: 14.17.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 8.7.0 - C:\Program Files\nodejs\npm.CMD
  ### Browsers:
    Chrome: Not Found
    Edge: Spartan (44.22000.120.0), Chromium (100.0.1185.50)
    Internet Explorer: 11.0.22000.120
  ### npmPackages:
    react: Not Found
    react-dom: Not Found
    react-scripts: Not Found
  ### npmGlobalPackages:
    create-react-app: Not Found .



### Expected behavior
I expected the command to work well as earlier and create a new react app . 


### Actual behavior
It raised an error and the app was not created , asking me to mark it as a bug report. 

<img width="811" alt="image" src="https://user-images.githubusercontent.com/59198577/164946640-8da8a246-b5ee-4225-bcae-39c22755f9d8.png">

<img width="493" alt="image" src="https://user-images.githubusercontent.com/59198577/164946672-e5739c74-ce0a-49aa-8290-a8a460d85439.png">

### Please fix this issue asap.
Repository: rust
Issue: The iterator documentation lacks guidance for implementers of iterators with side-effects
Labels: A-docs,A-iterators

Today the standard library implementation of the defaulted iterator methods as well as various transformers are developed under an assumption that there are basically two kinds of valid iterators:

1. Side-effect free iterators (these are very nice and easy to optimize :partying_face: :tada:);
2. Iterators with side effects where all the side effects will be observed no matter how you combine it (e.g. `(0..10).map(|_| println!("banana")).skip(10).next()` will still print out a :banana: 10 times.

However, nothing in the documentation we have appears to inform of this. And so people implementing the `Iterator` trait may be inclined to optimize their side-effect-ful Iterators to omit some side effects when they deem it possible. I was presented “debug logs” as an example of what definitely doesn't _feel_ like a side-effect even though it definitely is, but even things like database or filesystem access could be suspect here.

So, consider the following Up To No Good code as an example:

```rust
struct MyIterator {
    current: usize,
}

impl Iterator for MyIterator {
    type Item = usize;
    fn next(&mut self) -> Option<usize> {
        self.nth(0)
    }
    
    fn nth(&mut self, count: usize) -> Option<usize> {
        let result = self.current + count;
        self.current = result + 1;
        println!("will yield {}", result);
        Some(result)
    }
}
```

Seems very justified in isolation. However in the presence of such an implementation we also start leaking implementation details of the standard library left and right:

```rust
fn main() {
    let mut iterator = MyIterator { current: 0 };
    iterator.nth(10);
    iterator.nth(10);
    let mut skipped_once = MyIterator { current: 0 }.skip(10);
    skipped_once.next();
    let mut skipped_twice = MyIterator { current: 0 }.skip(10).skip(10);
    skipped_twice.next();
}
```

prints out:

```
will yield 10
will yield 21
will yield 9
will yield 10
will yield 9
will yield 19
will yield 20
```

The intuition I have as somebody working on Rust is that implementing `skip(10)` by calling `next()` 10 times, or by calling `nth` only once for each `next()` ought to be a valid implementation. However any change to implementation of `skip` suddenly becomes a potentially breaking change in presence of such an iterator implementation.

All that is to say that we definitely should document what a correct implementation of the overriden default `Iterator` methods should look like and what are the consequences of not following the guidance.
Repository: go
Issue: proposal: plugin: add Syms method
Labels: Proposal

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->
Hello. 
I would like to suggest a tiny change on the [plugin package](https://github.com/golang/go/tree/master/src/plugin).
The _Plugin_ struct have a field called [_syms_](https://github.com/golang/go/blob/master/src/plugin/plugin.go#L25), that [holds all exported variable or function names](https://github.com/golang/go/blob/master/src/plugin/plugin.go#L36). It's [safe for concurrent](https://github.com/golang/go/blob/master/src/plugin/plugin.go#L38) too. But, we can't access this field when using the _Plugin_ struct, and would be useful to use that map, e.g in the case of a programs that wants to list to the user all the functions that a plugin exports.
So, my suggestion is to turn the field [_syms_](https://github.com/golang/go/blob/master/src/plugin/plugin.go#L25) to Syms, so we can use when import the plugin package.
Repository: godot
Issue: GLB import albedo texture uses sRGB space for Windows export but linear space for HTML export (GLES3)
Labels: bug,platform:web,topic:rendering,topic:porting,topic:3d

### Godot version

3.4.4

### System information

Windows 10

### Issue description

I have a GLB model with an albedo texture.  For the GLB import, I have chosen Material Storage: Built-In.  When I export for Windows (or run in the editor) the albedo texture uses sRGB color space, but when I export for HTML the albedo texture uses linear color space.
![native](https://user-images.githubusercontent.com/23195746/164951243-df06ba7f-b8fd-41cc-8da7-3527691d8218.png)
![web](https://user-images.githubusercontent.com/23195746/164951249-18f7452b-10b9-495a-afdc-d54c6ada8367.png)

Both of the above images use the texture below, which has a white/black checkboard pattern on half, and an 0.5 grey value on the other half.  In linear space they will appear to be the same brightness, but in sRGB space they will not.

![texture](https://user-images.githubusercontent.com/23195746/164951371-d794f349-6ce0-44f9-a4b7-766bed0cae6f.png)

### Steps to reproduce

Import a GLB model with an albedo texture.  Don't change the material.  Notice that the Windows editor and Windows export interpret color values in the albedo texture as sRGB, regardless of the 'sRGB' checkbox being unchecked in the material's albedo texture.  Notice that the Web export will interpret the color values in the albedo texture as linear, because the 'sRGB' checkbox in the material's albedo texture is unchecked.


### Minimal reproduction project

[srgb_vs_linear.zip](https://github.com/godotengine/godot/files/8548844/srgb_vs_linear.zip)