sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Compiler error with custom test framework
Labels: I-ICE,T-compiler,C-bug,S-needs-repro

<!--
Thank you for finding an Internal Compiler Error! 🧊  If possible, try to provide
a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for
how to create smaller examples.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

-->

### Code

```
#![allow(unused)]
#![feature(custom_test_frameworks)]
#![test_runner(my_runner)]

fn main() {
fn my_runner(tests: &[&i32]) {
    for t in tests {
        if **t == 0 {
            println!("PASSED");
        } else {
            println!("FAILED");
        }
    }
}

#[test_case]
const WILL_PASS: i32 = 0;

#[test_case]
const WILL_FAIL: i32 = 4;
}


```


### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.54.0 (a178d0322 2021-07-26)
binary: rustc
commit-hash: a178d0322ce20e33eac124758e837cbd80a6f633
commit-date: 2021-07-26
host: x86_64-unknown-linux-gnu
release: 1.54.0
LLVM version: 12.0.1
```

### Error output

```
<output>
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary><strong>Backtrace</strong></summary>
<p>

```
Compiling custom_test_framework v0.1.0 (/root/works/rust_escapades/custom_test_framework)
thread 'rustc' panicked at 'expected Item', compiler/rustc_expand/src/base.rs:132:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-
bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.54.0 (a178d0322 2021-07-26) running on x86_64-unknown-linux-gnu
note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
end of query stack
error: could not compile `custom_test_framework`
```

</p>
</details>
Repository: vscode
Issue: Can't drag markdown cells in edit mode
Labels: bug,notebook-dnd


Issue Type: <b>Bug</b>


Create a new blank Jupyter Notebook file - there should be a single python cell
Create a new markdown cell

#### With the bug
Moving your cursor anywhere around the edge of the cell will turn it into the grab icon
However, attempting to actually click and drag will not do anything

#### Expected behavior
I expect that if the cursor shows a grab icon, I will be able to drag the cell to other places in the notebook
(I also expect that the grabable area will be the same for Python and Markdown cells, but that's very minor by comparison)

Extension version: 2021.8.1195043623
VS Code version: Code 1.59.0 (379476f0e13988d90fab105c5c19e7abc8b1dea8, 2021-08-04T23:13:12.822Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz (4 x 3312)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|23.93GB (13.67GB free)|
|Process Argv|--crash-reporter-id f182f946-40ce-4a2a-949c-5d5e83a8c3a7|
|Screen Reader|no|
|VM|0%|
</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
pythonvspyt678:30270856
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscorecescf:30322572
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200:30340761
vscextlang:30333561
binariesv615:30325510
vsccppwtct:30329789
pythonvssor306:30344512
bridge0708:30335490
vstre464:30346472

```

</details>

<!-- generated by issue reporter -->
Repository: material-ui
Issue: [system] `style` function is not aptly named
Labels: discussion,package: system

- [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.

[Related issue](https://github.com/mui-org/material-ui/pull/27618)

## Summary 💡

The `style` function from `@mui/system` is ambiguous and undocumented.

Better names for `style`:
`createSystemProp`
`createStyleProp`

Proposed solution: 
1. Rename the existing `style` function to `unstable_style`.
2. Create a new function with name matching one of the above.
3. Document this function, potentially including the [styled-system](https://styled-system.com/custom-props/) docs.
4. Party 🎉
Repository: material-ui
Issue: [system] Propagate custom `style` props to component SxProps.
Labels: new feature,package: system

- [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 💡

- Custom props created using `style` aren't propagated to the SxProps which enhances each MUI component.  While the SxProps prop technically works with any valid CSS, the theme-aware transformers aren't applied.

## Examples 🌈
```
import {Box} from "@material-ui/core"
import styled from "@emotion/styled"
import {style} from "@material-ui/system"

const bgStyle = style({
  cssProperty: "backgroundColor"
  prop: "bg",
  themeKey: "palette",
})

const CustomBox = styled(Box)`
  ${bgStyle};
`

// doesn't work
<CustomBox sx={{bg: "background.primary"}} />
```

One way to get it working today would be to create a custom Sx function and then override the default Sx prop on each component.  

What if we provided additional transformers at the ThemeProvider level?  Perhaps we could expose a method to override [getThemeValue](https://github.com/mui-org/material-ui/blob/next/packages/material-ui-system/src/getThemeValue.js) globally?

Updated example*
Repository: TypeScript
Issue: Inlay hints look awkward for callback parameters with a single parameter
Labels: Suggestion,Help Wanted,Experience Enhancement,Fix Available,Rescheduled,Domain: Inlay Hints

When you have a callback whose parameter has no parentheses, inlay hints starts to look a little bit weird.

For example, in this code

```ts
            return hints.map(hint => ({
                ...hint,
                position: scriptInfo.positionToLineOffset(hint.position),
            }));
```

you get the following:

![image](https://user-images.githubusercontent.com/972891/128792954-f0024bcc-63aa-427a-943d-f96d3092e204.png)

Ideally, you'd see that line rewritten as

````
callbackfn: (hint: InlayHint) => ({
```
Repository: vscode
Issue: [Bug] `"merge-conflict.diffViewPosition": "Below"` opens multiple diff editors
Labels: bug,merge-conflict

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->

Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->

- VS Code Version: v1.60.0-insider
- OS Version: Windows 10

Steps to Reproduce:

With `"merge-conflict.diffViewPosition": "Beside"` (keeps one diff editor open):

![STG 2021-08-10 09_31_02](https://user-images.githubusercontent.com/28700378/128794749-f16273ea-3521-4d4e-8643-2729e1241680.gif)

With `"merge-conflict.diffViewPosition": "Below"` (opens multiple diff editors):

![STG 2021-08-10 09_33_19](https://user-images.githubusercontent.com/28700378/128794882-d975763d-1e62-48b5-a261-bb81e2b141a0.gif)
Repository: godot
Issue: AtlasTexture cannot save video memory
Labels: bug,topic:rendering,documentation

### Godot version

3.3.2 stable

### System information

Windows 10, GLES3, GeForce GTX 1660 SUPER/PCIe/SSE2

### Issue description

AtlasTexture cannot save video memory

### Steps to reproduce

```
var img = Image.new()

func _ready():
  img.create(10000, 10000, false, Image.FORMAT_RGB8)
  img.fill(Color.red)
  
  var texture = ImageTexture.new()
  texture.create_from_image(img, 0)
  
  var use_altas = true
  
  if use_altas:
    $Sprite.texture = AtlasTexture.new()
    $Sprite.texture.region = Rect2(0, 0, 100, 100)
    $Sprite.texture.atlas = texture
    # will still cost 300MB video memory
  else:
    $Sprite.texture = texture
    # will cost 300MB video memory
    
  print("%1.0fMB" % (Performance.get_monitor(Performance.RENDER_VIDEO_MEM_USED) / 1000 / 1000))
```

### Minimal reproduction project

[AtlasTextureBug.zip](https://github.com/godotengine/godot/files/6958331/AtlasTextureBug.zip)
Repository: godot
Issue: Portals: Unexpected room bounds generated
Labels: bug,topic:rendering,topic:3d

### Godot version

3.x (0403cb8ad)

### System information

macOS 11.5.1

### Issue description

One corner of the generated room bounds of my room is at an unexpected place. The room should be a cube shape.

The corner will be at the expected place after deleting the large portal in the front.

![screenshot](https://user-images.githubusercontent.com/372476/128806846-fcaad0f5-5715-4ac8-a034-7f575a964964.png)

### Steps to reproduce

Open the MRP in the editor and click "Convert Rooms" to see the green bounds.

### Minimal reproduction project

[QuickHull.zip](https://github.com/godotengine/godot/files/6958846/QuickHull.zip)
Repository: rust
Issue: `Instant::duration_since` returns a shortened duration if a suspend occurred
Labels: T-libs-api,T-libs,C-discussion,A-time

`Instant::now` currently uses `CLOCK_MONOTONIC`, which stops ticking during suspend. This means that creating a `Duration` via `Instant::duration_since` will be notably shorter than expected if the system suspended between the `&self` instance and the `earlier` argument.

If `CLOCK_BOOTTIME` is used instead, the clock is guaranteed to continue ticking during suspend. This closer matches the documentation and real world usage of `Instant`. The documentation for `Instant::duration_since` reads "Returns the amount of time elapsed from another instant to this one." - no mention of an exception for suspend or other low power states. `tokio` uses `Instant` to govern its sleep and timeout functionality. Given that `tokio` is commonly used to implement network servers and clients, slicing out suspended time was likely not their intention.

Using `CLOCK_BOOTTIME` should have minimal impact on existing usage. Performance-wise, `CLOCK_BOOTTIME` is implemented in Linux by getting the `CLOCK_MONOTONIC` time and adding an offset to it. That offset is updated as part of exiting suspend. As a result, the total cost should be an extra two loads , two adds, and maybe two stores with bad optimization, which are all negligible compared to the cost of servicing a system call. In terms of existing applications, the only ones which will see new behavior is ones which are measuring time across suspends. The only use case I can think of for wanting the old `CLOCK_MONOTONIC` behavior is time-multiplexing system resources, but I am not aware of an actual user.

## Other projects on the same issue
* Go decided against [switching its runtime](https://github.com/golang/go/issues/24595) to use `CLOCK_BOOTTIME` due to  
* Linux [converted](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6ed449afdb38f89a7b38ec50e367559e1b8f71f) `CLOCK_MONOTONIC` to act like `CLOCK_BOOTTIME` since it was almost always the desired behavior, and technically spec compatible, but [reverted](https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/a3ed0e4393d6885b4af7ce84b437dc696490a530) it shortly afterwards due to compatibility issues.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"hellow554"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: grid_sample should not require grid to be the same dimension as input.
Labels: module: nn,triaged,enhancement,module: interpolation

## 🚀 Feature

`grid_sample` requires `input` and `grid` to have the same dimensions, such that given input `[B, C, H, W]`, the grid must be `[B, H', W', 2]`. 

However, this restriction is not necessary. Given input `[B, C, H, W]`, why can't the grid be `[B, D, 2]` if I simply want the output to be one-dimensional.

## Motivation

There are cases where we want the grid output to be in a different dimension as the input, but the current `grid_sample` function does not directly allow that. We can work around it (see below), but it would be nice to support it natively.

Currently, in PyTorch3D, we need it for volumetric rendering.

## Pitch

Change the `grid_sample` function to accept arbitrary dimensions for the `grid`.
For 4D input `[B, C, H, W]`, 2D grid `[B, D, 2]` should be valid. 5D grid `[B, D, H, W, 2]` should be valid, and grid `[B, ..., 2]` should be valid.
For 5D input `[B, C, D, H, W]`, 2D grid [B, D, 3]` should be valid. 4D grid `[B, H, W, 3]` should be valid, and grid `[B, ..., 3]` should be valid.

## Alternatives

The current workaround is to the change `[B, D, 2]` grid to `[B, D, 1, 2]` by inserting a new dimension. After grid sampling, we can remove the extra dimension from output `[B, C, D, 1]` to `[B, C, D]`.



cc @albanD @mruberry @jbschlosser
Repository: storybook
Issue: globalTypes does not work properly with Composition
Labels: bug,composition,args

**Describe the bug**
A clear and concise description of what the bug is.

When using composition, the global toolbar options appear, but the default value is not set, when you update the value, the story doesn't re-render. This situation is slightly improved if you create the globalType in the global storybook preview.js file, as it sets the default value, and will update the global value in the url.

Checking the Console Logs, I see:

```
received globals from a non-local ref. This is not currently supported.
```

**To Reproduce**
Please create a reproduction by running `npx sb@next repro` and following the instructions. Read our [documentation](https://storybook.js.org/docs/react/contribute/how-to-reproduce) to learn more about creating reproductions.
Paste your repository and deployed reproduction here. We prioritize issues with reproductions over those without.

1. Create a Core Storybook, and a Composition Storybook
2. Define in preview.js in composition storybook.
  ```js
  export const globalTypes = {
    locale: {
      name: 'locale',
      description: 'Locale',
      defaultValue: 'en-NZ',
      toolbar: {
        icon: 'globe',
        items: [
          { value: 'keys', title: 'keys' },
          { value: 'en-NZ', title: 'en-NZ' },
          { value: 'zh-CN', title: 'zh-CN' },
          { value: 'ru-RU', title: 'ru-RU' },
        ],
      },
    },
  };
  ```
3. Define a Story that uses globals:
  ```js
  const Story = (args, ctx) => {
    const locale = ctx.globals.locale;
    return <p>{locale}</p>;
  };
  ```
4. Use the toolbar to update the value, notice it doesn't update the story, and it doesn't update the url, and it doesn't even set the toolbar highlight.
5. Define in preview.js in core storybook.
  ```js
  export const globalTypes = {
    locale: {
      name: 'locale',
      description: 'Locale',
      defaultValue: 'en-NZ',
    },
  };
  ```
6. Notice that now the toolbar now highlights, and the url updates, but the story does not reload.

**System**
Please paste the results of `npx sb@next info` here.

```
npm: 7.15.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22000.1.0), Chromium (92.0.902.67)
  npmPackages:
    @storybook/addon-essentials: ^6.3.6 => 6.3.6
    @storybook/addon-links: ^6.3.6 => 6.3.6    @storybook/react: ^6.3.6 => 6.3.6
```

**Additional context**
Add any other context about the problem here.
Repository: electron
Issue: [Feature Request]: Documentation for debugging of preload scripts
Labels: enhancement :sparkles:,documentation :notebook:

### 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

Please consider adding an explicit statement to the "[Testing and Debugging](https://www.electronjs.org/docs/latest/)" section of the documentation as to whether it is known and/or expected that a debugger **cannot** be used on **preload** scripts?   

Given the security risks of enabling the `nodeIntegration` flag, preload scripts (with context bridging) could become a more commonly used approach to provide a better native application experience.

If `console.log` is the only way to debug preload scripts, that should be stated.

There are many dozens of questions out there asking how to debug preload scripts, but they are all either unanswered, or the response describes how to debug a renderer (as opposed to a preload script).

This [issue #12863](https://github.com/electron/electron/issues/12863) has the most concise and accurate example I've seen of the problem (and incorporates best practice of both node and context isolation).  But it was closed without a clear statement of whether this is a defect or a "feature".


### Proposed Solution

I would be happy to provide a PR updating the "[Testing and Debugging](https://www.electronjs.org/docs/latest/)" section of the documentation, if someone on the Electron team could provide official feedback on the question of whether this is even possible.


### Alternatives Considered

N/A

### Additional Information

N/A
Repository: neovim
Issue: PyPy freezes nvim on windows
Labels: status:blocked-external,platform:windows,provider

### Neovim Version

v0.5.0-dev+1283-g59eae3b38

### Operating system/version:

Windows 10

### Terminal name/version:

NA

### TERM environment variable

NA

### Installation

Repo release

### Steps to reproduce

1. `:let g:python3_host_prog="pypy3"`
2. `:py3 print("test")`

### Vim

_No response_

### Expected behavior

Echoes "test"

### Actual behavior

Editor freezes.

`:checkhealth provider` gives
```
## Python 3 provider (optional)
  - INFO: Using: g:python3_host_prog = "pypy3"
  - INFO: Executable: C:\tools\pypy3.7-v7.3.5-win64\pypy3.EXE
  - INFO: Python version: 3.7.10^M
  - INFO: pynvim version: 0.4.3^M
  - OK: Latest pynvim is installed.
```

PyPy installed from https://downloads.python.org/pypy/pypy3.7-v7.3.5-win64.zip

Works fine on Linux.
Repository: material-ui
Issue: [AvatarGroup] Clickable "ellipsis"
Labels: new feature,component: avatar

Unable to click last item on Avatar Group
how do I solve this problem ?
Repository: rust
Issue: rustdoc does not consider (complicated?) trait bounds for listing blanket implementations
Labels: T-rustdoc,C-bug

See for example https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/gio/struct.FileInputStream.html#blanket-implementations

In short the relevant code looks as follows

```rust
struct FileInputStream { ... }
impl IsA<InputStream> for FileInputStream { ... }

trait InputStreamExt { ... }
impl<T: IsA<InputStream>> InputStreamExt for T { ... }
```

rustdoc is correctly listing for `FileInputStream` the `IsA<InputStream>` impl and also various blanket impls, but not the `InputStreamExt` blanket impl that also applies to it.

Some blanket impls with trait bounds (e.g. `impl<T> Cast for T where T: ObjectType`) are listed so there must be something about the specific trait bound that is confusing rustdoc.
Repository: vscode
Issue: VS code not preventing MacOS sleep
Labels: feature-request

Issue Type: <b>Feature Request</b>

Hello,

I've been using MS VS code studio for a while, and I really like it. It's my IDE of choice currently.

I've noticed an issue in macOS though -- the app does not prevent macOS from sleeping. This means that, while code is running / debugging etc, macOS automatic sleep (for instance after 5mins of inactivity) is not prevented.

Yesterday I also noticed automatic macOS restarts are not prevented by the app when code is running -- a Python experiment I was running for the night got cancelled because macOS updated, and VS code did not stop it.

Please add functionality to prevent such sleeps/restarts jeopardising running code (only allow them when no code is running or when debug is paused at a breakpoint or so).

Best

VS Code version: Code 1.59.0 (Universal) (379476f0e13988d90fab105c5c19e7abc8b1dea8, 2021-08-04T23:14:40.191Z)
OS version: Darwin arm64 20.6.0
Restricted Mode: No


<!-- generated by issue reporter -->
Repository: rust
Issue: rustdoc should maybe only consider trait definitions and not trait impls for the search
Labels: T-rustdoc,C-feature-request,A-rustdoc-search,A-rustdoc-js

See for example https://doc.rust-lang.org/std/?search=fmt . This shows the `Debug::fmt` impl of each of these types, which can easily get quite noisy and make it hard to spot that actually it's the `Debug::fmt` somewhere at the top that is the origin of all the results.

In addition, rustdoc only lists the `Debug::fmt` impls of each of the types but not the `Display::fmt` impl, which is also quite inconsistent.