sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: TableRow: Hover Background - Value Provided is Out of Range
Labels: new feature,design: material,component: table

- [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 using less transparent selected/hover opacities within a custom theme, the TableRow component causes an out of range error when it attempts to create the hover background-color alpha:

```
MUI: The value provided 1.4 is out of range [0, 1]. 
    in MuiTableRowRoot (created by TableRow)
```

Here's the line throwing the error:
https://github.com/mui-org/material-ui/blob/master/packages/mui-material/src/TableRow/TableRow.js#L43

## Expected Behavior 🤔

First instinct is to simply not get an error, similar to the other components that create alphas based on the theme's opacities. 

If the case is that opacities need to be 0.5 or below, I would expect a range warning. I've been using these thick action opacities as long as I have been using custom themes. 

## Steps to Reproduce 🕹

Steps:

1. Set the selectedOpacity and hoverOpacity to values over 0.5
2. Create a table and sprinkle in some TableRow components
3. Check the console for out of range errors

Here'e my CodeSandbox reproducing this exact error:
https://codesandbox.io/s/blue-glade-329so?file=/src/theme.js

## Your Environment 🌎

Same as the Codesandbox.
@mui/material 5.0.2
Repository: angular
Issue: Produce a warning in case i18n markers are used for bindings
Labels: feature,area: i18n,hotlist: error messages,area: compiler,feature: in backlog

### Which @angular/* package(s) are relevant/releated to the feature request?

compiler

### Description

Angular i18n marker for attributes/properties work for static fields only (and fields with interpolations), so the following code would work (the i18n message will be extracted):

```
<div title="Hello" i18n-title></div>
```
However if the `title` becomes a binding, the i18n extraction would not pick it up:
```
<div [title]="myTitleBinding" i18n-title></div>
```
Which works as intended (only static attribute values can be localized via i18n markers), but there is no indication during the build process that the `i18n-title` would basically be ignored.

We should consider adding a non-blocking compile-time warning (throwing an error might be too strong, though this might be configurable?) to let users known that the `[title]` would not be localized.

Relevant part of code:
https://github.com/angular/angular/blob/9a6bd264ab25c274387a93ec73b648858a07b301/packages/compiler/src/render3/view/i18n/meta.ts#L107-L116
Repository: terminal
Issue: [Feature Request] Ability to rename the context menu entry
Labels: Product-Terminal,Issue-Task,Area-ShellExtension

Currently the context menu entry is hardcoded to "Open in Windows Terminal Preview" for the preview version.
This is very long string compared to everything else on the menu and therefore extends the width of the whole menu, so if possible please add an option to the settings to rename the context menu entry, or just change the default string to something smaller.
![image](https://user-images.githubusercontent.com/43749640/137556213-4ad8534e-ee51-400c-be3b-9221cd741dd7.png)
Repository: electron
Issue: [Bug]: Electron app is getting unsnapped on restore from minimize
Labels: platform/windows,bug :beetle:,status/confirmed,has-repro-gist,27-x-y,28-x-y,29-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/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.

### Electron Version

13.1.7

### What operating system are you using?

Windows

### Operating System Version

Windows 11 Dev Insider

### What arch are you using?

x64

### Last Known Working Electron version

Unsure

### Expected Behavior

1. Snap Electron app window through WIN+Left/Right, dragging, or with hovering on the maximize button to get the snap options.
2. Minimize the window.
3. Click on the window through the taskbar to pull it up again.

**Expected behavior:**  Electron window stays snapped.

### Actual Behavior

1. Snap Electron app window through WIN+Left/Right, dragging, or with hovering on the maximize button to get the snap options.
2. Minimize the window.
3. Click on the window through the taskbar to pull it up again.

**Actual behavior:**  Electron window gets unsnapped, visible because the corners are rounded instead of sharp. 

### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: godot
Issue: Undo/redo shortcut key doesn't work with camera transform changes
Labels: bug,topic:editor,needs testing,topic:3d

### Godot version

3.3.3 stable

### System information

Windows 7 64-bit

### Issue description

Trying to undo adjustments to camera transforms doesn't work properly and can only be undo/redo-ed from the Scene > Undo/Redo menu. I'll move or rotate the camera (either preview mode or not) and undo albums never works, it even says `Undo: Translate
Redo: Translate` in the Output, but it isn't doing anything until I use the menu.

### Steps to reproduce

- Create a camera.
- Move or rotate it a few times.
- Try to use Ctrl+z or Ctrl+Shift+Z.

I tried to reproduce this in a minimal project, but it's working properly in that. The only difference I had in my broken scene is I added a script to the scene root and have a gltf in the scene with it, but I don't know how to reliably reproduce this.

### Minimal reproduction project

[undobug.zip](https://github.com/godotengine/godot/files/7356274/undobug.zip)
Repository: rust
Issue: By-reference variables in closures may have wrong aliasing information
Labels: I-slow,A-closures,C-bug,C-optimization

A check for division by zero is not optimized out, despite `assert_ne!(0, div);` outside of the loop *if* the closure captures by reference rather than by move.

```rust
pub fn closure_alias(div: u32) -> Vec<u32> {
    let mut out = Vec::new();        
    assert_ne!(0, div);
    out.extend((0..100).map(|x| x / div));  // a branch to "attempt to divide by zero" panic exists here
    out
}
```

The same code with a move closure optimizes as expected:

```rust
pub fn closure_alias(div: u32) -> Vec<u32> {
    let mut out = Vec::new();        
    assert_ne!(0, div);
    out.extend((0..100).map(move |x| x / div));  // Now LLVM knows that div != 0
    out
}
```

I expected both to optimize the same, because the captured variable is not mutated. 

[godbolt link](https://rust.godbolt.org/z/WqKqxbeT7)

When the loop is unrolled, the first iteration does not have a div/0 panic branch, only later ones have. Perhaps LLVM gets incomplete aliasing information? (`&out` aliasing `&div`?)

### Meta

rustc 1.55 and rustc 1.57.0-nightly (e1e9319d9 2021-10-14).
Repository: material-ui
Issue: [system] Allow `theme.spacing()` to return a number
Labels: new feature,package: system

## Motivation 🔦

I love the spacing utility function because it makes keeping spacing consistent throughout an application very easy, but in some cases, I want to tweak the value returned by it a little. This is currently quite difficult because the function always returns a string with `"px"` appended to it.
Currently, if I want to, for example, add 2 to the return value of the spacing function, I would have to do something like this:
```js
`${Number(theme.spacing(3).slice(0, -2)) + 2}px`
```
I did check to see if the spacing value provided to `createTheme()` was exposed anywhere in the `Theme` object, but it didn't look like it was.

- [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.

## Summary 💡

There should be some way (possibly a fifth argument?) to make the spacing function return a number. If this isn't possible, then the spacing multiplier value provided to `createTheme()` should be exposed somewhere in the `Theme` object so that developers can use it to do the multiplication themselves.
Repository: PowerToys
Issue: [request] Quick run circular / pie menu for mouse only control
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

I think it would be really handy, to have a GUI like PowerToys Run but as a "mouse" controlled concept, where you can define entries (you maybe can give Symbols/Icons too), when you click them with the mouse, it will execute a command, open a program, or execute a keyboard shortcut.

### Scenario when this would be used?

There are several key bindings build into Windows, which are hard to remember or annoying to press. 

Lets say there was a function like PowerToys Run, you could bind to mouse4/5 for example. Pressing it would open a GUI centered on the screen, where you can click with the mouse on entries/icons, which then executes commands you bound to those entries, or emulate a keybinding shortcut.

Example:

Just a quick Google search as a "design" idea what I mean.

https://github.com/dawiidio/o-menu

You could add pie parts and extend the pie outwards adding more layers like an onion and put on each pie a different icon/color and a command to execute or a emulated keypress/shortcut.

This could also be handy on tablets.

### Supporting information

_No response_
Repository: pytorch
Issue: torch.nn.EmbeddingBag behave differently in two cases of cpu and cuda
Labels: module: error checking,triaged,module: embedding

## 🐛 Bug

`torch.nn.EmbeddingBag` will raise an RuntimeError when using cpu, but it will pass without any problem when using cuda.

## To Reproduce

```python
import torch
def cpu():
  api = torch.nn.EmbeddingBag(10,3,mode="sum",)
  tensor1 = torch.randint(-32768,1,torch.Size([8]), dtype=torch.int64)
  tensor2 = torch.randint(-32768,32768,torch.Size([2]), dtype=torch.int64)
  res = api(tensor1,tensor2)
  
def cuda():
  api = torch.nn.EmbeddingBag(10,3,mode="sum",).cuda()
  tensor1 = torch.randint(-32768,1,torch.Size([8]), dtype=torch.int64).cuda()
  tensor2 = torch.randint(-32768,32768,torch.Size([2]), dtype=torch.int64).cuda()
  res = api(tensor1,tensor2)

cuda()
print("CUDA PASS!")
cpu()
```

## Expected behavior

They should have the same behavior.

## Environment

 - PyTorch Version (e.g., 1.0): 1.9.0
 - OS (e.g., Linux): Linux
 - Python version: 3.7
 - CUDA/cuDNN version: 11.4/8.2.2
 - GPU models and configuration: RTX 3060
Repository: pytorch
Issue: torch.nn.functional.embedding behave differently in two cases of cpu and cuda
Labels: module: error checking,triaged,module: embedding

## 🐛 Bug

`torch.nn.functional.embedding` raises an error that `IndexError: index out of range in self` when using cpu, but it passes normally when using cuda.

## To Reproduce

```python
import torch
def cpu():
  input = torch.randint(-32768,1,torch.Size([3, 6]), dtype=torch.int64)
  weight = torch.rand(torch.Size([2, 1024]), dtype=torch.float32)
  res = torch.nn.functional.embedding(input, weight)
  
def cuda():
  input = torch.randint(-32768,1,torch.Size([3, 6]), dtype=torch.int64).cuda()
  weight = torch.rand(torch.Size([2, 1024]), dtype=torch.float32).cuda()
  res = torch.nn.functional.embedding(input, weight)

cuda()
print("CUDA PASS!")
cpu()
```

## Expected behavior

It should behave consistently in these two cases.

## Environment

- PyTorch Version (e.g., 1.0): 1.9.0
- OS (e.g., Linux): Linux
- Python version: 3.7
- CUDA/cuDNN version: 11.4/8.2.2
- GPU models and configuration: RTX 3060
Repository: rust
Issue: improve diagnostic for passing sub-array instead of slice
Labels: A-diagnostics,T-compiler

Given the following code: <!-- Please provide a link to play.rust-lang.org -->


[playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f5006503c3e88fb372a4a02e31d6373c)

```rust
fn foo() {
    let buf = [0u8; 100];
    println!("value of a is {:?}", buf[0..2]);
}
```

The current output is:

```
error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
   --> src/lib.rs:5:5
    |
5   |     println!("value of a is {:?}", buf[0..2]);
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `[u8]`
    = note: this error originates in the macro `$crate::format_args_nl` (in Nightly builds, run with -Z macro-backtrace for more info)
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
5   |     println!("value of a is {:?}", buf[0..2]);
    |                                    ^^^^^^^^^   consider &buf[0..2]
```
Repository: deno
Issue: Per-`JsRuntime` maps in `ProcState`
Labels: cli,refactor,runtime

Module maps are conceptually specific to an instance of `JsRuntime`, yet part of the module map mechanics in our current implementation is maintained in `ProcState`, which is shared across multiple `JsRuntime`s. An implementation of #12248 would need `ProcState` to keep a per-`JsRuntime` url → blob map, and according to @bartlomieju, something similar would be needed to cache resolved modules.

One issue is how to represent `JsRuntime` identity in those maps. `JsRuntime` is not cloneable or a reference type, and it is not typically used with a reference-counted pointer type. What's more, if a `JsRuntime` is dropped ­–if a worker is terminated, for example– the blob references and cached modules associated with that `JsRuntime` should be dropped as well, but there doesn't seem to be any obvious way to do this, since `JsRuntime` has no concept of `ProcState`.
Repository: TypeScript
Issue: Allow bigint as an index type because number is allowed too
Labels: Suggestion,Awaiting More Feedback

# Suggestion

The bigint type currently is not allowed as an index type requiring an explicit string cast.

```ts
const n = 100n;

const obj = {};
obj[n] = 1;
```

In JS, it's automatically cast as a string. This is what happens with numbers too. If numbers are automatically cast to strings, then why not allow bigint to be indexable as well? It would avoid having to explicitly cast all the time when it's not necessary in JS.

## 🔍 Search Terms

bigint index

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

Just make bigint indexable.

## 📃 Motivating Example

```ts
const n = 100n;

const obj = {};
obj[n] = 1;
```
Repository: rust
Issue: Some normalisations during MIR opts may be unnecessary
Labels: A-mir-opt,T-types

https://github.com/rust-lang/rust/pull/85254 normalises all types at the beginning of MIR optimizations.

As a consequence, we can remove some normalizations in other mir opts, e.g. https://github.com/rust-lang/rust/blob/6cc0a764e082d9c0abcf37a768d5889247ba13e2/compiler/rustc_mir_transform/src/inline.rs#L258

_Originally posted by @lcnr in https://github.com/rust-lang/rust/issues/85254#issuecomment-944880884_
Repository: node
Issue: piping request to fs write stream consume 100% CPU
Labels: fs

### Version

v16.11.1

### Platform

4.18.0-240.10.1.el8_3.x86_64

### Subsystem

fs

### What steps will reproduce the bug?

using this simple script:

```
import HTTP from 'http';
import FS from 'fs';

HTTP.createServer(req => {
	const ws = FS.createWriteStream('/home/file');
	req.on('end', () => ws.close()).pipe(ws);
}).listen('127.0.0.1', '80');
```

cause 100% CPU usage on main loop while writing 30MB per second. 

![image](https://user-images.githubusercontent.com/163890/137583010-651639da-6af3-423a-bb12-202d13a61a55.png)

in htop the disk is almost 0 for several samples and it suddenly get to the size of the file. it's like node does not write anything till the request ends.

![image](https://user-images.githubusercontent.com/163890/137583087-d61de99d-de74-4102-afe2-6bc5775285f1.png)
Repository: rust
Issue: `SpecExtend` for `TrustedLen` is unsound
Labels: I-unsound,C-bug,A-iterators,requires-nightly,T-libs

```rust
#![feature(trusted_len)]
use std::iter::TrustedLen;
use std::marker::PhantomData;

pub struct MaybeTrusted<'a, I>(I, PhantomData<fn(&'a ()) -> &'a ()>);

impl<'a, I: Iterator> Iterator for MaybeTrusted<'a, I> {
    type Item = I::Item;
    fn next(&mut self) -> Option<Self::Item> {
        self.0.next()
    }

    fn size_hint(&self) -> (usize, Option<usize>) {
        self.0.size_hint()
    }
}

/// This is safe, as a `'static` version of this struct can only be created
/// using a trusted iterator.
unsafe impl<I: Iterator> TrustedLen for MaybeTrusted<'static, I> {}
impl<I: TrustedLen> MaybeTrusted<'static, I> {
    pub fn new(value: I) -> Self {
        MaybeTrusted(value, PhantomData)
    }
}

/// `I` might not implement `TrustedLen`, but that's ok,
/// because you can't get a `MaybeTrusted<'static, I>` from this.
pub fn not_trusted<I: Iterator, T>(i: I, f: impl for<'a> FnOnce(MaybeTrusted<'a, I>) -> T) -> T {
    f(MaybeTrusted(i, PhantomData))
}

// In a separate crate:

struct Liar(usize);
impl Iterator for Liar {
    type Item = usize;
    fn next(&mut self) -> Option<Self::Item> {
        if self.0 < 10000 {
            self.0 += 1;
            Some(self.0)
        } else {
            None
        }
    }

    fn size_hint(&self) -> (usize, Option<usize>) {
        // happy little accident, but ok, doesn't implemented `TrustedLen`.
        let len = self.0.saturating_sub(10000);
        (len, Some(len))
    }
}

fn main() {
    not_trusted(Liar(0), |iter| iter.collect::<Vec<_>>());
}
```
results in:
```
Segmentation fault (core dumped)
```
Repository: godot
Issue: [3.3/3.4b] «2D Pixel» preset glitch in 3D
Labels: bug,confirmed,topic:import,regression,topic:3d

### Godot version

both 3.3.4 stable and 3.4 beta 6

### System information

Windows 10, GLES3, RTX 2070 Super (472.12)

### Issue description

When loading some voxel textures into Godot and applying the "2D Pixel" import preset, texture artefacts occur. 
It does not depend on the type of model: dae, obj or fbx.

There are no such problems when loading in Blender etc.

Blender:
![blender](https://user-images.githubusercontent.com/3815426/137592338-5d4922fb-ceb3-4932-aa7e-cf8e43984579.png)

Godot:
![godot](https://user-images.githubusercontent.com/3815426/137592341-44cd3d8a-4f64-4f7e-bb15-c7182c8b315f.png)




### Steps to reproduce

Import throne sample model from ZIP to Godot project. 
Apply "2D Pixel" preset to PNG texture, reimport it and apply to model.

### Minimal reproduction project

[throne.zip](https://github.com/godotengine/godot/files/7357744/throne.zip)
[Throne_sample.zip](https://github.com/godotengine/godot/files/7357774/Throne_sample.zip)
Repository: PowerToys
Issue: App-specific zooming. (FancyZone integration?)
Labels: Idea-New PowerToy,Area-Accessibility

### Description of the new feature / enhancement

I have a few applications that have very poor zooming features (e.g. CTRL-Mouse wheel, Settings Global Font, etc.).

I'd love to be able to mark an app with an independent zoom level, so I could have a tiny-fonted app run at 150% magnification, for example.

Perhaps integrated with FancyZones. We can all agree that FanzyZones is god-tear amazing, right?

Have a zone that's 150% zoom for anything *docked* in it. It doesn't need to support undocked apps, so it's not like a live magnified region.

### Scenario when this would be used?

Large, high DPI monitors, apps missing 'pseudo-standard accessibility features'. Old eyes.

### Supporting information

Win 10, 4K monitor. 100% zoom at OS level, but want higher zooms for apps. Think browser remembering zoom levels per-domain.
Repository: TypeScript
Issue: Let (value-space) `typeof` give a more specific type than the union of all `typeof` types
Labels: Suggestion,In Discussion

# Suggestion

## 🔍 Search Terms

typeof typeof string literal value redeclare

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

If a value is known to be a particular primitive type or union of types, such as `string` or `number | string`, `typeof typeof` should give back the exact string literal type, such as `"string"` or `"number" | "string"`, respectively.

In other words: TypeScript should give a more specific type than just `string` if `typeof <value>` would be known to give back one of >=1 string literals.

## 📃 Motivating Example

When a variable is meant to store the result of a `typeof` expression, TypeScript should be able to infer its string literal type, not just that it's a `string` primitive.

There should be no errors in this code:

```ts
let myTypeOf: 'number' | 'string';
myTypeOf = typeof 'abc';
myTypeOf = typeof 123;
```

Today:

```
Type '"string" | "number" | "bigint" | "boolean" | "symbol" | "undefined" | "object" | "function"' is not assignable to type '"string" | "number"'.
  Type '"bigint"' is not assignable to type '"string" | "number"'.
```

## 💻 Use Cases

See this variable declaration: https://github.com/typescript-eslint/typescript-eslint/pull/3891/files#diff-8a7d4566dbe9356145e8b86ccefa6d7a164c0b77818beb78d789e1089e9c4bc4R39

Ideally we would want to call it `let memberType: 'noInitializer' | 'number' | 'string' | undefined`, but later on `typeof member.initializer.value` gives back `string` instead of `'number' | 'string'`.

Edit: this also causes https://github.com/typescript-eslint/typescript-eslint/issues/3453, so perhaps this borders on a bug?