sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Specifying lint levels does not work on macros
Labels: A-diagnostics,T-compiler

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
fn main() {
    #[allow(irrefutable_let_patterns)]
    println!("{}", if let _ = 1 { 42 } else { 0 });
    
    // The macro doesn't matter, even macros like `asm!` exhibit this behavior
    #[allow(irrefutable_let_patterns)]
    dbg!("{}", if let _ = 1 { 42 } else { 0 });
    
    #[allow(irrefutable_let_patterns)]
    {
        println!("{}", if let _ = 2 { 84 } else { 0 });
    }
    
    #[allow(irrefutable_let_patterns)]
    if let _ = 3 { 
        println!("{}", 168);
    } else { 
        println!("{}", 0);
    }
}
```
[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9a1b773af2cac2860626115a77a2336b)

The current output is:

```
warning: irrefutable `if let` pattern
 --> src/main.rs:3:20
  |
3 |     println!("{}", if let _ = 1 { 42 } else { 0 });
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(irrefutable_let_patterns)]` on by default
  = note: this pattern will always match, so the `if let` is useless
  = help: consider replacing the `if let` with a `let`

warning: irrefutable `if let` pattern
 --> src/main.rs:7:16
  |
7 |     dbg!("{}", if let _ = 1 { 42 } else { 0 });
  |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this pattern will always match, so the `if let` is useless
  = help: consider replacing the `if let` with a `let`

warning: 2 warnings emitted
```

Ideally in this case, the compilation should succeed without warning, as the lint appears to have been explicitly allowed everywhere it is used.

This likely applies for all lints and all lint levels and all macros
 - (only tested `println!`, `dbg!`, and `asm!` with allow, warn, and deny for `irrefutable_let_patterns` as well as in in my in progress lint `named_asm_labels`)
 
A current workaround is to create a scope to put the macro in, and apply the lint level to *that scope*, as demonstrated in the example.

Applying the lint level to the crate with `#![level(lint)]` works as expected, however this is often not desirable.

Possibly related: #59306
Repository: TypeScript
Issue: Intellisense AutoComplete out of Context , unbearable
Labels: Needs Investigation

![image](https://user-images.githubusercontent.com/6446798/125978608-523827be-71a3-4c35-8522-1526a77dad8e.png)
The screen recording does not pick up the autocomplete window, but I was able to capture the essence of what I am trying to get. I have autoclosing tags enabled, yet they do not autoclose or even suggest to close the element correctly. **The Report A Problem page redirects to this issue.**

_Originally posted by @Reckoning47 in https://github.com/microsoft/TypeScript/issues/5997#issuecomment-881568500_


this makes the use of the IDE unbearable, I waste too much time and it brakes the flow of coding when you always have to press escape to continue working for every freaking tag
Repository: flutter
Issue: Repeated clicks of the official component click event caused the CPU usage to increase to 65 percent
Labels: platform-ios,engine,c: performance,has reproducible steps,P2,found in release: 2.2,found in release: 2.4,team-ios,triaged-ios

Repeated clicks of the official component click event caused the CPU usage to increase to 65 percent in iOS
such as:
InkWell(
        onTap: () => {},
        child: Icon(Icons.add),
 )

[✓] Flutter (Channel unknown, 2.2.1, on macOS 11.2.3 20D91 darwin-arm, locale zh-Hans-CN)
    • Flutter version 2.2.1 at /Users/pupu-xia/fvm/versions/2.2.1
    • Framework revision 02c026b03c (8 周前), 2021-05-27 12:24:44 -0700
    • Engine revision 0fdb562ac8
    • Dart version 2.13.1
    • Pub download mirror https://pub.flutter-io.cn
    • Flutter download mirror https://storage.flutter-io.cn

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/pupu-xia/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • ANDROID_HOME = /Users/pupu-xia/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] VS Code (version 1.58.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.24.0
Repository: node
Issue: Deprecate `Readable.readableFlowing` setter
Labels: stream

How this works and what it does is pretty undefined and I don't think users should be using this setter.
Repository: storybook
Issue: Add code highlighting for "raw" editing of an object.
Labels: feature request,inactive,addon: controls

Currently the raw editing of an object just shows plain text. Please add code highlighting in the new versions, as the editing would be more easy. You could easily exchange the textarea with some kind of highlighting controls.

Looks like this currently:
![currentraw](https://user-images.githubusercontent.com/21260471/126753537-1aac37aa-0d24-49e9-860c-b2504babdc1a.png)

Could look like this in future:
![futureraw](https://user-images.githubusercontent.com/21260471/126753535-9a625e3a-b7f5-4aeb-a412-0db4a4ee40aa.png)
Repository: next.js
Issue: Locale not preserved on redirect in getServerSideProps
Labels: bug

### What version of Next.js are you using?

11.0.2-canary.16

### What version of Node.js are you using?

14

### How are you deploying your application?

Vercel

### Describe the Bug

If I redirect from a `getServerSideProps` function, the locale present of the URL is not used to build the redirect destination URL. 



### Expected Behavior

When redirecting, next should preserve the locale present in the URL. 

It could also expose a field `locale` in the redirect payload to allow end user to choose the locale where to go. 

### To Reproduce

Given this page `pages/index.tsx`:

```ts
interface RootPageProps {}

export const getServerSideProps: GetServerSideProps<RootPageProps> =
  async (context) => {
    return {
      redirect: {
        destination: "/foo/bar",
        permanent: false,
      },
    };
  };
```

And the locales `en` and `fr` are configured (`en` is the default one).
When I visit: `http://localhost:300/fr` 

I should be redirected to  `http://localhost:300/fr/foo/bar` but I'm redirected to `http://localhost:300/foo/bar`. The initial locale is lost during the redirection.

I found a workaround to preprend the locale to the destination path: 

```ts
interface RootPageProps {}

export const getServerSideProps: GetServerSideProps<RootPageProps> =
  (context) => {
    const localePathPrefix =
      context.locale !== context.defaultLocale ? `/${context.locale}` : "";

    return {
      redirect: {
        destination: localePathPrefix + "/foo/bar",
        permanent: false,
      },
    };
  };
```
Repository: TypeScript
Issue: The Promise constructor cannot handle void returns on resolve
Labels: Needs Investigation

## Configuration Check

My compilation *target* is `es5` and my *lib* is `dom`, `es5`, `es2015.promise` and `es2015.iterable`.

## Missing / Incorrect Definition

The value for the resolve callback in the `Promise` constructor is required:
`new <T>(executor: (resolve: (value: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;`

## Sample Code

Using `void` as the generic (return) type for a `Promise` results in an error:
![image](https://user-images.githubusercontent.com/24222938/126765133-49bc15de-a2a1-408c-9956-8c6f9eccc775.png)

## Workaround 
The current workaround is to return `undefined`:
![image](https://user-images.githubusercontent.com/24222938/126754922-53358350-1d61-428a-8b59-fc0a9ae74811.png)

But `undefined` is not the same as `void`: https://www.typescriptlang.org/docs/handbook/2/functions.html#void
Repository: PowerToys
Issue: Lorem Ipsum Generator
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

some sort of shortcut should copy an lorum ipsum text with 100 words to the clipboards first position.

### Scenario when this would be used?

For all cases of predesigning an app, a feature without the correct data.

### Supporting information

_No response_
Repository: flutter
Issue: PlatformDispatcher.accessibilityFeatures complete with properties for 'Button Shapes' and 'On/Off Labels'
Labels: c: new feature,engine,a: accessibility,c: proposal,P3,team-engine,triaged-engine

Hi,

I use the PlatformDispatcher to query some accessibility features at app startup. I noticed that there is currently no possibility to query the iOS specific settings 'Button Shapes' and 'On/Off Labels'. Could the AccessibilityFeatures of the PlatformDispatcher be extended by these two options?

Thank you very much and best regards
Repository: godot
Issue: custom mouse icon does not change when mouse has not moved on startup
Labels: bug,topic:porting,topic:input,topic:gui,topic:2d

### Godot version

3.3 stable

### System information

linux mint 10

### Issue description

I have custom image set as the mouse in the project settings.

If you start Godot and do not move the mouse the cursor remains as the default OS mouse until the mouse is moved, it then changes to the Godot image. However, this problem manifests in a bad way when you are using a gui.

If you enable a gui scene without having moved the mouse, then the mouse remains as the default until you close your gui then reopen it. It does not matter if you have called MOUSE_MODE_HIDDEN or not.

In the meantime, is there a workaround, e.g. a method to force the mouse to change or simulate a mouse move?

Observe:

https://user-images.githubusercontent.com/12863685/126780129-dd7fce3d-6308-43f6-9c2d-1ec1715d695c.mp4



### Steps to reproduce

1. add custom image to a mouse
2. start program without moving mouse
3. the mouse does not change

or for the gui issue:
1. as above
2. as above
3. show a gui
4. the mouse does not change until the gui is removed

### Minimal reproduction project

_No response_
Repository: godot
Issue: SDFGI Is Splotchy On Large Uniform Surfaces
Labels: topic:rendering,documentation,topic:3d

### Godot version

Godot 4 nightly build

### System information

Windows 10 v20H2, Intel i7 6700, Nvidia GTX1080, 16GB RAM

### Issue description

SDFGI displays severe splotching and pockmarking artifacts in low-light environments and especially on large uniform surfaces with little texture or model breakup. Although this splotching seems to always be present, it is mostly present in these circumstances.

### Steps to reproduce

In the following examples I have a room with a single thin window letting directional light in as well as skylight. This scenario has been recreated in the attached project file below.
Here, we can observe severe splotching of light and dark tones in a large bare room:
![SDFGI Splotchy 05](https://user-images.githubusercontent.com/70243134/126780033-794a4b65-523b-4b67-9f99-3adad9fa6495.JPG)
![SDFGI Splotchy 01](https://user-images.githubusercontent.com/70243134/126780227-d9ba9e5c-c943-4c8f-8326-edff8b0344e8.JPG)

Even on smaller-scale surfaces and those with low detail frequency the splotching can be observed. Although it may look smooth from a distance:
![SDFGI Splotchy 02](https://user-images.githubusercontent.com/70243134/126780307-ba73844c-bf7c-4c49-8be5-b250c09cf1a2.JPG)

Splotching occurs when the camera moves closer and GI detail is increased in the area:
![SDFGI Splotchy 03](https://user-images.githubusercontent.com/70243134/126780368-620c7bf2-c03b-4d0b-b17a-0d4699b3cad5.JPG)

### Minimal reproduction project

I have provided an example file with a couple basic meshes and a capsule to represent the size of a regular player:
[SDFGI_Splotchy_Bug.zip](https://github.com/godotengine/godot/files/6868679/SDFGI_Splotchy_Bug.zip)

Here are some screenshots of the effects that may be observed:
The leftmost structure is only partially enclosed with plenty of light spilling in. Although the effect is hardly noticeable close to the light, further into the structure where the light has difficulty reaching there are highly visible artifacts:
![SDFGI Splotchy 06](https://user-images.githubusercontent.com/70243134/126781073-4f75b6ab-c867-4b0f-a899-c2afab7502c6.JPG)

The rightmost structure is considerably larger with a thinner opening for light to enter. Although there is no detail frequency in the space, the GI lighting artifacts are chaotic:
![SDFGI Splotchy 07](https://user-images.githubusercontent.com/70243134/126781185-b48136f6-ac43-48c1-a2a9-f68e150aa20f.JPG)

All shots taken with 8 cascades, Y scale at 50% and Occlusion and Sky Influence active.
Repository: PowerToys
Issue: Color Picker - Replace Windows default colour picker
Labels: Idea-Enhancement,Product-Color Picker

### Description of the new feature / enhancement

Could the PowerToys color picker entirely replace the default Windows colour picker?

There used to be an app called Jovian Color Picker that did this, but it seems abandoned many years ago.

### Scenario when this would be used?

Allows a modern, more advanced color picker everywhere that the Windows default is used.

### Supporting information

Archived Jovian page: https://web.archive.org/web/20111208024616/http://www.joviancolorpicker.com/index.aspx

Super User discussion: https://superuser.com/questions/1412770/how-to-change-the-windows-10-default-color-picker
Repository: godot
Issue: CPUParticles2D Color ramp and Gravity sometimes reset with use_vsync=false
Labels: bug,topic:rendering,topic:2d,topic:particles

### Godot version

3.3.2-stable_x11.64

### System information

Ubuntu 20.04.2 LTS, GLES2, GeForce GTX 950

### Issue description

In some cases the CPUParticles2D system will do some kind of "reset". I have had it happen randomly, but seem to be able to provoke the bug if i agressively resize the game window.
Upon this "reset" All particle movement that was caused by the "gravity" setting will be undone. Movement from "velocity" seems unaffected.
Additionally Color Ramp progress for all current particles are reset.
The "reset" seems to only occur when "use_vsync" is disabled in the project settings
i have included a video of the issue:

https://user-images.githubusercontent.com/3738264/126785092-485bfd71-aea6-48d7-b43e-65317e34a8dc.mp4



### Steps to reproduce

- Create an empty project and set "display/window/vsync/use_vsync" to "false"
- Create a 2D scene and add a CPUParticles2D node
  - Set amount to 80, lifetime to 15, initial velocity to 10, and the texture to the glorious godot icon.png
  - Set gravity to (0, 3.5)
  - Set a color ramp that fades in in the beginning and out in the end. f.ex: offsets:(0, 0.2, 0.8, 1.0) colors:(Transparent, White, White, Transparent)
  - Play scene and let the system run for at least 15 sec. Notice the particles should be moving right and slowly falling while fading in and out
  - Try resizing the window, or otherwise stressing it somehow. Suddenly the particles will all reset their colors and move up, as if gravity had not affected them from the beginning.

### Minimal reproduction project

_No response_
Repository: godot
Issue: VisualScript is not hinting when extending a class_named Script
Labels: bug,topic:editor,topic:visualscript

### Godot version

3.3.2

### System information

Windows 10

### Issue description

In VisualScript when you try to extend a other script.

It is not possible to select a script like in GDScript. You are only able to select class_name scripts.
Those scripts do not get any hints in the editor. Not even those of the base class.

Making it completely unworkable.

No function hints no variable hints nothing



### Steps to reproduce

![image](https://user-images.githubusercontent.com/20573784/126790946-c397daaa-4b16-4f57-9c31-1a23f55083b2.png)


### Minimal reproduction project

[mrp_extend class_name.zip](https://github.com/godotengine/godot/files/6869238/mrp_extend.class_name.zip)
Repository: rust
Issue: Add more artifact size profiling
Labels: WG-compiler-performance,A-self-profile

As an extension to https://github.com/rust-lang/rust/pull/87404, we'll want to add support for profiling even more artifact file sizes. Below are some ideas of which artifacts we'll want to profile: 

* object files
* bit code 
* crate metadata
  * Everything captured [here](https://github.com/rust-lang/rust/blob/b2b7c859c1aae39d26884e760201f5e6c7feeff9/compiler/rustc_metadata/src/rmeta/encoder.rs#L726-L742)
* final binary artifact size (rlib, exe. etc)
* debug info (when separate)
Repository: TypeScript
Issue: JS files should parse as JS, not as JSX
Labels: Suggestion,Awaiting More Feedback

# Bug Report

### 🔎 Search Terms

TS1005 allowJS

### 🕗 Version & Regression Information

3.3.3

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about allowJS and TS1005
- I was unable to test this on prior versions because playground

### ⏯ Playground Link

https://www.typescriptlang.org/play?jsx=0&ts=3.3.3&filetype=js#code/C4JwrgpgPABA9AHQEZwHTAgZ2ACgER4CU8cMA8gNIBQokUiK6WuBxcpAYgIICSAMlSA

### 💻 Code

`tsc --allowJs --checkJs test.js`

```js
true< /\b/.test("") // OK
true</\b/.test("") // FAIL
```
This is a small reproducing example.
The real-world code causing this issue is: https://unpkg.com/froala-editor@4.0.3/js/froala_editor.min.js

### 🙁 Actual behavior

```
:2:2 - error TS1005: ';' expected.
:2:7 - error TS1127: Invalid character.
:2:10 - error TS1109: Expression expected.
```

### 🙂 Expected behavior

Compiles successfully, because line 1 and line 2 are semantically equal in JS.
Repository: transformers
Issue: BatchFeature should cast to `np.float32` by default
Labels: WIP

Currently the default dtype for Speech Feature Extractors is `numpy.float64` which leads to two problems:

1) It makes the data processing extremely expensive for the RAM. Many sound formats are stored in int16 (such as `.wav`) and are then transformed to float64 which unnecessarly increases RAM by a factor of 4. We should at least stick to `float32`
2) Currently we have added some hacks to the Wav2Vec2 and Speech2TextTransformer feature extractors to prevent Double vs. Float dtype mismatches: https://github.com/huggingface/transformers/blob/f6e254474cb4f90f8a168a599b9aaf3544c37890/src/transformers/models/wav2vec2/feature_extraction_wav2vec2.py#L87

The main problem is that `np.asarray([....])` by default creates a np.float64 array and that we just pass that format along.
=> We should either always cast to float32 in BatchFeature (see here: https://github.com/huggingface/transformers/blob/f6e254474cb4f90f8a168a599b9aaf3544c37890/src/transformers/feature_extraction_utils.py#L151) or add a flag `dtype` to BatchFeature.

@patrickvonplaten
Repository: material-ui
Issue: AccordionSummary first and last child's corners do not display as rounded 
Labels: new feature,component: accordion

When `AccordionSummary` is given an opaque background color, the first child's top-left/right and last child's bottom-left/right corners appear to be squared even though the `MuiAccordion-rounded:first-child` and `MuiAccordion-rounded:last-child` styles are correctly applied.  This occurs because the `AccordionSummary`'s corners are squared, stacking on top of the parent div (ie `Accordion`); when `AccordionSummary`'s background color is transparent, this does not cause an issue but when its background color is opaque, the first and last `Accordions`' corners will appear as squared.

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

When `AccordionSummary` is given an opaque background color, the first child's top-left/right and last child's bottom-left/right corners appear to be squared instead of rounded.

## Expected Behavior 🤔

Frist and last Accordion's corners should be rounded.

## Steps to Reproduce 🕹

Steps:
1.  Open the Simple accordion example in codesandbox.io - https://codesandbox.io/s/ccmf9 
2.  Note the first and last accordion's corners are rounded.
3.  Add `style={{backgroundColor:'blue'}}` to each of the `AccordionSummary` elements
4.  Corners are showing as squared.

## Context 🔦
`Accordion` display should be consistent and its first and last child's corner rounding should not be affected by the `AccordionSmmary`'s color.

## Your Environment 🌎
Material-ui Accordion demo example.
Repository: flutter
Issue: "Invalid cid" crash from Dart VM while building engine unit tests
Labels: engine,dependency: dart,P2,c: fatal crash,team-engine,triaged-engine

On the roll from Skia here https://github.com/flutter/engine/pull/27665, which is probably unrelated, but the immediately preceding commit was a Dart SDK roll here https://github.com/flutter/engine/pull/27663.

There are several such crashes in the logs linked from her:
https://ci.chromium.org/ui/p/flutter/builders/prod/Windows%20Web%20Engine/6106/overview
Repository: electron
Issue: [Feature Request]: Target a Display when fullscreen-ing a BrowserWindow
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Right now, the `win.setFullScreen()` method will fullscreen the window on its current display. There is no way to target a different display when fullscreening.

### Proposed Solution

Add an optional second "display" argument to the `setFullScreen()` method:

```javascript
win.setFullScreen(flag, display)
```

This would identify the target Display for fullscreening. When `win.setFullScreen(false)` is called, the BrowserWindow would return to it's original location on its original Display.

### Alternatives Considered

The current method for doing this is clunky.

```javascript
function fullScreenOnDisplay(win, disp) {
  const currentDisplay = screen.getDisplayMatching(win.getBounds())
  if (currentDisplay === disp) {
    // we're already on the right screen, no need to move
  } else {
    // we need to move the window to the correct screen before fullscreening
    // ensure that the window isn't already fullscreened
    win.setFullScreen(false)
    win.setPosition(disp.workArea.x, disp.workArea.y)
    // --- unnecessary window repaint happens here with non-fullscreen window on target display ---
  }
  win.setFullScreen(true)
}
```

**However**, when `win.setFullScreen(false)` is called, the window will end up on the target display and not in its original location.

### Additional Information

A few of the other BrowserWindow instance methods could be multi-screen aware as well.

`win.maximize()`
`win.center()`

and/or possbly a new method of:
`win.moveToDisplay(display)`