sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: [PWA] Register vscode.dev as file handler for well-supported file types
Labels: feature-request,web,vscode.dev

Using the _File Handling API_, the vscode.dev PWA could register as handler for files (mime types and extensions); makin it easier to open, view, and edit files .

[File Handling](https://docs.google.com/document/d/1SpLwK0sQ3CUuuG-T9pFBqlm1Ae-OGwi4MsP5X2bCBow/edit#heading=h.xzptrog8pyxf) is currently in [origin trials](https://developer.chrome.com/origintrials/#/view_trial/-6682215947110973439) and slotted to ship in stable soon.

VS Code already has a list of file extensions for both Windows and macOS and could generate a file handler list from those entries.

cc @joaomoreno @bamurtaugh @thejohnjansen @captainbrosset
Repository: godot
Issue: Editor changes not synced to remote scene, despite automatic port reassignment.
Labels: bug,topic:editor,needs testing

### Godot version

v3.4 RC1 (Mono build)

### System information

Windows 10

### Issue description

In any situation that would trigger https://github.com/godotengine/godot/issues/41650, changes to a scene made in the editor are still not synced to the running scene, even after https://github.com/godotengine/godot/pull/37067.

https://user-images.githubusercontent.com/56076033/138736428-72ceac88-af67-4956-bb8b-1d6112b3013d.mp4

https://user-images.githubusercontent.com/56076033/138736450-79c9ebdb-5530-4603-b8d6-9a91f80921c5.mp4





### Steps to reproduce

In any project, attempt to edit a scene in the editor while the project is running when debugging ports have had to be reassigned (having OmniSharp enabled in Visual Studio Code, in my case).

### Minimal reproduction project

Reproduction requires an external debugger, which cannot be bundled into a project.
Repository: rust
Issue: Tracking Issue for `-Z no-unique-section-names`
Labels: T-compiler,C-tracking-issue,A-CLI

This is a tracking issue for the `-Z no-unique-section-names` debugging option which can reduce the size of object files for ELF targets when using the LLVM codegen backend.

- Docs: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/no-unique-section-names.html
- Implementation: https://github.com/rust-lang/rust/pull/89581

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Implementation history

- https://github.com/rust-lang/rust/pull/89581
Repository: go
Issue: cmd/compile, runtime: initialization order within a file appears to have changed
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
go version go1.17.2 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes, with 1.17.1 and .2. It has not been a problem prior to 1.17.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/cnicolaou/Library/Caches/go-build"
GOENV="/Users/cnicolaou/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/cnicolaou/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cnicolaou/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.7"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/cnicolaou/go-bug-report/bug/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/1h/54rm9zd51ddcs0pt8j_l7d2m0000gn/T/go-build3841401253=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

### What did you do?

Nothing new! The code that encountered the problem has been in use since 2014/15.

It is my understanding that for the code snippet below, the initializeMe function will always
be called first and before any other initialization. This has been been the case prior to
go 1.17

```go
package foo
// no other code here.
var _ = initializeMe()
// other code here, which really should not matter
```

However, with go 1.17, this behavior appears to have changed, and ```initializeMe``` is no longer
called before other initialization and in my case is not called before initialization that depends
on it. I understand that there is no dependency analysis going on but there shouldn't need
since by my reading of the spec initializeMe should always be called first. I have attached
code snippets to repro the problem.

The code that seems to defeat the expected initialization involves an additional variable initialization
via an other package.

```
var breaksIfThisExists = struct {
        vals    []int
} {
        []int{indirect.GetVal(d)},
}
```

where ```indirect.GetVal(d)``` calls a method on ```d``` whose implementation accesses a variable that
is initialized by ```initializeMe```.

### What did you expect to see?

no panic.

### What did you see instead?
a panic

[bug.tar.gz](https://github.com/golang/go/files/7412516/bug.tar.gz)
Repository: material-ui
Issue: Add @mui/lab/locale
Labels: package: lab

When using localization, the theme can be extended with 

```jsx
import { createTheme, responsiveFontSizes } from '@mui/material/styles';
import { frFR } from '@mui/material/locale';
import merge from 'deepmerge';

// localized theme
const theme = merge(responsiveFontSizes(createTheme(themePreset), frFR);
```
However, components inside `@mui/lab` aren't localized.

- [X] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Summary 💡

<!-- Describe how it should work. -->

## Examples 🌈

With `@mui/lab/locale`, extending the theme would decouple de app's responsibility to localize these components.

```jsx
import { createTheme, responsiveFontSizes } from '@mui/material/styles';
import { frFR } from '@mui/material/locale';
import { frFR as frFR_lab } from '@mui/lab/locale';  // suggested
import merge from 'deepmerge';

// fully localized theme
const theme = merge.all([ responsiveFontSizes(createTheme(themePreset), frFR, frFR_lab ]);
```

## Motivation 🔦

Components like `TimePicker` aren't localized. Once they are, and they are moved to `@mui/material`, then their localizations will move with them. User code should not maintain these localization strings.
Repository: vscode
Issue: Deleted files from explorer should match styling from deletions on disk
Labels: polish,scm

Deleting a file through the explorer shows the "Deleted" text in the tab when clicking on it through scm:

<img width="535" alt="CleanShot 2021-10-25 at 11 37 01@2x" src="https://user-images.githubusercontent.com/35271042/138751182-71fefa4e-ab96-465f-b9a9-eecc3c4539da.png">

We recently updated this styling when deleting files from on disk via https://github.com/microsoft/vscode/issues/130526:

<img width="474" alt="CleanShot 2021-10-25 at 11 37 54@2x" src="https://user-images.githubusercontent.com/35271042/138751331-9bc18bcf-2ae6-4fa9-8042-6bed7291b2e7.png">

We should align the scm view so that these two are the same and use our new treatment
Repository: create-react-app
Issue: Issues with Jest
Labels: needs triage

We have an old version of an application done with create-react-app. This is using `react-scripts 1.1.5`.

I am trying to use Jest with react-testing-library.

When running the specs, I have the following issue:

```
  ● Test suite failed to run

    /home/mgarcia/projects/v3bitex-implementation/node_modules/apex-web/lib/redux/middlewares/authMiddleware.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){import _regeneratorRuntime from 'babel-runtime/regenerator';
                                                                                             ^^^^^^
    
    SyntaxError: Cannot use import statement outside a module
```

Fine. It seems to be complaining about ES6 being used in a node module. So I run the script with the following:

`npm run test --  --transformIgnorePatterns "node_modules/apex-web"`

This seems to work, until I run into:

```
  ● Test suite failed to run

    /home/mgarcia/projects/v3bitex-implementation/node_modules/@testing-library/dom/node_modules/pretty-format/build/plugins/DOMElement.js: Unexpected token, expected ( (25:10)
        23 |   try {
        24 |     return typeof val.hasAttribute === 'function' && val.hasAttribute('is');
      > 25 |   } catch {
           |           ^
        26 |     return false;
        27 |   }
```

So it seems I have to exclude another library.

Am I missing something here? Should I manually list every single library that has this issue? Is there a version of react-scripts that automatically handles this without any issues?

I have tried to upgrade to v2, but everything broke miserably.
Repository: node
Issue: Dynamic import in loader hooks crashes node
Labels: esm,loaders

### Version

16.12.0

### Platform

Microsoft Windows NT 10.0.19041.0 x64

### Subsystem

esm

### What steps will reproduce the bug?

I am currently doing some experiments with loader hooks (see also www.npmjs.com/package/create-esm-loader and https://www.npmjs.com/package/node-esm-loader) and noticed something that was working in 16.11, but not anymore in 16.12.0 (which coincides with the changes in the loader api).

The setup is the following:
```js
// # loader.js
const promise = import('./dep.js');

export async function resolve(specifier, ctx, defaultResolve) {
  await promise;
  return defaultResolve(specifier, ctx, defaultResolve);
}

// # dep.js
import './nested.js';

// # nested.js
console.log('Nested dep');
```

If you try to run a file using `node --experimental-loader="./loader.js" file.js`, it will crash the Node process with an exit code 13 on 16.12, whereas it runs fine on 16.11.

### How often does it reproduce? Is there a required condition?

The bug can only be reproduced if you import a nested dependency `nested.js`.

### What is the expected behavior?

The Node process should not crash, as it did in 16.11.

### What do you see instead?

Node crashes.

### Additional information

The problem is likely related to the fact the the nested dependency is loaded asynchronously and that the `resolve()` hook is interfering with loading it. Indeed, if you do
```js
import './dep.js';
const promise = import('./dep.js');

export async function resolve(specifier, ctx, defaultResolve) {
  await promise;
  return defaultResolve(specifier, ctx, defaultResolve);
}
```
the Node process does not crash because it finished loading the nested dependency before trying to use the loader hooks.
Repository: go
Issue: runtime: bad crash output for synchronous signal in the VDSO
Labels: NeedsFix,compiler/runtime

If a synchronous signal causes a crash in the VDSO, the output looks something like:

```
runtime: unexpected return pc for runtime.sigpanic called from 0x7ffd19ea9a4a
stack: frame={sp:0x7ffd19e600f8, fp:0x7ffd19e60148} stack=[0xc00004e000,0xc00004e800)

fatal error: unknown caller pc

runtime stack:
runtime.throw({0x4a1a18, 0x5197e0})
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:965 +0x71
runtime.gentraceback(0x1000100000006, 0xc00004e800, 0x7ffd19e60160, 0x7ffd19ea9a4a, 0x0, 0x0, 0x7fffffff, 0x7ffd19e60170, 0x45ca0a, 0x0)
        /usr/local/google/home/mpratt/src/go/src/runtime/traceback.go:240 +0x1a36
runtime.addOneOpenDeferFrame.func1()
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:585 +0x6b
runtime.systemstack()
        /usr/local/google/home/mpratt/src/go/src/runtime/asm_amd64.s:344 +0x49

goroutine 6 [running]:
runtime: unexpected return pc for runtime.systemstack_switch called from 0x0
stack: frame={sp:0x7ffd19e5fff0, fp:0x7ffd19e5fff8} stack=[0xc00004e000,0xc00004e800)

runtime.systemstack_switch()
        /usr/local/google/home/mpratt/src/go/src/runtime/asm_amd64.s:311 fp=0x7ffd19e5fff8 sp=0x7ffd19e5fff0 pc=0x458780
created by main.main
        /usr/local/google/home/mpratt/Downloads/hello.go:12 +0x76

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc000010250)
        /usr/local/google/home/mpratt/src/go/src/runtime/sema.go:56 +0x25
sync.(*WaitGroup).Wait(0x0)
        /usr/local/google/home/mpratt/src/go/src/sync/waitgroup.go:136 +0x52
main.main()
        /usr/local/google/home/mpratt/Downloads/hello.go:16 +0x85
```

I manually triggered this crash by changing the runtime to pass a bad `struct timespec *` to `clock_gettime` in the VDSO.

Rather than the normal unexpected signal panic one would expect, `gentraceback` fails and throws. Luckily `0x7ffd19ea9a4a` is the PC of the faulting instruction, which would help in an investigation, though it is not obvious from this output that that is the correct PC.

Synchronous signals panic by pushing `sigpanic0` onto the stack and `sigreturn`ing to it. My quick investigation shows that gentraceback is computing the incorrect frame pointer, but I don't yet see why. I thought perhaps making `preparePanic` push `vdsoSP` instead of the actual SP might fix it, but it made no difference.

In practice, a synchronous signal in the VDSO would probably only occur due to a bug in the Go runtime, so this isn't high priority.

cc @cherrymui
Repository: rust
Issue: Add obligation cause code for function call trait bounds
Labels: C-enhancement,A-diagnostics,A-trait-system,T-compiler

Recommended by: https://github.com/rust-lang/rust/pull/90181#discussion_r735152142

There is already an obligation cause code for when the requirement can be traced back to a single parameter, but there is no appropriate cause code for the cases where it cannot.
Repository: rust
Issue: Tests do not capture stdout of foreign threads
Labels: A-libtest,C-discussion,A-thread,T-testing-devex

<!--
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 a test writes to stdout on a thread created outside of Rust (e.g. directly via `pthread_create` on Linux or `CreateThread` on Windows), then that output will not be captured but will go straight to stdout when run with `cargo test`. This is problematic for tests that need to run code on threads created by non-Rust components.

Repro:

```rust
#![cfg(test)]

#[test]
fn foo() {
    unsafe {
        let mut n = std::mem::zeroed();
        assert_eq!(
            0,
            libc::pthread_create(&mut n, std::ptr::null(), print_thread, std::ptr::null_mut())
        );
        assert_eq!(0, libc::pthread_join(n, std::ptr::null_mut()));
    }
}

extern "C" fn print_thread(_: *mut std::ffi::c_void) -> *mut std::ffi::c_void {
    println!("should be captured");
    std::ptr::null_mut()
}
```

Expected (output is captured):

```
    Finished test [unoptimized + debuginfo] target(s) in 0.11s
     Running unittests (target/debug/deps/repro-4d64f2a51a952b52)

running 1 test
test foo ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

Actual (output is not captured):

```
    Finished test [unoptimized + debuginfo] target(s) in 0.11s
     Running unittests (target/debug/deps/repro-4d64f2a51a952b52)

running 1 test
should be captured
test foo ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

### 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.56.0 (09c42c458 2021-10-18)
binary: rustc
commit-hash: 09c42c45858d5f3aedfa670698275303a3d19afa
commit-date: 2021-10-18
host: x86_64-unknown-linux-musl
release: 1.56.0
LLVM version: 13.0.0
```
Repository: flutter
Issue: Use `-flto=thin`
Labels: team,engine,P2,team-engine,triaged-engine

See http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html

This should speed up our build times, but potentially impacts benchmarks.
Repository: terminal
Issue: Ssh MouseEvent doesn't work with touch input
Labels: Help Wanted,Area-Input,Issue-Bug,Area-TerminalControl,Product-Terminal,Priority-2

### Windows Terminal version (or Windows build number)

1.10.2714.0

### Other Software

found it out by using HTOP on a debian linux server connected via SSH

### Steps to reproduce

1. Ssh into a linux machine via the `ssh [IP]` command.
2. Open HTOP by typing `sudo htop`
3. Click with your mouse on a row, it becomes selected. Now touch on another row. Nothing happens.

### Expected Behavior

Touch inputs are passed to SSH.

### Actual Behavior

Touch doesn't work.
Repository: godot
Issue: Enumerated properties exported via _get_property_list() only appear as integers in the keyframe inspector.
Labels: bug,topic:editor,topic:animation

### Godot version

3.2.3 stable

### System information

Ubuntu 20.10

### Issue description

I can make an exported enum property appear in the node inspector as expected, and animate it, but the keyframe inspector only displays an integer value.

![image](https://user-images.githubusercontent.com/20008200/138786667-eb876931-4f88-423c-b398-d80e043f905e.png)


### Steps to reproduce

1. Create a tool script.
2. Create a property, `foo`.
3. Add the `_get_property_list() `method to the script.
4. Export `foo` within the method, giving it the type `TYPE_INT`, and the hint `PROPERTY_HINT_ENUM`.
5. Assign enum values in the properties `hint_string` value.
6. Keyframe the property in a new animation.
7. Examine the keyframe by bringing it up in the inspector.

### Minimal reproduction project

[Export Enum Bug.zip](https://github.com/godotengine/godot/files/7414164/Export.Enum.Bug.zip)
Repository: flutter
Issue: Debug check that TransitionRoute (and subclasses) that are marked as non-opaque actually have a transparent pixel
Labels: c: new feature,framework,perf: speed,P3,team-framework,triaged-framework

https://api.flutter.dev/flutter/widgets/TransitionRoute/opaque.html

We should make sure that once the transition is complete, a rasterized version of the route has at least one non-opaque pixel if `opaque == false`, since setting opaque to false has performance implications that are wasted if the route behind the current one is invisible.
Repository: godot
Issue: Editor wide glitch after idling in the background
Labels: bug,topic:rendering,topic:editor,needs testing

### Godot version

 v4.0.dev.20211015.official [f113dc986]

### System information

Windows 64bit, Nvidia dedicated 765M

### Issue description

I had Godot 4 idling in the background (not visible) for a while I was working in the Browser and on Godot3 projects. When I came back to bring Godot 4 window into the front again, this is what I saw:

![godot_4_glitch](https://user-images.githubusercontent.com/47016402/138788743-a52cbbe4-e6e7-4158-8597-ac3545563941.png)

The Editor has not crashed btw. I can still zoom in and out and everything feels as responsive as usual. It's just totally glitched in terms of rendering.

### Steps to reproduce

Not exactly sure how to replicate this other than have Godot 4 idle in the background.
I've had this happening a few times already, not regularly or often though, but also with much older builds. I don't think that a new issue.

The project and scene is basically empty. I think it just had two sprite nodes in it, that's it.

### Minimal reproduction project

_No response_
Repository: rust
Issue: Detect heterogeneous generic recursion usage pre-monomorphization
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.
-->

(Request inspired by https://github.com/rust-lang/rust/issues/90063#issuecomment-950127053, after I wrote compiles-but-never-works code in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#the-opscontrolflow-type )

Given the following (minimal example) code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=584d7b447db0f7890d2f94c3b945640e

```rust
pub fn foo<T>(x: T) {
    if rand() {
        foo(&x);
    }
}
```
 
The current output is: *no errors nor warnings*

However, if it's ever called, it'll give an error like
```
error: reached the recursion limit while instantiating `foo::<&&&&&&&&&&&&&&&&&&&&&&&&&&...&&&&&&&&&&&&&&&&&&&&&&&&&&&&i32>`
```

It would be nice for the compiler to detect, pre-monomorphization, that this will never actually work because any possible monomorphization will end up requiring instantiating another additional monomorphization.

(Not catching all cases would be fine -- I suspect indirect recursion would be particularly annoying to detect well.  Maybe a deny-by-default lint for this?  It'd technically be a breaking change to make it a hard error, and I don't think it really *needs* to be hard error.  The lint is enough.)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: tauri
Issue: [meta] Tracking issue for overlay/Spotlight-like apps support
Labels: type: feature request

Features relevant for macOS overlay apps like Spotlight or Alfred:
- https://github.com/tauri-apps/tauri/issues/2258
- https://github.com/tauri-apps/tao/issues/182
- https://github.com/tauri-apps/tauri/pull/3689
- https://github.com/tauri-apps/tao/issues/105
- https://github.com/tauri-apps/tao/issues/185
- https://github.com/tauri-apps/tao/issues/189
- https://github.com/tauri-apps/tao/issues/186
- https://github.com/tauri-apps/tao/issues/187
Repository: pytorch
Issue: [docs] Google finds docs pages that give 404
Labels: high priority,module: docs,triaged

Found https://pytorch.org/vision/stable/_modules/torchvision/ops/focal_loss.html - gives 404

The existing one: https://pytorch.org/vision/stable/ops.html?highlight=focal_loss#torchvision.ops.sigmoid_focal_loss

It seems to be a source code page, so link to source from the existing url also gives 404.

I propose that the source code pages are properly deleted from Google along with https://github.com/pytorch/pytorch/issues/66408 and not just give 404.

Also, code-based snippets are quite bad. And somehow fvcore repo gets ranked higher than pytorch.org :(

![image](https://user-images.githubusercontent.com/1041752/138795668-21e4a3c6-e536-4e9d-8440-420986413add.png)

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @brianjo @mruberry @fmassa @malfet 

Btw would be nice to log 404 somehow and try to remove these pages from Google. Removing them from Google may require creating back placeholder for these files and adding correct meta headers. Another question: why doesn't Google remove these 404 pages itself? Why doesn't it reindex it?

@malfet If there was a CI spider checking docs for 404, this massive one (probably some configuration error) would have been found automatically.