sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Add FileCheck annotations to MIR-opt tests
Labels: E-easy,A-testsuite,E-needs-test,T-compiler,E-help-wanted,A-mir-opt,E-tedious

The MIR-opt testsuite (`tests/mir-opt`) supports checking the MIR output using LLVM FileCheck tool. The purpose of this check is to write in the `.rs` file what we expect to see, similar to the annotations we have for ui tests. See individual commits in https://github.com/rust-lang/rust/pull/116810 for a few examples, and `tests/mir-opt/README.md` for tips in dealing with functions, locals and basic blocks.

Most testcases disable this using a `// skip-filecheck` comment. They should not.
We need to go through all the test cases in the MIR-opt suite to write these annotations.
Exception: the `tests/mir-opt/pre-codegen` does not need these directives, as its purpose is to track the quality of the MIR we emit.

Steps, for each test case:
- figure out what is being tested (that's sometimes not directly obvious, may need git archeology);
- write the FileCheck annotations based on the emitted MIR (see the MIR dumps to help).

In some cases, it may be interesting to strengthen the test cases to better verify what they meant to verify. This can be done by adding a `// unit-test: SomePassName` directive at the top, or changing compiler flags.

The point is to add check directives for what we want to check. Skipping storage statements, basic-block numbers, useless assignments is encouraged.

For volunteers: please post a comment with the files you want to work with. Please do not claim the whole issue, there is plenty to do. Please `r? cjgillot` in the PR so I can keep track of them.
Repository: rust
Issue: Tracking issue: `-Zreg-struct-return` support in `rustc`
Labels: T-compiler,C-tracking-issue,A-ABI,A-CLI,A-rust-for-linux

i.e. the equivalent of Clang's/GCC's `-freg-struct-return`. The kernel needs it to support the x86 32-bit architecture, together with [`-Zregparm=3`](https://github.com/rust-lang/rust/issues/116972).

It could potentially be a ["global target feature"](https://github.com/rust-lang/rust/issues/121970#issuecomment-1978605782), i.e. a target feature that is required to be set the same way for all compilation units.

- https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-freg-struct-return
- https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-freg-struct-return

### About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps

- [x] Implementation:
    - https://github.com/rust-lang/rust/pull/130777
- [ ] Adjust documentation ([see instructions on rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs))
- [ ] Stabilization PR ([see instructions on rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr))

### Unresolved Questions & Answers
- [ ] Q: Should it affect the Rust ABI? It cannot be documented as doing such, because the Rust ABI is unstable, but should it do so anyways as a quality-of-implementation matter?
     - **Currently**: We already do this for the Rust ABI implicitly, without needing a compiler flag: https://github.com/rust-lang/rust/issues/116973#issuecomment-1772741176
- [ ] Q: Should it affect *any* other ABIs than `"C"`, `"cdecl"`, and `"stdcall"`?
     - **Currently**: No.
     - **Alternatives**: It's not yet clear what ABIs this affects for gcc and clang.
- [ ] Q: Should it be accepted on any other architecture than x86_32?
     - **Currently**: No.
- [ ] Q: Does MSVC code use this?
Repository: godot
Issue: CharacterBody3D will not slide on slopes when stop on slopes is disabled.
Labels: bug,topic:physics,topic:3d

### Godot version

4.1.2 stable

### System information

Fedora Linux

### Issue description

While adding a velocity against the floor direction, the body will not slide correctly even with stop on slope disabled. The result is a jittery, slow movement.  In this simple example i'm applying gravity to a sphere, which i expect to slide along the floor, but it does not work:

![Gif1](https://github.com/godotengine/godot/assets/64601424/e5231c17-6a9f-43ce-bf77-54cce1a0c932)

Expected behavior, using a max angle of 0 so it does not treat it like a floor:

![gif2](https://github.com/godotengine/godot/assets/64601424/16edefa7-fb18-4d59-9703-c825a8397fae)



### Steps to reproduce

- Create a CharacterBody3D
-  Disable stop on slopes
-  Disable stop on walls (Just to be sure)
-  Add some gravity to the character body
-  Call move and slide
- The body does not slide.

### Minimal reproduction project

[CharacterBody3DBug.zip](https://github.com/godotengine/godot/files/13054180/CharacterBody3DBug.zip)
Repository: PowerToys
Issue: Manage multiple displays
Labels: Idea-Enhancement,Product-Window Manager,Needs-Triage

### Description of the new feature / enhancement

A tool to see which windows are open on which displays.
I have multiple monitors, which I do not always have switched on, or sometimes I am using one or two of my monitors on my laptop instead of my desktop. Windows sometimes opens windows on the monitors which are switched off or being used on another computer, this is very annoying. I would like a tool to see the open windows on my main monitor, and be able to move them between my monitors.

### Scenario when this would be used?

Windows opens windows sometimes on the monitors which are switched off or not in use, this is very annoying as I cannot see or use the window.

### Supporting information

_No response_
Repository: vscode
Issue: Getting incorrect language features in diff editor, from GHPRI
Labels: feature-request,typescript

When reviewing a PR and opening a file which was modified in it, you will get TypeScript language features in the right-hand side editor that are incorrect. Feels like a regression to me.

https://github.com/microsoft/vscode/assets/22350/c1b0418a-4c77-4ddd-bea4-e499b6b056c5

@hediet @alexr00 @mjbvz It's hard to gauge who should own this, sorry for the multiple assignment.
Repository: material-ui
Issue: [joy-ui]slider] Provide option to stop thumb from going outside of the rail
Labels: new feature,component: slider,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Currently for Joy UI (and Base and Material), the center of the thumb acts as the "value point". As a result, the thumb can go outside of the rail on either side for 50%.

There is no way to stop that behavior as far as I can find. It would be great if it was possible to create a variant that makes it so that the left edge of the thumb touching the left side of the rail acts as "0" and when it touches the right edge of the rail with its own right edge acts as "1" (or any other value given to it).

If a simple example could be created, that would be great too.

### Examples 🌈

One example of this is the color picker slider in iOS.

<img width="357" alt="image" src="https://github.com/mui/material-ui/assets/1693592/9b0c2894-5a2c-4fd8-814b-5cb085200ce1">


### Motivation 🔦

You don't always want the thumb to be able to leave the track. Additionally, the way the slider is designed makes it annoying to position it besides other elements with a flex layout/grid while using a gap, which causes the thumb to cross into the gap and makes for visual imbalance.
Repository: godot
Issue: ScrollContainer doesn't clip the focus highlight (at least on ItemLists) in editor tools
Labels: bug,needs testing,topic:gui

### Godot version

v4.2.beta2.mono.official [f8818f85e]

### System information

Godot v4.2.beta2.mono - Fedora Linux 38 (KDE Plasma) - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 570 Series (RADV POLARIS10) () - AMD Ryzen 5 2600 Six-Core Processor (12 Threads)

### Issue description

When clicking on an ItemList that's a child on a ScrollContainer that doesn't stretch all the way to the viewport in the editor tools, it doesn't clip the focus highlight.

![image](https://github.com/godotengine/godot/assets/8017858/f6a0789c-7cff-4eda-9887-cb49f241982a)

### Steps to reproduce

1. Open the attached project
2. On the upper-left dock, click on any item on the item list

### Minimal reproduction project

[FocusHighlightRecreation.zip](https://github.com/godotengine/godot/files/13055512/FocusHighlightRecreation.zip)
Repository: godot
Issue: Centering ColorRects; fill position gets integer rounded
Labels: discussion,topic:editor,needs testing,topic:gui

### Godot version

4.1.2

### System information

Windows 10

### Issue description

This isn't super consequential as I'm just using these ColorRects as UI placeholders but I noticed when trying to centre one, the fill position seems to get rounded so that it doesn't fit into the orange outline.

This is only noticeable at smaller pixel sizes, e.g. trying to centre a 40x40 rect in a 45x45 one (left) has a position of (2.5,2.5) set when centred.

![image](https://github.com/godotengine/godot/assets/4680342/fb70051a-eca1-4787-a2db-824c6a4a3c94)

The one on the right is a 41x41 rect in a 45x45 one so has a position of (2, 2) which centres nicely.

![image](https://github.com/godotengine/godot/assets/4680342/85d83267-9cf2-469d-8bbf-504acdbb2269)



### Steps to reproduce

1. Create a ColorRect node and set its size/custom minimum size to 45x45
2. Add a child ColorRect node; set its size/custom minimum size to 40x40
3. On the child node, choose the center anchor preset

### Minimal reproduction project

N/A
Repository: deno
Issue: LSP truncates complex typescript types
Labels: suggestion,lsp

the deno LSP truncates information from complex typescript types with `...` ellipses - i confirmed the same behaviour with both VSCode and emacs

<img width="765" alt="image" src="https://github.com/denoland/deno/assets/29339/f7bcfa67-77ed-4f1b-98cd-d9f2679eea07">

something similar happens with the vanilla typescript LSP - but there is a [workaround](https://github.com/Microsoft/TypeScript/issues/26238) available, at the possible expense of some performance

it would be great if deno had a similar ability to avoid truncation of type information
Repository: next.js
Issue: App Router and Pages Router with _app.getInitialProps breaks custom 404 page
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/vinnymac/nextjs-404-repro

### To Reproduce

1. Visit the [deployment](https://nextjs-404-repro-1lc4npnb5-vincent-feather.vercel.app/404) that has `_app.getInitialProps` defined
2. Then visit the [deployment](https://nextjs-404-repro-2ynd23q10-vincent-feather.vercel.app/404) that does not have `_app.getInitialProps` defined.
3. Notice that the custom 404 page (pages/404.js) only works when `_app.getInitialProps` is not defined.

Removing the `_app.getInitialProps` makes the 404 page load in production builds. See the few commits I made for some context: https://github.com/vinnymac/nextjs-404-repro/commits/main

Note: This issue is not reproducible in a dev environment, the custom 404 page only breaks when the application is built.

### Current vs. Expected behavior

Currently when using `_app.getInitialProps` in a production build, the existing custom 404 page isn't shown. This prevents incremental adoption of the App Router.

Expected: To see my custom 404 page (pages/404.js), even when both the Pages Router and App Router are in use, allowing for incremental adoption.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000
Binaries:
  Node: 18.17.1
  npm: 9.6.7
  Yarn: 3.6.3
  pnpm: N/A
Relevant Packages:
  next: 13.5.6
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

### Additional context

I tested the latest `next@canary` release and the issue still persists. See [deployment here](https://nextjs-404-repro-6oeycyc9z-vincent-feather.vercel.app/404)
Repository: rust
Issue: ice: symbol mangling v0 + `dyn_star`: `cannot be demangled`
Labels: I-ICE,T-compiler,C-bug,S-bug-has-test,requires-debug-assertions,F-dyn_star

<!--
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
build with `-Csymbol-mangling-version=v0`
```Rust
#![feature(dyn_star)]
#![allow(incomplete_features)]

use std::fmt::Display;

pub fn require_dyn_star_display(_: dyn* Display) {}

fn main() {
    require_dyn_star_display(1usize);
}
```


### 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`:
```
274455a9d1aae26b47d2757cdd41a74ec1b280f9
```

### Error output

```
<output>
```
Repository: godot
Issue: godot crashes uppon opening a project witht the forward+ renderer.
Labels: bug,topic:rendering,needs testing,crash

### Godot version

v4.1.2.stable.official [399c9dc39]

### System information

Godot v4.1.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - Intel(R) HD Graphics 520 (Intel Corporation; 26.20.100.7870) - Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (4 Threads)

### Issue description

double clicking the project or clicking the edit button creats a window which disappears shortly after. No error is thrown when running godot from the terminal (even after including the `--verbose` flag): [verbose terminal output when opening a project.txt](https://github.com/godotengine/godot/files/13055409/verbose.terminal.output.when.opening.a.project.txt)

Running godot with the `--renering-driver opengl3` works but you can't run the project. I found the command that runs the project while using the `--verbose` flag (`./Godot_v4.1.2-stable_win64.exe --verbose --path C:/Users/Lucas%20Kurosei/Library/Projects/Code/LeafVortex --remote-debug tcp://127.0.0.1:6007 --editor-pid 15280 --position 384,216 res://main.tscn`). Running said command on a seperate terminal after adding `--rendring-driver opengl3` works again but I haven't figured out how to make godot add that option automatically.

no issue arrises when using the compatibility renderer

a week ago I installed windows and my graphics driver with it so I'm pretty sure it's updated so that's out of the equation

### Steps to reproduce

I'm not really sure how one would reproduce the same issue without having the same graphics card. But ig you just create a forward+ project and try to edit it?

### Minimal reproduction project

[Learning Godot.zip](https://github.com/godotengine/godot/files/13055622/Learning.Godot.zip)

here it is. As I said, it's basically just an empty project lmao. Please lemme know if you need anymore info!
Repository: kubernetes
Issue: A container cannot restart when there is any terminating container in the same pod
Labels: kind/bug,sig/node,priority/important-longterm,triage/accepted

### What happened?

A terminated container cannot restart when there is any terminating container in the same pod.

/sig node

### What did you expect to happen?

I expect the terminated container can restart during another container's termination.

### How can we reproduce it (as minimally and precisely as possible)?

Make a pod with
- terminating-container: terminate because of the liveness failure
- restarting-container: exit immediately 

```yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: test
  name: test
spec:
  containers:
  - args:
    - bash
    - "-c"
    - |
      _term() {
        echo "terminating..." >> /shared/log
        sleep 15s
        echo "terminated" >> /shared/log
        exit 0
      }
      trap _term TERM
      exec sleep infinity & wait $!
    livenessProbe:
        exec:
          command:
          - "false"
        periodSeconds: 1
        failureThreshold: 1
    image: ubuntu
    name: terminating-container
    volumeMounts:
    - name: log
      mountPath: /shared
  - args:
    - bash
    - "-c"
    - echo "start a container" >> /shared/log
    image: ubuntu
    name: restarting-container
    volumeMounts:
    - name: log
      mountPath: /shared
  - args:
    - tail
    - -F
    - /shared/log
    image: ubuntu
    name: log
    volumeMounts:
    - name: log
      mountPath: /shared
  volumes:
  - name: log
    emptyDir: {}
```


```
$ kubectl logs test -c log -f
start a container
start a container
terminating...
terminated
start a container
terminating...
terminated
terminating...
terminated
start a container
terminating...
terminated
terminating...
terminated
start a container
terminating...
terminated
start a container
```

The result is saying that no container restarts during the termination.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.0
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: deno
Issue: Bug: Deno compiled app crashes on npm:@fastify/swagger
Labels: bug,compile,node compat,node API

Hi,
I created a Deno app, and I'm using `npm:fastify`.
All works well so far, except for one thing;

I added swagger plugin to the server, and when I run `Deno run` it works.
The problem starts when I compile my app, and then try to reach the swagger path (on `http://localhost:8000/docs`):

<img width="1286" alt="image" src="https://github.com/denoland/deno/assets/13683050/4fc0a982-515e-4c6f-8c21-d79a90f28238">


My deps.ts file:
```ts
/**
 * deps.ts
 *
 * This module re-exports the required methods from the dependant remote modules.
 */

import Fastify from "npm:fastify";
import pg from "npm:@fastify/postgres";
import swagger from "npm:@fastify/swagger";
import swaggerUI from "npm:@fastify/swagger-ui";

export { load } from "https://deno.land/std@0.204.0/dotenv/mod.ts";
export { Fastify, pg, swagger, swaggerUI };
```

and my main.ts:
```ts
import { load, Fastify, swagger, swaggerUI, pg } from "./deps.ts";

await load({ export: true });

export const server = Fastify({
  logger: true,
});

// Plugins
server.register(pg, {
  connectionString: `${Deno.env.get("DB_HOST")}://${Deno.env.get("DB_USER")}:${Deno.env.get("DB_PASSWORD")
    }@${Deno.env.get("DB_HOST")}:${Deno.env.get("DB_PORT")}/${Deno.env.get("DB_NAME")
    }`,
});
server.register(swagger, {});
server.register(swaggerUI, {
  routePrefix: "/docs",
});

// Run the app
if (import.meta.main) {
  try {
    await server.listen({ host: '0.0.0.0', port: 8000 });
  } catch (err) {
    server.log.error(err);
    Deno.exit(1);
  }
}
```

I guess this is a problem with the compatibility of Deno and Node, and I'd like to know how can I take care of it.
Thanks in advance!
Repository: rust
Issue: Error when implementing async method of another trait from another trait
Labels: F-async_fn_in_trait,T-types,fixed-by-next-solver

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
trait TraitOne {
    async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()>;
}

trait TraitTwo: TraitOne {
    async fn m4(&self, a: u32) -> Result<(), ()>;
    async fn m5(&self, b: String) -> Result<(), ()>;
}

impl<T: TraitTwo> TraitOne for T {
    async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()> {
        Ok(())
    }
}
fn main() {
    println!("hello world");
}
```

I expected to see this happen: the above should be able to compile as the `sync` version of that code can also be compiled (i.e. removing all `async` keywords from the example above)

Instead, this happened: it gave the following error below, where the signatures match exactly but compilation still gave an error.

```
❯ RUST_BACKTRACE=1 cargo run
   Compiling async-trait-err v0.1.0 (/home/vloh/projects/test-async-trait)
error[E0053]: method `m3` has an incompatible type for trait
  --> src/main.rs:11:5
   |
11 |     async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found future
   |
note: type in trait
  --> src/main.rs:2:5
   |
2  |     async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: expected signature `fn(&T, &mut W, _) -> impl Future<Output = Result<(), ()>>`
              found signature `fn(&T, &mut W, _) -> impl Future<Output = Result<(), ()>>`

For more information about this error, try `rustc --explain E0053`.
error: could not compile `async-trait-err` (bin "async-trait-err") due to previous error
```

### 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.75.0-nightly (4578435e1 2023-10-19)
binary: rustc
commit-hash: 4578435e1695863d921c7763d5a0add98f8e3869
commit-date: 2023-10-19
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.3
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>