sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: yt-dlp
Issue: [Google Drive] get format/download source even the video still processing
Labels: site-enhancement

### Checklist

- [X] I'm reporting a site feature request
- [X] I've verified that I'm running yt-dlp version **2022.01.21**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've checked that all provided URLs are alive and playable in a browser
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)
- [ ] I've read about [sharing account credentials](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#are-you-willing-to-share-account-details-if-needed) and I'm willing to share it if required

### Region

_No response_

### Example URLs

https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view

### Description

hello, can you make get source format for download? even that video is still processing by google drive.

### Verbose log

```shell
C:\Users\Administrator>yt-dlp -Uv https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view
[debug] Command-line config: ['-Uv', 'https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, err utf-8, pref cp1252
[debug] yt-dlp version 2022.01.21 [f20d607] (win_exe)
[debug] Python version 3.8.10 (CPython 64bit) - Windows-10-10.0.19042-SP0
[debug] exe versions: ffmpeg 5.0-full_build-www.gyan.dev (setts), ffprobe 4.4.1-full_build-www.gyan.dev, phantomjs 2.1.1
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
Latest version: 2022.01.21, Current version: 2022.01.21
yt-dlp is up to date (2022.01.21)
[debug] [GoogleDrive] Extracting URL: https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view
[GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: Downloading webpage
ERROR: [GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: We're processing this video. Please check back later.
  File "yt_dlp\extractor\common.py", line 612, in extract
  File "yt_dlp\extractor\googledrive.py", line 176, in _real_extract

C:\Users\Administrator>yt-dlp -F https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view
[GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: Downloading webpage
ERROR: [GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: We're processing this video. Please check back later.

C:\Users\Administrator>yt-dlp -f source https://drive.google.com/file/d/1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk/view
[GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: Downloading webpage
ERROR: [GoogleDrive] 1Yu3I73IWqzEX4GzfxpLZ-AFhE6nQfVWk: We're processing this video. Please check back later.
```
Repository: godot
Issue: WindowDialog corner drag cursor incorrect on Linux with DMZ-White or DMZ-Black cursor sets
Labels: bug,platform:linuxbsd,topic:porting,needs testing

### Godot version

3.4.2 stable mono

### System information

Linux Mint, using DMZ-White cursor set

### Issue description

![image](https://user-images.githubusercontent.com/60734649/151950546-eb793b6f-f636-4075-abea-c37d3cd0d08a.png) are shown normally but ![image](https://user-images.githubusercontent.com/60734649/151950594-37d469d7-fbca-4d02-995a-6924900abe3c.png) fail to be shown. I got the normal cursor ![image](https://user-images.githubusercontent.com/60734649/151950696-418cad49-02c1-43e3-85b2-978aaa4821d3.png) when I am able to corner-resize the window dialog.

I can reproduce also with DMZ-Black, but it runs correctly with Adwaita (on my OS). Windows (default), Fedora (I don't know exactly the cursor set) is also correct.

### Steps to reproduce

Add a window dialog and drag it.

### Minimal reproduction project

_No response_
Repository: godot
Issue: [3.5beta1 server]ERROR: Script does not inherit a Node: res://
Labels: bug,platform:linuxbsd,needs testing,topic:dotnet,topic:export

### Godot version

v3.5.beta1.mono.official [b9b23d222]

### System information

Debian 11

### Issue description

I tried to use server and it give me an error:

```
Godot Engine v3.5.beta1.mono.official.b9b23d222 - https://godotengine.org
 
Mono: Log file is: '/home/vale/.local/share/godot/app_userdata/Authentication/mono/mono_logs/2022-02-01_13.58.03_1320802.log'
ERROR: Script does not inherit a Node: res://autoload/Signals.cs
   at: start (main/main.cpp:1904)
ERROR: Script does not inherit a Node: res://autoload/Setup.cs
   at: start (main/main.cpp:1904)
ERROR: Script does not inherit a Node: res://autoload/Authenticate.cs
   at: start (main/main.cpp:1904)
ERROR: Script does not inherit a Node: res://autoload/GameServers.cs
   at: start (main/main.cpp:1904)
ERROR: Script does not inherit a Node: res://autoload/DbHelper.cs
   at: start (main/main.cpp:1904)
```

where , for example, Signals have a Node like any of others:
```
using Godot;
using System;

namespace DesertEdge.Singleton
{
    public class Signals : Node
    {
        public override void _Ready()
        {
        }
    }
}
```

If I use headless server it work properly.
I followed the guide line posted here: https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_dedicated_servers.html
So I tried to use .pck file - as stated in docs -  but same error.
I tried: (godot-server.64 is the Godot server donloaded form website -mono version )
- ~/myproject/godot-server.64
- ~/myproject/godot-server.64 --main-pack myproject.pck
- ~/myproject/myproject.64  <-- renamed with same name as my myproject.pck

Still same errors..


### Steps to reproduce

see before

### Minimal reproduction project

NA
Repository: terminal
Issue: Cursor shape keep changing
Labels: Product-Conpty,Area-VT,Issue-Bug,Priority-2

### Windows Terminal version

1.11.3741.0

### Windows build number

10.0.19042.1466

### Other Software

tmux 3.0a (inside WSL)
NVIM v0.7.0-dev

### Steps to reproduce

1. Create `~/.tmux.conf`:
```
set-option -sg status-interval 1
set -g status-right "%I:%M%S%P"
```
2. Enter tmux by typing `tmux`
3. Enter nvim inside tmux by typing `nvim`
4. Enter insert mode by typing `i`

### Expected Behavior

**The cursor should not be changing. I've tested it on other terminals and it behaves correctly.** Here is the recording of the terminal output and I've tested this on other terminal and didn't experience any cursor issue with it. However, it causes cursor issue on Windows Terminal.
```sh
scriptreplay --timing=timing.log script.log
```
[script.log](https://github.com/microsoft/terminal/files/7978682/script.log)
[timing.log](https://github.com/microsoft/terminal/files/7978685/timing.log)


### Actual Behavior

The cursor will keep changing randomly when the status line redraws. This does not happen on every frame but about half of the time.

https://user-images.githubusercontent.com/28508329/151974459-7e0ba6ec-ee66-476b-9893-c77a6ee318f5.mp4


The following is what gets repeatedly emitted to the console after following https://github.com/microsoft/terminal/wiki/Enabling-the-debug-tap
```
[0]␣0:nvim*␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣01:1936pm␛[H␛[?25h␛[m␛[2␣q␛[?12l␛[6␣q␛[?25l␛[30m␛[42m␛[45;1H[0]␣0:nvim*␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣01:1937pm␛[H␛[?25h␛[m␛[2␣q␛[?12l␛[6␣q␛[?25l␛[30m␛[42m␛[45;1H[0]␣0:nvim*␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣01:1938pm␛[H␛[?25h␛[m␛[2␣q␛[?12l␛[6␣q␛[?25l␛[30m␛[42m␛[45;1H[0]␣0:nvim*␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣01:1939pm␛[H␛[?25h␛[m␛[2␣q␛[?12l␛[6␣q␛[?25l␛[30m␛[42m␛[45;1H
```
Repository: pytorch
Issue: Update MKL version used with MAGMA
Labels: module: ci,triaged,module: magma

### 🚀 The feature, motivation and pitch

PyTorch CI has recently upgraded the MKL version to the latest 2022.0. That version introduced a change that caused some of our tests to fail (see https://github.com/pytorch/pytorch/issues/71645, https://github.com/pytorch/pytorch/issues/67693).
The new MKL version has changed the behavior for SVD operation with inputs containing non-finite values.

MAGMA internally uses LAPACK for parts of the computation and it's linked statically to its own LAPACK, it doesn't share it with the rest of PyTorch. This situation leads to discrepancies in the behavior, for example the following code raises an error with MKL 2022.0 and cuSOLVER from CUDA Toolkit 11.5:
```py
import torch
device = 'cpu' # or 'cuda'
a = torch.randn(3, 33, 33, device=device)
a[1, 0, 0] = float('nan')
torch.linalg.svd(a) # errors here both on CPU and CUDA (cuSOLVER)
```
while with MAGMA there's no error:
```py
import torch
torch.backends.cuda.preferred_linalg_library("magma")
device = 'cuda'
a = torch.randn(3, 33, 33, device=device)
a[1, 0, 0] = float('nan')
torch.linalg.svd(a) # no error here
# prints to terminal
# Intel MKL ERROR: Parameter 4 was incorrect on entry to SLASCL.
# Intel MKL ERROR: Parameter 4 was incorrect on entry to SLASCL.
```

### Alternatives

Build dynamic MAGMA library (currently it is linked statically) https://github.com/pytorch/pytorch/issues/72106#issuecomment-1027124606.

### Additional context

Another issue that requires attention is due to the upgrade to MKL 2022.0: https://github.com/pytorch/pytorch/issues/71911.

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: vscode
Issue: Extra parameter for TextEditorEdit.insert to specify not moving a selection position that's at the insertion position
Labels: feature-request,editor-api

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

Lets say the editor has an empty selection at position (0, 5). If you insert some text at the same position:

``` typescript
let editBuilder: TextEditorEdit
...
editBuilder.insert(new Position(0, 5), "some text")
```

Then the selection moves with the inserted text, so that it's now positioned at the end of `some text`.

It would be nice if with `TextEditorEdit.insert`, you could specify not to move the active or anchor point of any selection *that's positioned exactly at the insertion point* (so it would instead stay at the beginning of "some text")

(Any selections *after* the insertion point are, and should be moved, that's fine)

I tried using `.replace` instead but that just changed the selection into a  non-empty selection with the same range as the inserted text.
Repository: PowerToys
Issue: FancyZones - Change an app to another zone without resizing
Labels: Idea-Enhancement,Product-FancyZones

### Description of the new feature / enhancement

Allow to set the top/left corner of an application on the top/left corner of a zone without resizing it. It could be a new "exception" list. In that list, there should be a way to set the size (width/height) of the application manually. The user could also resize the application itself to get these values updated automatically.

### Scenario when this would be used?

All the time. When an app in the list is moved, only the top/left position is changed, but not the size.

### Supporting information

_No response_
Repository: material-ui
Issue: Customize color shadow by property or variant
Labels: new feature

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

The same shadow size can not be customized by color.

This means that if I want a boxShadow of elevation 4, for example, in blue for a component and in red for another I have to override the boxShadow style at all, without using theme.shadows.

the only solution so far, right now, it is to override two different elevations using the same size but with different color:

```
// reference to @mui/material/styles/shadows.js
const shadows = [
    'none',
  createShadow(0, 2, 1, -1, 0, 1, 1, 0, 0, 1, 3, 0),
  createShadow(0, 3, 1, -2, 0, 2, 2, 0, 0, 1, 5, 0),
  createShadow(0, 3, 3, -2, 0, 3, 4, 0, 0, 1, 8, 0),
  createShadow(0, 2, 4, -1, 0, 4, 5, 0, 0, 1, 10, 0, "yellow"), 
  createShadow(0, 2, 4, -1, 0, 4, 5, 0, 0, 1, 10, 0, "red"), // same size of shadows[4], but with different color 
....
];
```

I do not think it should be the right way for doing that.

My suggestion is to export a color manipulator (similar to `alpha`) for using the same size but with different color:

```
<Stack boxShadow={(theme) => shadowColor(theme.shadows(4), "red")}>
```

I have read other (closed) issues related to this (like [this](https://github.com/mui-org/material-ui/issues/11386)) but I have not found an exhaustive answer 

### Examples 🌈

_No response_

### Motivation 🔦

_No response_
Repository: flutter
Issue: GridView inside ExpansionTile with PageStorageKey throws type cast error
Labels: c: crash,framework,f: scrolling,has reproducible steps,P2,found in release: 2.8,found in release: 2.10,team-framework,triaged-framework

## Description
I try to have an GridView inside an ExpansionTile wrapped in a Sliverlist. To persist the state of the ExpansionTile I added a PageStorageKey but by expanding the ExpanstionTile, after collapsing it, an error is thrown

## Steps to Reproduce

<!-- Please include full steps to reproduce so that we can reproduce the problem. -->

1. Execute `flutter run` on the code sample

**Expected results:**
No error.

**Actual results:**
The following error is thrown upon expanding the ExpansionTile:
```
The following _CastError was thrown building GridView(scrollDirection: vertical, primary: using primary controller, NeverScrollableScrollPhysics, shrinkWrap: shrink-wrapping, dependencies: [MediaQuery, PrimaryScrollController]):
type 'bool' is not a subtype of type 'double?' in type cast
```

<details>
<summary>Code sample</summary>

```dart
import 'package:flutter/material.dart';

void main() {
  runApp(const TestScreen());
}

class TestScreen extends StatelessWidget {
  const TestScreen({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Welcome to Flutter',
      home: Scaffold(
        body: CustomScrollView(
          physics: const BouncingScrollPhysics(),
          slivers: [
            // SliverAppBar comes here
            SliverList(
                delegate: SliverChildListDelegate([
              _expansionTile(),
            ]))
          ],
        ),
      ),
    );
  }

  Widget _expansionTile() {
    return ExpansionTile(
      initiallyExpanded: true,
      key: const PageStorageKey("some-key"), // <-- produces the error
      title: const Text("Expansoion Tile"),
      children: [_grid()],
    );
  }

  Widget _grid() {
    return GridView.count(
      shrinkWrap: true,
      crossAxisCount: 3,
      physics: const NeverScrollableScrollPhysics(),
      children: const [
        Text("1"),
        Text("2"),
        Text("3"),
        Text("4"),
        Text("5"),
      ],
    );
  }
}
```

</details>
Repository: pytorch
Issue: Unable to parse IR generated by Lazy Tensor Core with TorchScript Backend
Labels: oncall: jit,module: lazy

### 🐛 Describe the bug

When using the TorchScript backend with Lazy Tensor Core, the IR generated using `ltc._LAZYC._get_ltc_tensors_backend` cannot be parsed using `torch._C.parse_ir` if the input tensor is the output of an add operation.

The "hacky" solution was to replace `{1}` with `1` in the graph before parsing. Is there a way around this issue, or another way to parse the generated IR?

Note: @wconstab mentioned in https://github.com/pytorch/pytorch/issues/69033#issuecomment-1024514017 that "manually extracting the IR from lazy tracing and feeding it to a compiler isn't really the envisioned use case for LT", so that _might_ be why this doesn't work

To reproduce:
```python
import lazy_tensor_core as ltc
import torch

ltc._LAZYC._ltc_init_ts_backend()
device = torch.device('lazy')
dtype = torch.float32

x = torch.randn((4, 5), device=device, dtype=dtype)

# Capture lazy computation and convert to TorchScript IR
graph_str = ltc._LAZYC._get_ltc_tensors_backend([
    x + x
])

print(graph_str)
graph = torch._C.parse_ir(graph_str)
```

Output:
```
graph(%p0 : Tensor):
  %0 : Long(requires_grad=0, device=cpu) = prim::Constant[value={1}]()
  %2 : Scalar = aten::ScalarImplicit(%0)
  %3 : Tensor = aten::add(%p0, %p0, %2)
  return (%3)

Traceback (most recent call last):
  File "repro_ts_parsing_error.py", line 16, in <module>
    graph = torch._C.parse_ir(graph_str)
RuntimeError: 
Could not parse literal{:
graph(%p0 : Tensor):
  %0 : Long(requires_grad=0, device=cpu) = prim::Constant[value={1}]()
                                                                ~ <--- HERE
  %2 : Scalar = aten::ScalarImplicit(%0)
  %3 : Tensor = aten::add(%p0, %p0, %2)
```

### Versions

PyTorch version: 1.11.0a0+gitf10e970
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: CentOS Linux release 7.9.2009 (Core) (x86_64)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Clang version: 3.4.2 (tags/RELEASE_34/dot2-final)
CMake version: Could not collect
Libc version: glibc-2.2.5

Python version: 3.7.4 (default, Jan 28 2022, 18:52:51)  [GCC 8.3.0] (64-bit runtime)
Python platform: Linux-3.10.0-1160.49.1.el7.x86_64-x86_64-with-centos-7.9.2009-Core
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.18.2
[pip3] pytorch-lightning==1.5.9
[pip3] torch==1.11.0a0+gitf10e970
[pip3] torchmetrics==0.7.0
[pip3] torchvision==0.12.0a0+45c15f5
[conda] Could not collect
Repository: PowerToys
Issue: [FancyZones] Zone tabs
Labels: Idea-Enhancement,Product-FancyZones

### Description of the new feature / enhancement

Add a visual indication of the windows snapped to a zone. 

### Scenario when this would be used?

Windows snapped to the same zone hide each other. Using a tabs-like GUI we would be able to see which windows are snapped. The GUI could also support switching the current window by clicking the appropriate tab. 

### Supporting information

_No response_
Repository: go
Issue: runtime: debug output for fatal signal during signal handling.
Labels: NeedsDecision,compiler/runtime

#50936 is a crash due to SIGSEGV while in the SIGPROF signal handler. Since our signal handlers have all signals masked, the SIGSEGV is handled via the default termination action by the kernel, exit via signal 11. This results in no output to stderr at all to aid in debugging.

 I think we should try to get a bit more debug info out of such crashes.

One approach may be to unmask some signals during signal handling to detect nested signals. Something like:

```go
func sighandler(...) {
  if getg().m.insig {
    // Also print critical siginfo details: PC, addr
    throw("signal during signal handling")
  }
  
  getg().m.insig = true
  unblocksig(SIGSEGV, SIGBUS, SIGILL, SIGFPE, etc)
  ...

  // Reset insig, mask (does kernel do this?).
}
```

This approach keeps all signals masked in the sigaction, which limits the risk of infinite signal recursion. The downside being an extra syscall required in the signal handler.

(Edit: What we should do with C signal handlers is unclear. Do we unmask prior to calling a C signal handler? (I'd lean against this)).

cc @aclements @cherrymui @mknyszek
Repository: go
Issue: database/sql: if there is a panic during Stmt execution, we cannot release resources
Labels: NeedsFix

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.6 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
 * yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/devalio/.cache/go-build"
GOENV="/home/devalio/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/devalio/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/devalio/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go-1.17"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-1.17/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.6"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build4248269622=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
```go

	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Commit()

	stmt, err := tx.Prepare(...)
	if err != nil {
		return err
	}
	defer stmt.Close()

	_, err = stmt.ExecContext(ctx, ...)  // the error occurs if there is a panic in the process
	if err != nil {
		return err
	}
```
This is the kind of algorithm that leads to a complete hang-up:
 1. open the transaction
 2. Prepare statement
 3. Execute prepared statement
 4. If there is a panic inside the execution - resources will not be fully released and closing the statement or transaction will cause the goroutine to hang

### What did you expect to see?
I expect the pending functions to perform correctly and the goroutine to continue to panic
I do not expect the whole routine to hang up permanently


### What did you see instead?
resources will not be fully released and closing the statement or transaction will cause the goroutine to hang
Repository: go
Issue: x/tools/gopls: update editor instructions for go.work
Labels: Documentation,NeedsInvestigation,gopls,Tools

Some language-agnostic LSP clients need to be configured with root patterns (e.g. open the workspace to the folder containing `go.mod`).

We should update those to account for using `go.work` as the workspace root.

EDIT: the main things to look for are:
1. LSP clients should choose the workspace root correctly. Ideally, they should set the workspace root to the _first_ parent directory (or current directory) containing a `go.work` file (i.e. find nearest go.work file up the directory hierarchy). If no such directory exists, they should repeat with `go.mod`.  Unfortunately, not all LSP clients support this multi-phase search, so an alternate heuristic is to take the _farthest_ directory up the directory hierarchy that contains _either_ a `go.work` file or `go.mod` file.

```
/A/go.work <- acceptable workspace folder
/A/B/go.mod <- avoid
/A/B/C/go.work  <- ideal workspace folder 
/A/B/C/D/go.mod <- avoid
/A/B/C/D/E <- opened directory
```

2. If possible, LSP clients should activate gopls for `go.work` files and send the `"go.work"` [language identifier](https://microsoft.github.io/language-server-protocol/specification#textDocumentItem). This is much less critical than (1) -- clients could also do this for `go.mod` files and AFAIK none of them do, except VS Code.