sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: diagnostics: suggest .iter().collect() instead of .into() if possible
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
use std::ffi::OsStr;
use std::path::PathBuf;
fn main() {
    let x = vec![
        OsStr::new("home"),
        OsStr::new("matthias"),
        OsStr::new("rust"),
    ];
    let path: PathBuf = x.into();
}
```

The current output is:

```
error[E0277]: the trait bound `PathBuf: From<Vec<&OsStr>>` is not satisfied
 --> src/main.rs:9:27
  |
9 |     let path: PathBuf = x.into();
  |                           ^^^^ the trait `From<Vec<&OsStr>>` is not implemented for `PathBuf`
  |
  = help: the following implementations were found:
            <PathBuf as From<&T>>
            <PathBuf as From<Box<Path>>>
            <PathBuf as From<Cow<'a, Path>>>
            <PathBuf as From<OsString>>
            <PathBuf as From<String>>
  = note: required because of the requirements on the impl of `Into<PathBuf>` for `Vec<&OsStr>`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` due to previous error
```
It would be great if we could somehow suggest `.iter().collect()` here because this works:

````rust
use std::ffi::OsStr;
use std::path::PathBuf;
fn main() {
    let x = vec![
        OsStr::new("home"),
        OsStr::new("matthias"),
        OsStr::new("rust"),
    ];
    let path: PathBuf = x.iter().collect();
}

````


````
rustc 1.59.0-nightly (e95e084a1 2021-12-19)
binary: rustc
commit-hash: e95e084a14870a718c712936ab5a8f8cd0159485
commit-date: 2021-12-19
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0
````
Repository: go
Issue: proposal: cmd/go: allow "go install" a forked repository with cmd
Labels: Proposal

So if there is a CLI tool implemented in Go (e.g., `github.com/example/tool/cmd/tool`) which I fork into my namespace and slightly fix (e.g., `github.com/mitar/tool/cmd/tool`), there seems to be no way to currently do `go install github.com/mitar/tool/cmd/tool@latest` to get my fork installed locally without doing find/replace over all files to change original package name to my fork's.

I would propose that there is such a way, maybe by providing a `replace` directive using CLI argument while installing, e.g.:

```
go install -replace gogithub.com/example/tool=github.com/mitar/tool@main github.com/example/tool/cmd/tool@latest
```

This is to support a common use case of collaboration in open source projects:
* I fork the project.
* I make a fix.
* I make a PR to the main project.
* While the main project is reviewing my PR I want to use the fixed CLI tool, e.g., in the Dockerfile which originally had `go install` with the original project.
* After PR is merged, I start using `go install` from original location again.

Currently I have to do the PR and then in another branch make one more commit on top of the PR, doing find/replace to replace module paths in all the codebase. This is tedious and error prone if during the review of PR I am asked to do modifications. Then I have to do the fix and then re-do the module paths replacements in a new commit.
Repository: rust
Issue: When trying to use cross language LTO on windows for the MSVC target, proc macros give a linker error without an explicit target
Labels: O-windows,A-diagnostics,T-compiler,C-bug,A-proc-macros,A-LTO

I'm building a hello world generated by cargo, using this .cargo/config:

```toml
[target.x86_64-pc-windows-msvc]
linker = "lld-link.exe"
rustflags = ["-Clinker=lld-link", "-Clinker-plugin-lto"]
```

I have LLVM/bin (From LLVM13 to match my current rust LLVM version) in my path. `cargo build` runs fine. But as soon as I add a dependency with a proc macro, it results in a linking error. For example:

```toml
[dependencies]
thiserror="1.0.30"
```

Results in:

```
    Updating crates.io index
   Compiling proc-macro2 v1.0.34
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.82
   Compiling quote v1.0.10
   Compiling thiserror-impl v1.0.30
error: Linker plugin based LTO is not supported together with `-C prefer-dynamic` when targeting Windows-like targets

error: could not compile `thiserror-impl` due to previous error
```

This goes away if an explicit target is used: `cargo build --target x86_64-pc-windows-msvc`

After reading the cargo docs [here](https://doc.rust-lang.org/cargo/reference/config.html) 

```
If the --target flag (or build.target) is used, then the flags will only be passed to the compiler for the target.
Things being built for the host, such as build scripts or proc macros, will not receive the args.
Without --target, the flags will be passed to all compiler invocations (including build scripts and proc macros) because dependencies are shared.
If you have args that you do not want to pass to build scripts or proc macros and are building for the host, pass --target with the host triple.
```

It makes sense but this is still super confusing, and the only reason I got it to work is someone suggested it to me. Could this restriction on prefer-dynamic + linker-plugin-lto be softened on proc-macros, or maybe the error message improved to suggest using an explicit target?
Repository: pytorch
Issue: Missing Docker image for 1.10.1
Labels: module: binaries,triaged,module: docker,Stale

### 🐛 Describe the bug

The Docker image for the latest release (v1.10.1) is missing from Docker Hub: https://hub.docker.com/r/pytorch/pytorch/tags.

### Versions

N/A

cc @ezyang @seemethere @malfet
Repository: deno
Issue: Can't debug multiple test files in VS Code using `deno test`
Labels: bug,debugger

On 1.17, when I debug `deno test --inspect-brk` in VS Code, I'm only able to hit breakpoints in the first test file it runs. E.g. if I have two test files and set breakpoints in both, I only hit breakpoints in the first file.

If I always explicitly specify the test file as an argument, then I'm able to debug my test successfully.

Here's a repository with a minimal setup to reproduce (including `launch.json` file):
https://github.com/jaredkrinke/repro-deno-debug-two-files

Deno version:
> deno 1.17.0 (release, x86_64-pc-windows-msvc)
> v8 9.7.106.15
> typescript 4.5.2

# Steps to reproduce
1. Open in VS Code
1. Put breakpoints on the `console.log` lines in *both* `one.test.ts` and `two.test.ts`
1. Fit F5 to start debugging with the provided `launch.json`
1. Hit the first breakpoint
1. Hit F5 to continue to the next breakpoint

# Expected
The next breakpoint should be hit.

# Actual
Debug session ends.

Note: I always hit the same breakpoint, and it's in the file that comes first alphabetically, so I suspect Deno is enumerating the files and running them sequentially in separate contexts, but for whatever reason, I can only debug the first context.

# Workaround
To debug a particular test, just add that test's file name to the arguments in `launch.json`.
Repository: godot
Issue: Godot Mono (C#) SQL Server connection problem
Labels: bug,platform:windows,topic:dotnet

### Godot version

3.4.stable

### System information

Windows 10

### Issue description

I'm using godot C# stable v3.4 and using visual studio code as an external editor with C# code and trying to make a connection between my project using C# and SQL Server using SQL server management studio 2019 and here is my initial code

```csharp
using Godot;
using System;
using System.Data.SqlClient;
using System.Net.Security;

public class Control : Godot.Control
{
    public override void _Ready()
    {
        SqlConnection conn = new SqlConnection("Server=DESKTOP-CQUGBAI;Database=SMS;Trusted_Connection=True;");
        try
        {
            conn.Open();
            OS.Alert("Open", "Message Box");
        }
        catch(Exception ex)
        {
            OS.Alert(ex.Message, "Message Box");
        } 
    }
}
```

the problem is the debug stoped at the SqlConnection object and give me this message
![unnamed](https://user-images.githubusercontent.com/96445279/146827417-8f44822a-9699-4a4d-8028-46a04ec4c3ef.jpg)

[for good quality](https://ibb.co/vz69dD6)


### Steps to reproduce

download VScode and godot mono
open my uploaded project
run the project

### Minimal reproduction project

[Issue.zip…]()
Repository: youtube-dl
Issue: Subtitles of the site ADN without encryption key
Labels: request

## Checklist
- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description
I found a method to no longer have the problem of the ADN subtitle encryption key. If you are interested I will tell you more in this discussion, but ping me. I think its will help a lot of people.
Repository: electron
Issue: [Feature Request]: Support persistent notifications
Labels: enhancement :sparkles:,component/notifications

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Currently Electron has odd behavior with notifications.

* The "close" event is fired automatically when the popup has closed. It is impossible to know if the user explicitly dismissed the notification, so it's impossible to sync that state to other clients.
* The notification sticks around in the Windows notification center, and [calling `.close()` on it has no effect](https://github.com/electron/electron/issues/32260), so dead notifications stack up indefinitely.
* There seems to be no way to track a fired notification when the app has been closed and re-opened. The system might still be showing one of your old notifications but there is no way to recall it or update it.

### Proposed Solution

Implement persistent notification support:

* Only fire the "close" event when the user explicitly dismisses the notification. That way it can be used as a reliable signal to recall the notification on other synced devices.
* When showing a notification, give back an identifier that can be saved and used later to recall (close) a notification, even if the app has restarted.
* Continue showing them in the Windows notification center and allow the app to close them at any point.

Some thought may need to go into how to listen for dismissed notifications when the app is not running. Though for starters it could just be that the app needs to be running in some capacity to pick up that event.

### Alternatives Considered

I think the only alternative to solve this issue would be to bypass the Electron notification system and implement a custom one, like what Slack appears to do.

### Additional Information

_No response_
Repository: bitcoin
Issue: [RFC] Stop automatically creating legacy and p2sh-segwit descriptors
Labels: Feature,Brainstorming,Wallet

As we see segwit and taproot usage grow, it seems reasonable to stop making wallets that are able to generate legacy and p2sh-segwit addresses. We have already made it difficult to make legacy addresses through the GUI (starting with `-addresstype=legacy` is the only way). The default address type is bech32. So it seems that we should consider stop automatically generating legacy, and probably p2sh-segwit, descriptors.

This would simply be removing the automatic creation of descriptors for the `LEGACY` and `P2SH_SEGWIT` output types for new wallets. We would still retain the ability to spend those outputs, parse those descriptors, and make those types of addresses if the user's wallet has descriptors for these output types. Additionally, if a user wanted to add such a descriptor to their wallet, they could via `importdescriptors`. There can also be some RPC which can add an automatically generated single key descriptor of whatever type that could legacy and p2sh-segwit descriptors to the wallet. Such an RPC would be the generic version of the one that will add `tr` descriptors (or perhaps the same RPC).
Repository: godot
Issue: Syntax highlighting color editor setting deleted itself when reset
Labels: bug,topic:editor,needs testing

### Godot version

3.4.1 Stable

### System information

macOS 12.0.1, Mid 2015 MacBook Pro (Intel, AMD Radeon R9 M370X)

### Issue description

While editing an editor setting, resetting it deleted the setting altogether – and set to a wrong default. Restarted Godot mostly fixed the issue.

### Steps to reproduce

I decided to play around with text editor highlighting. I set (and reset back with the arrow icon) a few settings.

When i reset function_color, instead of becoming its default, it turned black – and then disappeared from the list entirely. Here's the output from that session:

![image](https://user-images.githubusercontent.com/11724303/146845843-66b1ec1a-7058-48b2-bef9-4a9f28459e33.png)

The highlight itself became black: 
![image](https://user-images.githubusercontent.com/11724303/146845860-73f5ab31-30b6-4c2e-92f9-21b591700fca.png)

Restarting Godot added the setting back and set the color to default. However, now most collors appear edited (resettable) despite being default:
![image](https://user-images.githubusercontent.com/11724303/146846213-c0e800c1-f740-4e36-a97f-91c9feef7e2e.png)

### Minimal reproduction project

_No response_
Repository: neovim
Issue: Treesitter: More control over injected languages
Labels: enhancement,treesitter

### Feature already in Vim?

N/A

### Feature description

Right now, the only option for injections is the ability to override the "injections" queries for each language

https://github.com/neovim/neovim/blob/1062ea2cc532b32862346a1972073f1a8dd6d19d/runtime/lua/vim/treesitter/languagetree.lua#L15

I think it would be useful to pass a list of allowed injected languages. For example, on a markdown file, only a subset of languages would be allowed, or even don't allow any language to be injected. Right now, users are just uninstalling parsers of languages they don't want to have injected, but that removes the ability to parse that language.

I'm opening this issue to come with suggestions on how this setting will work.

Maybe a table of languages to a table of options?

```lua
  local opts.injections = {
    lua = {
      -- Injection query to override the global one.
      query = "...",
      -- Injections aren't allowed.
      -- This option can be a boolean to enable or disable
      -- injections of all languages, or a list.
      -- If "enable" and "disable" are empty lists it means
      -- enable = true.
      enable = false,
    },
    markdown = {
      query = "...",
      -- Only a subset of languages are allowed.
      enable = {"javascript", "lua"},
      -- If both "enable" and "disable" are given,
      -- the former takes precedence, and disable is ignored.
      disable = {}
    },
    rst = {
      -- All languages except for these are allowed.
      disable = {"javascript", "lua"},
    }
  }
```

To keep backwards compatibility (but not really sure if people are using this option, or at least in plugins form nvim-treesitter we aren't  AFIK), if the value of the option is a string it will be transformed to a table.
Repository: pytorch
Issue: Grad strides do not match bucket view strides
Labels: triaged,module: ddp

> Grad strides do not match bucket view strides. This may indicate grad was not created according to the gradient layout contract, or that the param's strides changed since DDP was constructed.  This is not an error, but may impair performance.
grad.sizes() = [1024, 256, 1, 1], strides() = [256, 1, 256, 256]

I meet a question, and I don't know what it represents and why it arises?
Repository: vscode
Issue: Emmet JSX Intellisense doesn't appear when directly next to a closing parentheses
Labels: bug,emmet,emmet-parse

<!-- ⚠️⚠️ 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
`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.63.2
- OS Version: Ubuntu 20.04 (Linux x64 5.11.0-43-generic snap)

#### Steps to Reproduce:

1. Ensure that the file extension is tsx (or the language is set to typescriptreact)
2. To check that Intellisense is working, type `img` and Intellisense should display an Emmet Abbreviation of `<img src="" alt="" />`
3. On new line, type `console.log(` (note that vscode automatically adds the closing parentheses)
4. Try to type a new `img` element inside the console log.
5. Note how Intellisense does not show the `img` Emmet Abbreviation 


#### Expected results:
The Emmet Abbreviation should appear even though you are next to a closing parentheses.
Repository: next.js
Issue: next/image objectFit="cover" causes images not to render on macOs and iOS
Labels: bug,Image (next/image)

### What version of Next.js are you using?

12.0.7

### What version of Node.js are you using?

16.13.1

### What browser are you using?

Safari for iOS, Firefox for Mac

### What operating system are you using?

macOS, iOS

### How are you deploying your application?

Vercel

### Describe the Bug

When using the Image component from ``next/image`` images don't render on certain Apple devices. I've had people test on Firefox for MacOS and Safari on iOS on an iPad. This seems to work on my iPhone though. This happens when using ``objectFit="cover"``. All devices are updated to versions of their operating systems that ship Safari that supports the ``object-fit: cover;`` css property, or use an up-to-date Firefox for macOS that also supports the property.

### Expected Behavior

I would expect the Image component to render images the same on all browsers

### To Reproduce

To reproduce, simply copy the provided component and add it to your page with an image. On MacOS or iOS (sometimes, depending on the device, my iPhone works fine, but my tester's iPad does not) the image will not show up.

This is the component used that has the problem (using tailwindcss)

```ts
const BackgroundImage = ({ src, alt }: { src: string, alt: string }) => {
    return (
        <div className="relative w-full h-full">
            <Image alt={ alt } src={src} layout="fill" objectFit="cover" objectPosition="center" />
        </div>
    );
}
```

On most browsers here is an image of the website with images, this one taken on Windows with Firefox:
![working](https://user-images.githubusercontent.com/14950489/146867550-214c9b37-53ce-410c-bdba-2e0246c986b3.png)

And here is an image from one of my testers on their iPad, but firefox on macOS looks the same, I just don't have an image from that tester:
![broken](https://user-images.githubusercontent.com/14950489/146867580-e6a49eec-01f6-45a5-b318-c836ff7d945f.jpg)

Also as a note replacing the component with the following does not have the same issue, but I would like the image compression features that Next.js provides with the Image component:
```ts
const BackgroundImage = ({ src, alt }: { src: string, alt: string }) => {
    return (
        <div className="relative w-full h-full overflow-hidden">
            <img alt={ alt } src={src} className="object-cover min-h-full" />
        </div>
    );
}
```
Repository: TypeScript
Issue: Incorrect `Type 'false' is not assignable to type 'true'.`
Labels: Suggestion,Experience Enhancement

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

"is not assignable to"

### 🕗 Version & Regression Information

- This changed between versions 3.9.7 and 4.0.5

### ⏯ Playground Link


[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.0.5#code/PTAEEkDtQFwCwJYGdQENKoDYHsDmBPAGlABFtsAnUAeUgFM1IATU8qgFQHdsAoEUOKgBuDeAki4UAIzqJmsOHQC2C1DFABjdKBmgkdOtE6Lo2AA6GAdHzBlKobPVBLU+AcIZTs8NKFzY1RhZUTVQqGTkWBBhCGwcqemjFCktWexhuZ1d3ET1FOjMdWXEomGsQOIBBDRgAVyxMIlAmNlhMpjoAM3Foukb3FCR8woiS0GjY-nQolEhvUDoRKg0cfSZUgGVsZtaM7eQ0TE5XFHNDOOnD4-wUQUHh6x46AA8zSnUYfAsISE7tgF5QAAKHigUAAH2BAG9QWC4S1KLQ6NQLJAAFywCi1OiwsEAX1AADI0hQkQBZBDPcQASlhkJhcPhbCRKMMGM6WH0uNAeJ41KJoAZO0oXGwrPRmOxsIRFFF4CQG2GGJgWJxvJ4n2+dlJ9ApVOg-zpgu5YJlSIAEqgkABxAIwdmcnGM03M+iWpAAYTCDswXMZvLB9JNwp1dHdtrUytVwbNbqtXooUal-p4PA0jiQ6j+2AxUD+oEBQtjyNRSbosRdIu44rLFdA-HYXzoGw0FAQZg+fV9oFqKHggS8PmwnQUdH0zl76l0KuxqQAQrUPoo3GEGA1sJw6CwYNtdBzfXRrJXQ+G7T79HXi+6E+fy7DgAAqBQHTgITCYUDdZ6jhYUCiUYhFkMBRsFqXA4HGTt3xQXtQDmMQJDQLxFxDBwnAfYB7zAGU5QVJVJTVHggA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
// In this analogy, Door One and Door Two
// have things behind them that can be seen when open.
// Door one may have both a goat and a car behind it,
// or neither. Door two may have sheep behind it.
//
// Actually, door two definitely has sheep behind it,
// and is not ever closed. So door two is always open
// and always has sheep.

export type Info = (
  | ({
      doorOneOpen: true
    } & DoorOneMixin)
  | {
      doorOneOpen: false
    }
) & {
  doorTwoOpen: true
  doorTwoIsSheep: true
}

type DoorOneMixin =
  | {
      doorOneHasGoat: false
      doorOneHasCar: false
    }
  | {
      doorOneHasGoat: true
      doorOneHasCar: true
    }

const foo: Info = {
  doorOneOpen: true,
  doorTwoOpen: true,
  // TypeScript tells us that both of these must be true. But they are allowed to be false.
  doorOneHasGoat: false,
  doorOneHasCar: false,
  /* this will fix the error, even though it tells us nothing about door one */
  // doorTwoIsSheep: true
}
```

### 🙁 Actual behavior

TypeScript tells us that our code cannot compile because `doorOneHasGoat` and `doorOneHasCar` are expected to be `true`. 

> Type 'false' is not assignable to type 'true'.
> Type 'false' is not assignable to type 'true'.

However, they are allowed to be what they are (`false`). The problem is actually that `doorTwoIsSheep` is not specified when it must be.

### 🙂 Expected behavior

TypeScript could say `doorTwoIsSheep is required`. For extra helpfulness it could say that it must be true (since this is known) but I don't care about that as much.

I understand this "hint" feature is considered a heuristic but maybe this can be one use case for improving the heuristic in a certain way.
Repository: go
Issue: proposal: generic should infer type from variable definition
Labels: Proposal,Proposal-Hold,generics,TypeInference

hope go could support infer generic type from variable type

```
func main() {
	var x Person = get() // to replace var x = get[Person]()
	fmt.Println(x)
}

func get[T any]() T {
	var x T
	return x
}
```