sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: auto import with tsconfig alias paths to node_modules
Labels: Suggestion,Help Wanted,Experience Enhancement,Domain: Auto-import

<!-- ⚠️⚠️ 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.71.2`
- OS Version: `Windows 11`

Steps to Reproduce:

1. Configure a tsconfig.json which has alias paths to node_modules

    ```json
    {
      "compilerOptions": {
        "allowJs": true,
        "jsx": "react",
        "baseUrl": ".",
        "checkJs": true,
        "noEmit": true,
        "esModuleInterop": true,
        "resolveJsonModule": true,
        "paths": {
          "theme/*": [
            "./src/web/theme/*",
            "./node_modules/my-library/my-module-a/web/theme/*",
            "./node_modules/my-library/my-module-b/web/theme/*",
            "./node_modules/my-library/my-module-c/web/theme/*",
          ],
          "web/*": [
            "./src/web/*",
            "./node_modules/my-library/my-module-a/web/*",
            "./node_modules/my-library/my-module-b/web/*",
            "./node_modules/my-library/my-module-c/web/*",
          ],
          "server/*": ["./node_modules/my-library/src/server/*"],
          "config/*": [
            "./src/config/*",
            "./node_modules/my-library/my-module-a/config/*",
            "./node_modules/my-library/my-module-b/config/*",
            "./node_modules/my-library/my-module-c/config/*",
          ],
        }
      }
    }
    ```
1. Try to import an existing file under the alias in node_modules
 
The autocomplete would prefer to use the `my-library` as a package instead of the shorter alias path, for example it would suggest:

```jsx
import Image from "my-library/my-module-a/web/theme/Image"
import Image from "my-library/my-module-b/web/theme/Image"
import Image from "my-library/my-module-c/web/theme/Image"
```

But it will not suggest:
```jsx
import Image from "theme/Image"
```

although that alias works perfectly fine when adding it manually.
Repository: go
Issue: x/net/nettest: TestTestConn failures
Labels: NeedsInvestigation

```
#!watchflakes
post <- pkg == "golang.org/x/net/nettest" && test ~ `^TestTestConn`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/3cb5bc7cbacc3918c671b87355d32cce28fa858e)):

    --- FAIL: TestTestConn (1.15s)
        --- FAIL: TestTestConn/UnixPacketPipe (0.34s)
            --- FAIL: TestTestConn/UnixPacketPipe/BasicIO (0.01s)
                conntest.go:93: transmitted data differs


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: flutter
Issue: Proposal to Change the InkSparkle Animation
Labels: c: new feature,platform-android,framework,f: material design,c: proposal,P3,team-android,triaged-android

`1. What if you increase the size of the sequins and the distance between them, because they are not very noticeable?`
`2. Remove the tonal glow from the splash, or if I misunderstood, the InkSparkle color is not correct.`

![Screenshot_2022_10_04_19_52_24_514_com_example_sliver_appbar_m3](https://user-images.githubusercontent.com/102767277/193897333-5e5de8dc-6f26-45ef-8a97-0d5a7567ce2c.jpg)
![Screenshot_2022-10-04-21-15-24-891_com aspiro tidal](https://user-images.githubusercontent.com/102767277/193897327-0c86679c-86d3-4dea-a6f9-c8faeeb6c7bd.jpg)

<hr>

`3. After playing the splash animation, the glitter disappears, but the circle with a tonal transition of color does not remain, compared to the native one.`
`4. The tonal circle should be animated, i.e. increase at the beginning of the animation, and decrease after the splash animation.`
`5. Animations on native android take a little longer to play than on Flutter, although the current solution is not bad.`

![Screenshot_2022_10_04_21_20_01_813_com_example_sliver_appbar_m3](https://user-images.githubusercontent.com/102767277/193898816-cc867b32-8f63-4ede-a3e2-ff0e507d986d.jpg)
![Screenshot_2022-10-04-21-23-11-851_com aspiro tidal](https://user-images.githubusercontent.com/102767277/193898813-eb915780-4b53-45f5-94b3-0fab8d7c1e54.jpg)
<hr>
https://user-images.githubusercontent.com/102767277/193905762-9c9566ee-be31-4f4e-9b10-67b9ae59c032.mp4

#91605
Repository: flutter
Issue: [Mac] - Scrolling momentum has disappeared from Listener scroll signal
Labels: framework,platform-mac,f: scrolling,a: desktop,has reproducible steps,P2,found in release: 3.3,team-macos,triaged-macos

In `super_editor` we use a `Listener` widget to implement scrolling in our documents. 

Before Flutter 3.3, when scrolling with a Magic Mouse on Mac, the `Listener` widget reported events that implicitly included momentum. In other words, if we simply added `event.scrollDelta.dy` to our scroll offset, we would get scroll momentum for free.

In Flutter 3.3, that momentum is gone. This has made our scrolling experience unacceptably bad.


https://user-images.githubusercontent.com/7259036/193917727-df76fcd6-8fb9-466f-9209-b81510c459fb.mov

I don't have a full repro, but here are the relevant pieces:

```dart
void _scrollOnMouseWheel(PointerSignalEvent event) {
    if (event is PointerScrollEvent) {
      widget.autoScroller.jumpBy(event.scrollDelta.dy);
    }
  }

@override
  Widget build(BuildContext context) {
    return Listener(
      onPointerSignal: _scrollOnMouseWheel,
      // Note: in our actual code we have a bunch of stuff between the Listener and the SingleChildScrollView
      child: SingleChildScrollView(
        controller: _scrollController,
        physics: const NeverScrollableScrollPhysics(),
        child: child,
      ),
    );
  }
```

Flutter version:
```
Flutter 3.3.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 18a827f393 (6 days ago) • 2022-09-28 10:03:14 -0700
Engine • revision 5c984c26eb
Tools • Dart 2.18.2 • DevTools 2.15.0
```
Repository: flutter
Issue: [Mac] - Should be able to disable pointer event pass through on gaining window focus
Labels: c: new feature,framework,platform-mac,c: proposal,a: desktop,f: focus,P3,team-macos,triaged-macos

Consider a Mac desktop environment with multiple application windows open.

Historically, when the user taps on a non-focused Flutter window on Mac, that tap causes the window to receive focus, but it **doesn't** cause a tap event in the newly focused window. This is a nice feature because often only a small part of a window might be visible, so the user may not have a good place to tap to switch window focus. The user doesn't want to inadvertently tap a button that changes the content in the window.

In Flutter 3.3, it appears that a tap to focus a Flutter Mac window also sends a tap event, making it more difficult in some scenarios to switch focus without impacting the app.

For example, I'm currently debugging issues in `SuperEditor` related to text selection. My IDE and my Flutter window are on the same screen. I need to switch back and forth between them. Every time that I switch from my IDE to my Flutter window, by tapping the Flutter window, I inadvertently move the text selection somewhere else, because the tap to switch focus was handled like an intentional user interaction.

If this change was intentional, then I would suggest introducing control over this behavior.

Flutter version:
```
Flutter 3.3.3 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 18a827f393 (6 days ago) • 2022-09-28 10:03:14 -0700
Engine • revision 5c984c26eb
Tools • Dart 2.18.2 • DevTools 2.15.0
```
Repository: go
Issue: os: document concurrency properties for File methods
Labels: ExpertNeeded,Documentation,NeedsInvestigation

### What version of Go are you using (`go version`)?

https://pkg.go.dev/os@go1.19.1

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

For #50436, I'm attempting to unblock reads on a `*File` returned by `os.Pipe` while it is being read concurrently by a user-controlled goroutine. The user-controlled goroutine may legitimately call the `Close` method, and may expect to be able to access other methods (such as `SetDeadline`) via type-assertion.

### What did you expect to see?

Given #6270, #7970, #9307, #17647 and https://go.dev/cl/65490, I expected the documentation for `*os.File to describe which methods are safe to invoke concurrently and under what conditions.

### What did you see instead?

The only mention of concurrency I could find in https://pkg.go.dev/os@go1.19.1 says this:
> Note: The maximum number of concurrent operations on a File may be limited by the OS or the system. The number should be high, but exceeding it may degrade performance or cause other issues.

That seems to imply that at least some of the `File` methods may be invoked concurrently, but isn't explicit about which ones.

I see unsynchronized writes in the `Close` implementation on both [`unix`](https://cs.opensource.google/go/go/+/master:src/os/file_unix.go;l=259;drc=6d8ec893039a39f495c8139012e47754e4518b70) and [`plan9`](https://cs.opensource.google/go/go/+/master:src/os/file_plan9.go;l=159;drc=81431c7aa7c5d782e72dec342442ea7664ef1783) (but maybe not `windows`?); it's not obvious to me which other methods are or aren't safe.

(CC @rsc @ianlancetaylor @robpike from previous `*File` race conditions.)
Repository: kubernetes
Issue: remove rsync from build
Labels: priority/backlog,sig/release,lifecycle/frozen,triage/accepted

There's a _lot_ of complexity in the build system around rsync + build + data containers.

This was mostly added to work around docker desktop filesystem performance on macOS, but also used to support building against docker on a remote VM.

Besides the docker desktop licensing changes probably reducing how many developers are actually using docker desktop, it's not clear that we should still be jumping through this many hoops in the build.

OTOH, removing it may be fairly involved, and it's possible the performance gap is still substantial, even if using filesystem caching (which appears to be replaced now https://github.com/docker/for-mac/issues/5402).

We should test performance and weigh ripping this stuff out to simplify the build.

cc @thockin @cblecker

/sig release
Repository: rust
Issue: prevent negative impl cycles
Labels: P-low,I-unsound,requires-nightly,F-negative_impls,T-types

When integrating negative impls into a-mir-formality, I realized a problem with the current check. 

The current logic has a check that, at its heart, boils down to this:

* If there are two overlapping impls and one impl requires `T: Trait`, and we can prove `T: !Trait`, then this impl can be ignored.

This assumes that the coherence checker is guaranteeing that `T: Trait` and `T: !Trait` do not hold for the same `T`. This is generally true, but there is a trick, because this code is running *during* coherence. So you can wind up with the coherence check for `Trait` (which has the job of proving that `T: Trait` and `T: !Trait` do not overlap) also relying on that same condition. 

In the current trait checker, this leads to a cycle, but in a-mir-formality, which permits cycles, it leads to unsoundness. Given that I plan to propose that we allow cycles for all traits (i.e., coinductive semantics), this is a problem.

Here is an example test:

```rust
trait MyTrait { }

struct Foo { }

impl !MyTrait for Foo { }

impl MyTrait for Foo
where
    Foo: MyTrait // in formality, this would work
{ }
```

What happens in this test:

* We see that the two impls overlap.
* We see that the second impl has `Foo: MyTrait` and try to prove `Foo: !MyTrait`, which succeeds (there is a negative impl, after all).
* We conclude that the two impls are disjoint (but that's not true, obviously).

I'll leave discussion on the best way to fix this for issue text.
Repository: stable-diffusion-webui
Issue: (Linux) --gfpgan-models-path and --gfpgan-dir both seem to be ignored
Labels: bug-report

**Describe the bug**
When running with either or both flags to use a specific directory for gfpgan models, they seem to be ignored completely. Model files will automatically be downloaded to stable-diffusion-webui/models/GFPGAN

**To Reproduce**
run the webui with something like "python webui.py --gfpgan-models-path /mnt/stable-diffusion-models/gfpgan/"

**Expected behavior**
Models that already exist in the specified directory should be used. New model files should not be downloaded to the default directory.

**Desktop (please complete the following information):**
 - OS: Arch Linux
 - Commit revision: ef40e4cd4d383a3405e03f1da3f5b5a1820a8f53

Obviously this isn't the end of the world as it'll still run. It'd be nice to be able to use this flag though.
Repository: stable-diffusion-webui
Issue: Include RestoreFormer
Labels: enhancement

Could you consider including [RestoreFormer](https://github.com/wzhouxiff/RestoreFormer) as a face restoration step? (It's unrelated to CodeFormer, despite its name).

Their results are state of the art and I'd love to have it as an option.
The guys behind [GFPGAN](https://github.com/TencentARC/GFPGAN) have added [RestoreFormer inference code](https://github.com/TencentARC/GFPGAN/blob/master/gfpgan/archs/restoreformer_arch.py) so maybe you can just [yoink](https://www.dictionary.com/browse/steal) that.
Repository: material-ui
Issue: [Paper] Custom variants disregard elevation prop
Labels: component: Paper

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Steps:

1. Create a custom Paper variant
2. Add variant prop with the new variant to a Paper component (or Paper-composed components e.g. Card)
3. Add elevation prop greater than 0 to component
4. Inspect Paper component's properties. The elevation's box-shadow and classnames will be missing.

[Codesandbox demo](https://codesandbox.io/s/paper-variant-doesnt-inherit-elevation-lrkjgl?file=/demo.js)

### Current behavior 😯

If you create a custom variant for a Paper component, it won't include any elevation styles if you try to add the `elevation` prop in tandem with the custom variant prop e.g. 
`<Paper variant="blue" elevation={5}>No elevation shadows here</Paper>`

### Expected behavior 🤔

Custom variants should include the default elevation styles unless explicitly overridden

### Context 🔦

I'm attempting to create a new Paper variant and expect it to inherit all the other styles of Paper.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
Browser: Chrome 105.0.5195.125
System:
    OS: macOS 12.6
  Binaries:
    Node: 16.13.2 - ~/.nvm/versions/node/v16.13.2/bin/node
    Yarn: Not Found
    npm: 8.5.5 - ~/.nvm/versions/node/v16.13.2/bin/npm
  Browsers:
    Chrome: 105.0.5195.125
    Edge: Not Found
    Firefox: 103.0.1
    Safari: 16.0
  npmPackages:
    @emotion/react: ^11.10.4 => 11.10.4
    @emotion/styled: ^11.10.4 => 11.10.4
    @mui/base:  5.0.0-alpha.98
    @mui/core-downloads-tracker:  5.10.6
    @mui/icons-material: ^5.10.6 => 5.10.6
    @mui/lab: 5.0.0-alpha.101 => 5.0.0-alpha.101
    @mui/material: ^5.10.6 => 5.10.6
    @mui/private-theming:  5.10.6
    @mui/styled-engine:  5.10.8
    @mui/system:  5.10.8
    @mui/types:  7.2.0
    @mui/utils: ^5.10.6 => 5.10.6
    @mui/x-data-grid:  5.17.5
    @mui/x-data-grid-pro: ^5.17.5 => 5.17.5
    @mui/x-date-pickers: 5.0.3 => 5.0.3
    @mui/x-date-pickers-pro: 5.0.3 => 5.0.3
    @mui/x-license-pro: ^5.17.0 => 5.17.0
    @types/react: ^18.0.21 => 18.0.21
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.8.4 => 4.8.4
```
</details>
Repository: flutter
Issue: Remove `use_xcode_clang` property from buildroot
Labels: engine,platform-windows,P2,c: tech-debt,team-engine,triaged-engine

ANGLE used to require that `use_xcode_clang` be set [when used outside of Chromium](https://bugs.chromium.org/p/angleproject/issues/detail?id=5440#c2).  The latest ANGLE version no longer uses that property, so remove from buildroot.

See https://github.com/flutter/buildroot/pull/407 and https://github.com/flutter/buildroot/pull/432

https://github.com/flutter/buildroot/blob/33358ba597f875f6646522fd4ea86c1b31404d77/build/toolchain/toolchain.gni
https://github.com/flutter/buildroot/blob/87d5dcb98983da54257f6f39d3beee2989cb0e47/build_overrides/angle.gni#L5-L6
Repository: go
Issue: cmd/compile: panic for cyclic generic interfaces
Labels: NeedsInvestigation,compiler/runtime

```Go
package p

type I[R any] interface{ m() R }
type J I[interface{ J }]
```
causes a type-checker panic:
```
$ go tool compile testdata/manual.go 
<unknown line number>: internal compiler error: panic: nil underlying

goroutine 1 [running]:
runtime/debug.Stack()
        /Users/gri/goroot/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x0?, 0x0?}, {0x1980893, 0x9}, {0xc0000c9d98, 0x1, 0x1})
        /Users/gri/goroot/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
        /Users/gri/goroot/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/gc.handlePanic()
        /Users/gri/goroot/src/cmd/compile/internal/gc/main.go:49 +0x95
panic({0x18eab80, 0x1aa3cc8})
        /Users/gri/goroot/src/runtime/panic.go:884 +0x213
cmd/compile/internal/types2.(*Checker).handleBailout(0xc0003be000, 0xc0000cb0d8)
        /Users/gri/goroot/src/cmd/compile/internal/types2/check.go:294 +0x8b
panic({0x18eab80, 0x1aa3cc8})
        /Users/gri/goroot/src/runtime/panic.go:884 +0x213
cmd/compile/internal/types2.(*Named).under(0xc00039b7a0)
        /Users/gri/goroot/src/cmd/compile/internal/types2/named.go:494 +0x3a5
...
```
(reported by @mdempsky)
Repository: go
Issue: cmd/compile: wrong type reported for generic cyclic interface
Labels: NeedsInvestigation,compiler/runtime

```Go
package main

import "fmt"

type I[R any] interface{ m() R }
type J interface{ I[interface{ J }] }

func main() {
	fmt.Printf("%T\n", J.m)
}
```
reports the wrong type when [run](https://go.dev/play/p/vZXbzyWQ6Oz?v=gotip):
```
func(main.J) interface {}
```
(reported by @mdempsky)
Repository: storybook
Issue: Errors in CSF files are logged but do not break the Storybook in SSv6
Labels: bug,core

**Describe the bug**

If you have a top-level error in a CSF file, causing the file not to execute, it is "swallowed" by `executeLoadable`:

https://github.com/storybookjs/storybook/blob/6d6a43217acdf3356bb830cc14cb88565c51c759/code/lib/core-client/src/preview/executeLoadable.ts#L37

The Storybook continues to load (with an error in the console), leading to a partial Storybook. This leads in particular to problems with integrators like Chromatic that rely on an accurate list of stories.

**To Reproduce**
Add `throw new Error('foo')` to a CSF file, in ssv6 mode.

**Additional context**
Arguably a breaking change to change the behaviour, so we should do it in 7.0
Repository: storybook
Issue: Resolve issue with smoke-testing `cra/default-ts`
Labels: bug,build

**Describe the bug**
The `cra/default-ts` smoke test task works but then regularly times out (maybe 80% of the time). The `execa()` call just never returns (see https://github.com/storybookjs/storybook/pull/19306 for investigations).

We have no idea why but it happens only for that template, we can speculate that maybe it uses more memory or something.

**Possible fixes**

First off we want to just update `execa` (and maybe node also) and see if it goes away.

Otherwise, we might have to try and create a reproduction, get it going on CI and then see if we can debug into execa to see what's happening (doesn't sound fun). So let's do the former and hope for luck 🤞 

Once it is fixed we should revert this commit: 17ddcb71ba
Repository: rust
Issue: generic_const_exprs: Exact same code compiles as unit test but fails to compile as integration test
Labels: C-bug,requires-nightly,F-generic_const_exprs,requires-incomplete-features

This is a minimal reproduction of an issue I encountered when I tried to use const generics in my library.

lib.rs:

```rust
#![feature(generic_const_exprs)]

pub trait NotEqual<Other> {}

impl<const X: u64, const Y: u64, T, U> NotEqual<U> for T
where
    T: IdType<Id = Id<X>>,
    U: IdType<Id = Id<Y>>,
    (): IsFalse<{ X == Y }>,
{
}

pub trait IdType {
    type Id;
}

pub struct Id<const ID: u64>;

trait IsFalse<const B: bool> {}
impl IsFalse<false> for () {}


#[cfg(test)]
mod tests {
    use super::*;
    struct A;
    impl IdType for A {
        type Id = Id<0>;
    }

    struct B;
    impl IdType for B {
        type Id = Id<1>;
    }

    fn require_not_equal<A, B>(_: A, _: B)
    where
        A: NotEqual<B>,
    {
    }

    #[test]
    fn testy() {
        require_not_equal(A, B);
    }
}
```

tests/same_test.rs:
```rust
use const_wtf::{Id, IdType, NotEqual};

struct A;
impl IdType for A {
    type Id = Id<0>;
}

struct B;
impl IdType for B {
    type Id = Id<1>;
}

fn require_not_equal<A, B>(_: A, _: B)
where
    A: NotEqual<B>,
{
}

#[test]
fn testy() {
    require_not_equal(A, B);
}
```

`cargo test`:
```
error[E0277]: the trait bound `(): const_wtf::IsFalse<_>` is not satisfied
  --> tests/same_test.rs:21:23
   |
21 |     require_not_equal(A, B);
   |     ----------------- ^ the trait `const_wtf::IsFalse<_>` is not implemented for `()`
   |     |
   |     required by a bound introduced by this call
   |
   = help: the trait `const_wtf::IsFalse<false>` is implemented for `()`
   = note: required for `A` to implement `NotEqual<_>`
note: required by a bound in `require_not_equal`
  --> tests/same_test.rs:15:8
   |
13 | fn require_not_equal<A, B>(_: A, _: B)
   |    ----------------- required by a bound in this
14 | where
15 |     A: NotEqual<B>,
   |        ^^^^^^^^^^^ required by this bound in `require_not_equal`

For more information about this error, try `rustc --explain E0277`.
```

`rustc --version --verbose`:
```
rustc 1.66.0-nightly (470e518c4 2022-09-27)
binary: rustc
commit-hash: 470e518c4b43265020c882bcf3c86632f5494910
commit-date: 2022-09-27
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.0
```
I updated to
```
rustc 1.66.0-nightly (01af5040f 2022-10-04)
binary: rustc
commit-hash: 01af5040fdada6ef8f1b749cda798d80a8590b2c
commit-date: 2022-10-04
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.2
```
and got the same output.
Repository: neovim
Issue: disable horizontal window separators
Labels: enhancement,ui

### Feature already in Vim?

_No response_

### Feature description

Currently, while using both `laststatus=3` and `winbar`, there are two horizontal separators (`winbar` and `fillchars`).

Cause `winbar` already acts as horizontal separators like `laststatus=2`, these `fillchars` (`horiz`, `horizup`, `horizdown`) are needless.

It would be great if there is an option to remove these `fillchars` or they just disabled automatically when both `laststatus=3` and `winbar` are enabled.

<img width="1032" alt="image" src="https://user-images.githubusercontent.com/60088301/193958382-8f3c89cd-8fc7-45cd-ad3f-2d0aefa18410.png">