sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Spaces are rendered twice as wide when using nimsum
Labels: bug,windows,font-rendering

<!-- ⚠️⚠️ 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:1.65.2
- OS Version:

Steps to Reproduce:

Serif font "space" takes to 2 charactor spaces, where it should only take one charactor space.
This does not happen in other IDEs like Visual Studio 2022 or Pycharm.
You can refer to the screenshots attached, in which the code is the same, only the fonts are different.


![consolas_font_screenshot](https://user-images.githubusercontent.com/28250495/163687422-700cc3b7-c2d5-4a41-bbf0-86cefb704afc.png)
![serif_font_screenshot](https://user-images.githubusercontent.com/28250495/163687425-decc001c-12c2-4eb0-8acd-a2fb871a92f6.png)
Repository: rust
Issue: UdpSocket requires bind at all costs causing unnecessary permission prompt on macos
Labels: C-bug,T-libs,A-io

<!--
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
use std::net::UdpSocket;
use std::net::Ipv4Addr;

fn main() {
        let socket = UdpSocket::bind((Ipv4Addr::new(0, 0, 0, 0), 0)).expect("Failed to create socket");
        socket.set_broadcast(true).expect("Failed to enable broadcast");
        socket.send_to(b"TEST", (Ipv4Addr::BROADCAST, 9998)).expect("Failed to send broadcast packet");
}
```

I expected to see this happen: no permission prompt because the socket is never EVER used for listening, but only for sending a BROADCAST packet.

Instead, this happened: permission prompt for listening on macOS because bind was requested...

EDIT: I propose to add a new function (maybe `UdpSocket::new`) to create an UdpSocket without binding to any address to cover this use case.

### 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.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-apple-darwin
release: 1.59.0
LLVM version: 13.0.0
```
</details>
Repository: rust
Issue: Closure in async block fails to compile when it should, issues incorrect/misleading diagnostic
Labels: C-bug,A-async-await,AsyncAwait-Triaged

I've put the code reproducing this issue in the [cdhowie/warp-lifetime-issue-repro](https://github.com/cdhowie/warp-lifetime-issue-repro) repository as it has a dependency on warp.  I have not been able to build a reproduction of this issue outside of warp or rocket-rs, but I believe the issue is with the compiler nonetheless, for a few reasons.  I have been able to reproduce the issue on all of the following Rust Docker images:

* docker.io/library/rust:1.59-bullseye (d6c4db7b2530)
* docker.io/library/rust:1.60-bullseye (5593c6ce4c4e)
* docker.io/rustlang/rust:nightly-bullseye (cf477c958fa3 -- 1.62.0-nightly (e7575f967 2022-04-14))

The summary is that passing a very simple non-capturing closure in an async route handler causes a lifetime mismatch error, referencing a type that is not used or demanded in the handler:

```
error[E0308]: mismatched types
   --> src/main.rs:39:6
    |
39  |     .and_then(|_id, provider: Arc<T>| async move {
    |      ^^^^^^^^ lifetime mismatch
    |
    = note: expected type `for<'r> FnOnce<(&&Item,)>`
               found type `for<'r> FnOnce<(&'r &Item,)>`
note: this closure does not fulfill the lifetime requirements
   --> src/main.rs:42:41
    |
42  |         let items = items.iter().filter(|item| !item.is_deleted());
    |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^
note: the lifetime requirement is introduced here
   --> /appsrc/.cache/registry/src/github.com-1ecc6299db9ec823/warp-0.3.2/src/filter/mod.rs:259:32
    |
259 |         F::Output: TryFuture + Send,
    |                                ^^^^
```

Nowhere in the handler is an `FnOnce` built, nor is one asked for by `Iterator::filter()` so at the very least the diagnostic is misleading.  However, rewriting the code to use a free function instead of a closure allows the code to compile:

```
fn item_is_not_deleted(item: &&Item) -> bool {
    !item.is_deleted()
}

// Replace line 42 with:

let items = items.iter().filter(item_is_not_deleted);
```

I can't see any reason why a closure should fail here but a free function should work; I'd expect them to be effectively identical since the closure doesn't capture anything from its environment.

For more specific details, see the repository linked above.  (I'm happy to copy the repro code directly into this issue if desired, just let me know.)
Repository: storybook
Issue: `sb@next repro` should use npm, not yarn
Labels: maintenance,cli

**Describe the bug**
yarn is an outdated package manager that many people have migrated away from. Why is it being used in the `repro` tool?

**To Reproduce**
Run `npx sb@next repro` on a system without yarn and watch it fail.

**Additional context**
Why not use `npm`? Everyone has that installed already.
Repository: pytorch
Issue: FSDP remove the requirement of all trainable parameters  
Labels: high priority,oncall: distributed,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

There are some cases that the model may have some fixed/untrainable parameters which should not be updated (.

In this case, the FSDP will raise the exception at https://github.com/pytorch/pytorch/blob/0df2e863fbd5993a7b9e652910792bd21a516ff3/torch/distributed/fsdp/flatten_params_wrapper.py#L363

assert (len(set(p.requires_grad for p in params)) == 1
        ), "expects all parameters to have same requires_grad"

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @pietern @SciPioneer
Repository: go
Issue: cmd/compile: Support `make jobserver` for dynamic negotiable concurreny during compilation
Labels: help wanted,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.12.2 gccgo
</pre>

### Does this issue reproduce with the latest release?
**Not tested**


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/builder/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/builder/go"
GOPROXY=""
GORACE=""
GOROOT="/usr"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/gcc/x86_64-linux-gnu/9"
GCCGO="/usr/bin/x86_64-linux-gnu-gccgo-9"
CC="/opt/miniconda3/envs/builder/bin/x86_64-conda-linux-gnu-cc"
CXX="/opt/miniconda3/envs/builder/bin/x86_64-conda-linux-gnu-c++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build646202173=/tmp/go-build -gno-record-gcc-switches -funwind-tables"
</pre></details>

### What did you do?
* Clone five independent packages
* Compile each with say 2 threads
* Observer number of threads
* It goes down from 10 (max possible) to 5 (minimum)



### What did you expect to see?
* Using a single workstation as CI server allows orchestration of concurrency during compilation of multiple independent packages
* Compiling go with other languages plays well in regards to optimal utilization of CPU cores



### What did you see instead?
* Controlling max threads in a single go compile process is possible
* Sharing of threads between independent go compile process is not possible
* Ensuring that 5 or so independent compile processes are keeping 8 CPU's fully stocked is not feasible.

### Possible solution
Implement support for GNU make jobserver for compilation. This doesn't have to be exposed for 80-90% of users whose primary use-case doesn't involve parallel independent compilation of go packages.

Bonus: Both compilation and testing can benefit from this

Pro:
* Works with make, ninja-cmake and other related build and meta build systems
* Works cross-platform on systems with sockets (all modern systems targeted by go as compilation platforms based on expectation of pulling dependencies automatically)
* Parity with compilation process of compilers like C/C++ (clang, gcc), rust (cargo)
* Allows power users to perform quick context switches during compilation and testing
* Allows people working on polyglot code bases a significant boost (a lot of tech stacks are not pure go)

Con:
* jobserver has drawbacks (the pipe could have been closed, env variables need to be passed into sub-shells (not a concern here, but often a source of errors))
* more complicated process for spawning sub-processes
* maybe low utilization in go community
Repository: rust
Issue: Tracking Issue for `slice::Split::as_slice()`
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(split_as_slice)]`

This is a tracking issue for:

Converting an iterator produced by `.split(...)` which is not fully consumed, into a slice, matching the APIs for `.split(...)` on `String`s.

### Public API


```rust
let a = [1,2,3];
let mut iter = a.split(|i| i == 2);
assert!(iter.next().is_some());
assert_eq!(iter.as_slice(), &[3]);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #92287
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

Add impl:
```
#[stable(feature = "split_as_slice", since = "1.0.0")]
impl<'a, T: 'a, P: FnMut(&T) -> bool> AsRef<[T]> for Split<'a, T, P> {
    fn as_ref(&self) -> &'a [T] {
        self.as_slice()
    }
}
```
Repository: flutter
Issue: [Tool] Doctor should warn on non-ideal git configuration of the Flutter repo
Labels: c: new feature,tool,c: proposal,P3,team-tool,triaged-tool

The Flutter tool does not support the upgrade operation on the following configurations of the user's local Flutter repository:

- The current checkout is on a "Detached HEAD" state.
- The current checkout does not have an upstream.
- The checkout is not tracking an official upstream(aka "[standard remote](https://github.com/flutter/flutter/blob/aa5d7b6972ee5be596c15b83d39f7d3dde6ad939/packages/flutter_tools/lib/src/version.dart#L387-L389)").

However, the doctor output still shows a `✓` for such cases in the Flutter section.

<details>
<summary>An example</summary>
<pre>
$ ./bin/flutter doctor
Building flutter tool...
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, 2.13.0-0.0.pre.601, on Artix Linux 5.17.3-artix1-1, locale en_IN.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[!] Android Studio (not installed)
[✓] Connected device (2 available)
[✓] HTTP Host Availability

! Doctor found issues in 1 category.

$ git checkout HEAD^1
Note: switching to 'HEAD^1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
...

$ ./bin/flutter doctor
Building flutter tool...
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel unknown, 2.13.0-0.0.pre.600, on Artix Linux 5.17.3-artix1-1, locale en_IN.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[!] Android Studio (not installed)
[✓] Connected device (2 available)
[✓] HTTP Host Availability

! Doctor found issues in 1 category.

$ ./bin/flutter upgrade
Unable to upgrade Flutter: Your Flutter checkout is currently not on a release branch.
Use "flutter channel" to switch to an official channel, and retry. Alternatively, re-install Flutter by going to https://flutter.dev/docs/get-started/install.
</pre>
</details>

## Proposal

Highlight that the current install has issues with the git configuration by showing a `!` in those cases.
Repository: react
Issue: Bug: Internal React error: Expected static flag was missing
Labels: Type: Bug,Status: Unconfirmed

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: V18.0.0
React router DOM: V5.2.1

## Steps To Reproduce

1. Going to profile page
2. Warning: Internal React error: Expected static flag was missing. Please notify the React team.

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example:
![Screenshot 2022-04-17 124859](https://user-images.githubusercontent.com/51002164/163707500-3ee1ca51-9695-4e2e-b3c4-3f5e8f7a98b3.png)
DynamicFilter.js component
![Screenshot 2022-04-17 125107](https://user-images.githubusercontent.com/51002164/163707576-b8536b98-3b47-4c7e-84f3-abfa9f93dddf.png)


<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior


## The expected behavior
Repository: storybook
Issue: Provide `user = userEvent.setup()` to Play function
Labels: feature request,test utilities

**Is your feature request related to a problem? Please describe**

`user-event@14` allows to create a session per `userEvent.setup()`.
The methods on the object share an input device state. I.e.:
```js
  const user = userEvent.setup()
  await user.keyboard('{Shift>}')
  await user.click(screen.getElementByRole('button')) // This would be a click with shiftKey=true
```

Applying `.setup()` and using these methods [is recommended](https://testing-library.com/docs/user-event/setup).

**Describe the solution you'd like**

Add `user` to `renderContext.storyContext` during [the `rendering` phase](https://github.com/storybookjs/storybook/blob/3e1874a82d725d27e9ea2321c7114df3ac47cca1/lib/preview-web/src/StoryRender.ts#L193-L195).

This should probably be injected by `@storybook/testing-library`.

Being able to get `user` per `play: ({user}) => { /*... */ }` would encourage people to use the recommended approach because it would also be the easiest.

**Are you able to assist to bring the feature to reality?**

Yes, I can add the necessary code if someone can guide me through your codebase and package structure.

**Additional context**

I've experimented with Storybook `6.5-alpha` and the developer experience improved a lot as many things work out of the box.
It would be great if this change could be added in `6.5` along with the upgrade in https://github.com/storybookjs/testing-library/pull/18 .
Repository: rust
Issue: higher ranked lifetimes not recognized by type alias impl trait
Labels: A-impl-trait,C-bug,F-type_alias_impl_trait,T-types,A-higher-ranked

The following snippet fails

```rust
#![feature(type_alias_impl_trait)]
trait Trait<'a> { type Out: 'a;}
impl<'a> Trait<'a> for i32 { type Out = String;}
type A = impl for<'a> Trait<'a, Out = impl Sized + 'a>;
fn foo() -> A {
    0_i32
}

```

The error is

```
error: non-defining opaque type use in defining scope
 --> src/lib.rs:6:5
  |
6 |     0_i32
  |     ^^^^^
  |
note: used non-generic lifetime `'a` for generic parameter
 --> src/lib.rs:4:52
  |
4 | type A = impl for<'a> Trait<'a, Out = impl Sized + 'a>;
  |                                                    ^^
```

_Originally posted by @oli-obk in https://github.com/rust-lang/rust/pull/96094#discussion_r851747321_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: getSystemProxyURI does not support NO_PROXY env variable
Labels: feature-request,proxy

<!-- ⚠️⚠️ 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/No

<!-- 🪓 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. -->
- Version: VS Code Server 1.66

Steps to Reproduce:

I'm trying to setup a VS Code Server behind a proxy which relies on NO_PROXY env var to bypass a proxy for some requests. But it does not seem to be respected. I think it should be handled [here](https://github.com/microsoft/vscode/blob/ee1655a82ebdfd38bf8792088a6602c69f7bbd94/src/vs/platform/request/node/proxy.ts#L11).
Repository: material-ui
Issue: [Slider] marks texts are out of bounds when labels are too long
Labels: bug 🐛,component: slider,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

If your marks text is too big then it's going to move out of it's parent's element bounds.
![image](https://user-images.githubusercontent.com/17240507/163721537-186c6f75-0ba8-4482-a6f7-387b85e831ac.png)


The same applies to tooltips
![image](https://user-images.githubusercontent.com/17240507/163721511-b3c4b93b-ce2f-4eb6-922f-485fac85aba8.png)


### Expected behavior 🤔

I'd suggest adding a new option to slider which would prevent overflow. Not sure if MUI is still using Popper.js, but they have this feature built-in https://popper.js.org/docs/v2/modifiers/prevent-overflow/

### Steps to reproduce 🕹

Just create any slider inside of Paper and add mark with long label in props.

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

**Browser is Chrome 100**

```
  System:
    OS: Linux 5.4 Ubuntu 20.04.4 LTS (Focal Fossa)
  Binaries:
    Node: 16.13.1 - ~/.asdf/installs/nodejs/16.13.1/bin/node
    Yarn: Not Found
    npm: 8.1.2 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: ^11.9.0 => 11.9.0 
    @emotion/styled: ^11.8.1 => 11.8.1 
    @mui/base:  5.0.0-alpha.76 
    @mui/icons-material: ^5.6.1 => 5.6.1 
    @mui/lab: ^5.0.0-alpha.77 => 5.0.0-alpha.77 
    @mui/material: ^5.6.1 => 5.6.1 
    @mui/private-theming:  5.6.1 
    @mui/styled-engine:  5.6.1 
    @mui/system:  5.6.1 
    @mui/types:  7.1.3 
    @mui/utils:  5.6.1 
    @mui/x-date-pickers: ^5.0.0-alpha.0 => 5.0.0-alpha.0 
    @types/react: ^17.0.44 => 17.0.44 
    react: ^17.0.2 => 17.0.2 
    react-dom: ^17.0.2 => 17.0.2 
    typescript: ^4.6.3 => 4.6.3
```
</details>
Repository: godot
Issue: Major performance drop when using "run on seperate thread" for 3D physics
Labels: bug,topic:physics,topic:3d,performance

### Godot version

4.0 Alpha 6

### System information

Windows 10 Nvidia GTX 1060 Intel i5 4690k

### Issue description

When using "run on seperate thread" for 3D physics in the settings menu, Godot performs far worse than when this option is off.

Here is a sample project.

There are a bunch of agents, and the most costly function is move_and_slide().

When threaded physics is off, this is the performance

https://user-images.githubusercontent.com/83078010/163723396-41b24c81-f266-4235-9d8a-d4edca99379a.mp4

When threaded physics is on, this is the performance.


https://user-images.githubusercontent.com/83078010/163723399-8df45369-dfc2-46a1-beda-ed33d080308a.mp4



There seems to be a significant performance decrease when using this option.

I have tested this in two projects, with the common variables being...
1. Using move and slide
2. Using the "run on seperate thread" for 3D physics

### Steps to reproduce

1. Create a scene with a bunch of agents wandering around the map (they must use move and slide, and collide with each other)
2. Make sure you have "run on seperate thread" for 3D physics enabled
3. Watch the FPS dip drastically low

### Minimal reproduction project

[PhysicsThreadBug.zip](https://github.com/godotengine/godot/files/8501998/PhysicsThreadBug.zip)