sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: `unused_parens` false positives and false negatives in code containing macro calls
Labels: A-lints,T-compiler,C-bug,L-unused_parens

### Code

```rust
macro_rules! m1 {
    () => {
        1
    };
}

pub fn f1() -> u8 {
    // Lint says parens are not needed, but they are.
    (m1! {} + 1)
}

macro_rules! m2 {
    () => {
        loop { break 1; }
    };
}

pub fn f2() -> u8 {
    // Lint says parens are needed, but they are not.
    (m2!() + 1)
}
```

### Current output

```console
warning: unnecessary parentheses around block return value
 --> src/lib.rs:9:5
  |
9 |     (m1! {} + 1)
  |     ^          ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
9 -     (m1! {} + 1)
9 +     m1! {} + 1
  |
```

### Desired output

```console
warning: unnecessary parentheses around block return value
 --> src/lib.rs:20:5
   |
20 |     (m2!() + 1)
   |     ^         ^
   |
   = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
   |
20 -     (m2!() + 1)
20 +     m2!() + 1
   |
```

### Rationale and extra context

The code suggested by rustc does not compile, because that pair of parentheses really is required.

```console
error: leading `+` is not supported
 --> src/lib.rs:9:12
  |
9 |     m1! {} + 1
  |            ^ unexpected `+`
  |
help: try removing the `+`
  |
9 -     m1! {} + 1
9 +     m1! {}  1
  |

error[E0308]: mismatched types
 --> src/lib.rs:3:9
  |
3 |         1
  |         ^ expected `()`, found integer
...
9 |     m1! {} + 1
  |     ------ in this macro invocation
  |
  = note: this error originates in the macro `m1` (in Nightly builds, run with -Z macro-backtrace for more info)
```

### Anything else?

I found a partly related issue https://github.com/rust-lang/rust/issues/113563, in which @Nilstrieb writes:

> I don't think it's easy to fix this. The lint works on the finalized AST and can't really take into account the details of how the macro was expanded. The easiest solution here is to just put an `#[allow()]` inside the macro for now (which you've probably done already).

However, I have filed this as a distinct issue because I am hopeful that the case in this issue might be easier to fix than the other one, because this one involves parentheses that come from outside the macro call, as opposed to parentheses that come from inside the macro definition.
Repository: PowerToys
Issue: Environment Variables: cannot copy-paste values while creating profiles
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.76.2

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Environment Variables

### Steps to reproduce

1. Click "+ New Profile" button.
2. Click "+ Add Variable" button.
3. Select and copy prepared value from Notepad (or elsewhere).
4. Attempt to paste value into New Variable dialog.

### ✔️ Expected Behavior

Expect to be able to populate New Variable dialog fields using copy-paste from elsewhere, especially for longer variable names or paths that might be prone to spelling mistakes.

### ❌ Actual Behavior

New Variable dialog vanishes when it loses focus. It is no longer there to copy-paste values into.

### Other Software

_No response_
Repository: PowerToys
Issue: Can you make an extra package of Power Automate supported in PowerToys.
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

Can you make an extra package of Power Automate supported in PowerToys.

### Scenario when this would be used?

This would be used to make an extra package of Power Automate supported in PowerToys.

### Supporting information

_No response_
Repository: PowerToys
Issue: please consider including this tool for auto refocus mouse pointer w/ alt tab
Labels: Idea-New PowerToy,Needs-Triage,Product-Mouse Utilities

### Description of the new feature / enhancement

https://github.com/rhinterndorfer/MousePointerReposition

### Scenario when this would be used?

especially helpful if one has multiple monitors and is trying to alt tab to a window on a far away monitor - avoiding dragging the mouse from monitor 3 to monitor 1

### Supporting information

https://superuser.com/questions/1323942/keyboard-shortcut-for-moving-mouse-to-focused-window
Repository: rust
Issue: `exported_private_dependencies` lint only take effect in innermost dependency
Labels: A-lints,A-visibility,T-compiler,C-bug,L-exported_private_dependencies,F-public_private_dependencies

### Problem

The `exported_private_dependencies` lint only take affect in the innermost dependency in a recursively dependent environment.

This inspired by https://github.com/rust-lang/rust/issues/44663#issuecomment-1851227083.


### Steps

In order to prove this problem, I purposely contructed a code repository, [here](https://github.com/linyihai/recursive_pub_reexport)

in the repository,  the `crates` folder has three crates, 

- grandparent_dep, the init crate provied the pub struct 
- parent_dep, the middle crate, add `grandparent_dep` as public and reexport pub struct from grandparent_dep
- pub_dep, the outmost crate, add `parent_dep` as public and reexport pub struct from parent_dep

(the crates in `crates` can be treated as download from respority(like github, crates.io)) 

in src/lib.rs,  add `pub_dep` as dependency but private.

After downloading the resposity,

1、 run `cargo build`,  no lint warning message
2、 change the `public = false` in `crates/pub_dep/Cargo.toml`,  then run `cargo build`, no lint warning message
3、 change the `public = false` in `crates/parent_dep/Cargo.toml`,  run `cargo build`   and a lint warning message comes up.

```
cargo build
   Compiling parent_dep v0.1.0 (/root/workspace/recursive_pub_reexport/crates/parent_dep)
   Compiling pub_dep v0.1.0 (/root/workspace/recursive_pub_reexport/crates/pub_dep)
   Compiling simple v0.1.0 (/root/workspace/recursive_pub_reexport)
warning: type `FromPriv` from private dependency 'grandparent_dep' in public interface
 --> src/lib.rs:3:1
  |
3 | pub fn use_pub(_: pub_dep::FromPriv) {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(exported_private_dependencies)]` on by default
```






### Possible Solution(s)

The focus of this issue is to verify whether there is a problem with the current situation, so the solution will not be considered for the time being.  

### Notes

_No response_

### Version

```text
cargo 1.76.0-nightly (623b78849 2023-12-02)
release: 1.76.0-nightly
commit-hash: 623b788496b3e51dc2f9282373cf0f6971a229b5
commit-date: 2023-12-02
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.4.0-DEV (sys:0.4.68+curl-8.4.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Ubuntu 22.04 (jammy) [64-bit]
```
Repository: go
Issue: runtime: add fast paths for common `select` patterns
Labels: Performance,NeedsInvestigation,compiler/runtime

This select:

```
select {
case <-closedCh: // or otherwise any channel for which the receive won't block
case <-nilCh: // e.g. context.Background().Done()
}
```

should, ideally, be as fast as this one:

```
select {
case <-closedCh: // or otherwise any channel for which the receive won't block
default:
}
```

This is currently not the case though, with the latter being over 2 orders of magnitude faster under contention, and almost 1 with no contention.

```
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
                              │    sec/op     │
Select/closed+nil-16             126.6n ±  2%
Select/closed+default-16        0.8886n ± 10%
Select/closed+nil                53.27n ±  0%
Select/closed+default            6.306n ±  0%
```

In `selectgo` there is a (pretty old) comment that claims that the code in the first example is ["rare enough" that it is not worth optimizing for](https://github.com/golang/go/blob/b25f5558c69140deb652337afaab5c1186cd0ff1/src/runtime/select.go#L161-L163). I would argue that at least in code I write and maintain, a two-cases `select` with one of the cases being `<-ctx.Done()` is pretty common. This would be especially beneficial in libraries, where the library normally has no control over which `Context` it is passed by the host application, and where the compiler would likely be unable to statically determine that the channel is nil.

AFAICT, to address this, `selectgo` could - [after counting how many non-nil cases exist](https://github.com/golang/go/blob/b25f5558c69140deb652337afaab5c1186cd0ff1/src/runtime/select.go#L166-L180) - dispatch directly to `chansend`/`chanrecv` if there is only one non-nil case. This would be somewhat similar to what the compiler does for simple cases, but done dynamically instead of statically.

---

*update*: I actually [tried it out](https://go-review.googlesource.com/c/go/+/553355/1), and to achieve the speedup it is also going to require extending the fast paths in `chanrecv`/`chansend`, but the results are promising:

```
Select/closed+nil-16        2.360n ±  1%
Select/closed+default-16   0.8645n ± 10%
Select/closed+nil           17.84n ±  1%
Select/closed+default       6.302n ±  0%
```

---

```
go version go1.21.1 darwin/amd64
```
Repository: next.js
Issue: Custom server config not working
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/next-js-custom-server-bug-6z8fhc

### To Reproduce

1. Create a basic next js application by running `npx create-next-app@latest`.
2. `cd` into the new directory and add a basic `server.js` file in the root directory with these content: 
```js
const { createServer } = require("http");
const { parse } = require("url");
const fs = require("fs");
const path = require("path");

const next = require("next");

const dev = process.env.NODE_ENV !== "production";
const hostname = "localhost";
const port = 3600;

const app = next({
    dev,
    hostname,
    port,
    conf: {
        distDir: ".custom_dist",
    }
});

const handle = app.getRequestHandler();

app.prepare()
    .then(() => {
        const server = createServer(async (req, res) => {
            try {
                const parsedUrl = parse(req.url || "", true);
                const { pathname, query } = parsedUrl;

                await handle(req, res, parsedUrl);
            } catch (err) {
                console.error("Error occurred handling", req.url, err);
                res.statusCode = 500;
                res.end("internal server error");
            }
        });

        server.on("error", (err) => {
            console.error("⚠️ SERVER ERROR =>", err.message);
        });

        server.listen(port, () => {
            console.log(`> Ready on http://${hostname}:${port}`);
        });
    })
    .catch((error) => {
        console.log(error);
    });
```
3. Run `node server.js` to start the development server.

### Current vs. Expected behavior

### Expectation
When the development server is started, the dist directory should be loaded from the `conf` property in the `next` function argument, and there should be a new folder in the root directory named `.custom_dist`.

### Current Behavior
The default `.next` directory is used instead of the specified `.custom_dist` directory. 

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.0.4
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

This bug appeared with Next 13. I'm currently running Next 12 on my apps to avoid this bug.
Repository: material-ui
Issue: [List][material-next] Add all List* components
Labels: component: list,design: material you

 ### Summary 💡
 This issue is to track the work for adding the List* component to @mui/material-next, moving forward with the Material you effort (#29345)



 * [x]  Copy component files from material (v5) to material-next: PR: https://github.com/mui/material-ui/pull/40367
 * [ ]  Remove deprecated components and componentsProps props (not applicable, the component already uses the `slots` & `slotProps` props (**WIP**) PR: https://github.com/mui/material-ui/pull/40406
 * [ ]  Ensure slots & slotProps have keys for each slot  (**WIP**) PR: https://github.com/mui/material-ui/pull/40406
 * [ ]  Drop support for ThemeProvider in favor of CssVarsProvider  (**WIP**) [PR: https://github.com/mui/material-ui/pull/40406
 * [ ]  Migrate component to Typescript   (**WIP**)
 * [ ]  Implement Material You design specs  (**WIP**)
 * [ ]  Add component playground to v5 docs  (**WIP**)
 * [ ]  Refactor styles to use component CSS Variables  (**WIP**)
 
 **Note**: If a task is marked as [WIP] it means someone is working on it
Repository: PowerToys
Issue: Text Extractor Crashes PowerToys
Labels: Issue-Bug,Product-Settings,Needs-Team-Response,Severity-Medium

### Microsoft PowerToys version

v0.76.2

### Installation method

WinGet

### Running as admin

Yes

### Area(s) with issue?

TextExtractor

### Steps to reproduce

When selecting Text Extractor from PowerToys Settings the application crashes.
Using keyboard short-cut to open Text Extractor does nothing. This might be related to: #22033. As I am facing the same issue simuatelously. 




### ✔️ Expected Behavior

I expect to see Text Extractor settings.

### ❌ Actual Behavior

See below:

![PowerToys Settings_ezTynK0ERt](https://github.com/microsoft/PowerToys/assets/12242398/c0b63bae-3f72-47de-8526-e26f9adbd2be)

### Other Software

_No response_
Repository: transformers
Issue: Add Mixture of Tokens model
Labels: New model

### Model description

Mixture of Tokens is a new architecture / technique proposed in [Mixture of Tokens: Efficient LLMs through Cross-Example Aggregation](https://arxiv.org/abs/2310.15961) and accompanying [blog](https://llm-random.github.io/posts/mixture_of_tokens/) by Szymon Antoniak, Sebastian Jaszczur et al.

It builds on expert-choice MoE, aggregating across sequences in a batch rather than positions in a sequence, and doing so in a continuous fashion. This full differentiability is its main advantage, bringing training stability and even expert utilization.

In collaboration with the authors, we (me + 3 others) would like to add a PyTorch implementation matching the architecture from the paper to HF transformers and later publish corresponding checkpoints. We believe this will make it significantly easier for the community to experiment with this approach, as the original implementation is quite dense and contained in an active research repo.

We believe a good approach is to start from the GPT2 HF model. We will have the assistance of the original authors for making sure the details match.

Please advise:
1.  If you have any general suggestions at this stage
2. What kinds of tests you would like to see in the finalized implementation for this case, where the exact snapshot corresponding to the paper's implementation and the checkpoints were not  previously published.
3.  If you have general suggestions regarding contributing methods that are potentially applicable to multiple base models  (like MoE and MoT).

As we understand, the next step is for us to create a template with https://github.com/huggingface/transformers/tree/main/templates/adding_a_new_model and get coding.



### Open source status

- [X] The model implementation is available
- [ ] The model weights are available

### Provide useful links for the implementation

https://github.com/llm-random/llm-random

https://github.com/sebastianjaszczur

https://llm-random.github.io/posts/mixture_of_tokens/
Repository: godot
Issue: Enabling SSIL causes error spam in scenes with SubViewport when SubViewport.size is too small
Labels: bug,topic:rendering,confirmed,topic:3d

### Tested versions

Reproducible in 4.2.1 stable

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 SUPER (NVIDIA; 31.0.15.4617) - AMD Ryzen 5 1600 Six-Core Processor (12 Threads)

### Issue description

Under certain conditions the editor starts spamming error messages:

```
Too many mipmaps requested for texture format and dimensions (6), maximum allowed: (5).
  drivers/vulkan/rendering_device_vulkan.cpp:8627 - Attempted to name invalid ID: 0
  servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp:75 - Condition "p_named_texture.texture.is_null()" is true.
  drivers/vulkan/rendering_device_vulkan.cpp:3317 - Parameter "src_tex" is null.
  servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp:419 - Condition "named_texture.texture.is_null()" is true. Returning: RID()
  Texture (binding: 0, index 0) is not a valid texture.
  ./servers/rendering/renderer_rd/uniform_set_cache_rd.h:129 - Condition "rid.is_null()" is true. Returning: rid
  drivers/vulkan/rendering_device_vulkan.cpp:7970 - Parameter "uniform_set" is null.
  Uniforms were never supplied for set (3) at the time of drawing, which are required by the pipeline
  Uniforms were never supplied for set (3) at the time of drawing, which are required by the pipeline
  Uniforms were never supplied for set (3) at the time of drawing, which are required by the pipeline
  Uniforms were never supplied for set (3) at the time of drawing, which are required by the pipeline
  servers/rendering/renderer_rd/storage_rd/render_scene_buffers_rd.cpp:419 - Condition "named_texture.texture.is_null()" is true. Returning: RID()
  Image (binding: 0) should provide one ID referencing a texture (IDs provided: 0).
```

Conditions seem to be:
   WorldEnvironment is present and SSIL is enabled
   SubViewport (with Camera attached) is present and **both** x and y values of Subviewport.size property are smaller than 32 px (so for example 1x32 px will work fine, 1x31 will not).

### Steps to reproduce

Create new project and build this hierarchy:

```
Node3D
    ┠╴WorldEnvironment
    ┖╴SubViewport
       ┖╴Camera3D
```

Add default environment, enable SSIL. Go to SubViewport, set both x and y values of size property to be smaller than 32 px. Errors should start to appear even without running the project.

### Minimal reproduction project (MRP)

[SSILbug.zip](https://github.com/godotengine/godot/files/13797765/SSILbug.zip)
Repository: godot
Issue: Often, when I open and save a scene that has nodes assigned to exported node properties, the reference is replaced with an instance in the scene source
Labels: topic:editor,needs testing,topic:dotnet

### Tested versions

- Reproducable in v4.2.1.stable.mono.official [b09f793f5]
- I've seen this happen in older versions of Godot 4 as well

### System information

Windows 11 - v4.2.1.stable.mono.official [b09f793f5] - Mobile renderer

### Issue description

Often, when I open and save a scene (without changing anything manually) that has nodes assigned to exported node properties, references are replaced with an instance in the scene source. When subsequently working with the editor or running the game, the reference is regarded to be severed (the editor says it has nothing assigned and runtime null references occur).

The following diff screenshot should illustrate what I mean:

![image](https://github.com/godotengine/godot/assets/260737/44a0eeb6-5734-4455-a96e-a0a418ac8953)

This is a short version of the `Teleport` script, which is behind the affected nodes:

```csharp
[Tool]
public partial class Teleport : PanelContainer
{
    [Export]
    public Teleport? Destination { get; set; }
}
```

The described problem doesn't happen all the time but more often than not.

Also, I've seen seen the same happen with other nodes in other scenes in my project. Many times, my game crashes for me to again find out that a node has lost is reference (e.g. to the Player node) and I have to hit Assign in the editor to re-attach it. I haven't checked the diffs there but I think that the reference got replaced by an instance as well.

### Steps to reproduce

Open and immediately save a scene with nodes in it that have scripts with exported properties that point to other nodes in the scene. There's probably much more to it that I can't grasp just yet.

### Minimal reproduction project (MRP)

I've set up a minimal reproduction project I haven't been able to put in the right things to trigger the bug yet. My original project is way too large to post here.
Repository: godot
Issue: Dropdown selection in Project settings is behind the project settings windows
Labels: bug,platform:macos,topic:editor,topic:gui

### Tested versions

v4.2.stable.official [46dc27791]

### System information

Mac OS Ventura - v4.2 

### Issue description

I open Godot in fullscreen mode in my Mac .
I tried editing my project settings, and this happens.

<img width="380" alt="Screenshot 2023-12-30 at 8 26 33 PM" src="https://github.com/godotengine/godot/assets/50512341/e29126b3-163e-46a4-9eb8-9e9a6cd3a91f">


This only happens in fullscreen mode.

### Steps to reproduce

1. Open Godot
2. Enter Fullscreen mode
3. Go to `Project Setting -> Display -> Window`
4. Try edit VSync mode. 

> [!NOTE]
>
> Any dropdown selection in the project setting will cause this, just that VSync mode option's dropdown is long enough to go outside of the project setting windows. And also, sometime, the bug won't trigger the first time triggering the dropdown selection.

### Minimal reproduction project (MRP)

[clone.zip](https://github.com/godotengine/godot/files/13798049/clone.zip)
Repository: next.js
Issue: style is not applied in index.html by output:'export'
Labels: bug

### Link to the code that reproduces this issue

https://github.com/Negin-ozn/next-issue

### To Reproduce

1. I created a next 14 project : npx create-next-app@latest
2. I wanted to use its static mode by adding :
const nextConfig = {
  output: 'export',
}
module.exports = nextConfig
3. Then I run yarn build and see the out folder
4. When I opened the index.html file in out folder the styles (tailwind) did not apply 
5. I had some errors in console like: Access to CSS stylesheet at 'file:///_next/static/css/d9c1932c9f423671.css' from origin 'null'
6.  and this is the output without style
<img width="520" alt="image (1)" src="https://github.com/vercel/next.js/assets/71718899/4adc0f7f-b38a-4b0f-97d2-c22a0ec2c7e0">



### Current vs. Expected behavior

I expected to have the page with all styles in index.html like when I run it on local server like this:
<img width="474" alt="image (2)" src="https://github.com/vercel/next.js/assets/71718899/62378873-0748-4dd7-8ad2-fba01e595a71">


### 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: x64
  Version: Darwin Kernel Version 22.6.0: Wed Oct  4 21:25:26 PDT 2023; root:xnu-8796.141.3.701.17~4/RELEASE_X86_64
Binaries:
  Node: 20.8.1
  npm: 9.8.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.0.4
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: export
```


### Which area(s) are affected? (Select all that apply)

App Router, Static HTML Export (output: "export")

### Additional context

_No response_