sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: TypeError: Cannot read property 'get' of undefined at Object.getJSXImplicitImportBase
Labels: Bug,Rescheduled

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

ts getJSXImplicitImportBase
ts jest getJSXImplicitImportBase
ts file.pragmas

### 🕗 Version & Regression Information

4.2.4

- This is the behaviour in every version I tried, and I reviewed the FAQ for entries about everything but it hasn't been covered.

### ⏯ Playground Link

I can't provide a link to a playground as this issue seems to be tied to the structure of the repository and dependencies.
I have tried to reproduce a minimal example but without luck for now.

### 💻 Code

This seems to be tied to the structure of the repository and dependencies:

- There are 2 monorepositories - `core` and `product`
- One of the packages in `core` is `toast`
- In `product` there are `ui` and `services`
- Both`ui` and `services` are dependent on `toast` which is installed as an external dependency from npmjs registry in both of them
- `ui` is dependent on `services`
```txt
     toast   <-- external dependency (core monorepo)
      |  |
services |  <-- product monorepo
     \   |       
       ui   <-- product monorepo
```
In `ui` there is a `Toast` with custom visual implementations for the `toast` from `core` with its own tests.

### 🙁 Actual behavior

Running tests with `npx jest packages/ui/src/components/Toast/__tests__/Toast.spec.tsx` crashes with:
```
TypeError: Cannot read property 'get' of undefined

      at Object.getJSXImplicitImportBase (../../node_modules/typescript/lib/typescript.js:19175:95)
      at transformSourceFile (../../node_modules/typescript/lib/typescript.js:88624:51)
      at transformSourceFileOrBundle (../../node_modules/typescript/lib/typescript.js:82540:57)
      at transformation (../../node_modules/typescript/lib/typescript.js:100190:24)
      at transformRoot (../../node_modules/typescript/lib/typescript.js:100217:82)
      at Object.transformNodes (../../node_modules/typescript/lib/typescript.js:100201:78)
      at emitJsFileOrBundle (../../node_modules/typescript/lib/typescript.js:100852:32)
      at emitSourceFileOrBundle (../../node_modules/typescript/lib/typescript.js:100799:13)
      at forEachEmittedFile (../../node_modules/typescript/lib/typescript.js:100520:34)
      at Object.emitFiles (../../node_modules/typescript/lib/typescript.js:100779:9)
```

when inspecting the issue I have noticed this behaviour:
- The file that causes the crash is `packages/ui/node_modules/@private/core-toast/src/index.ts`
- `SourceFileObject` of this file is missing `pragmas` map
- But it contains `redirectInfo` with `redirectTarget`: `packages/ui/node_modules/@private/product-services/node_modules/@private/core-toast/src/index.ts`
- The `SourceFileObject` from this `redirectInfo` contains `pragmas` map

This happens during local development as well as in travis CI.

### 🙂 Expected behavior

The jest tests run without crashing.

### Maybe related issue
[#43373](43373)
Repository: rust
Issue: const cycle detected error messages are confusing
Labels: A-diagnostics,T-compiler

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
pub const FOO: usize = foo();
pub const fn foo() -> usize { FOO }
```

The current output is:

```
error[E0391]: cycle detected when simplifying constant for the type system `FOO`
 --> src/lib.rs:1:1
  |
1 | pub const FOO: usize = foo();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: ...which requires simplifying constant for the type system `FOO`...
 --> src/lib.rs:1:1
  |
1 | pub const FOO: usize = foo();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires const-evaluating + checking `FOO`...
 --> src/lib.rs:1:1
  |
1 | pub const FOO: usize = foo();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: ...which requires normalizing `FOO`...
  = note: ...which again requires simplifying constant for the type system `FOO`, completing the cycle
  = note: cycle used when running analysis passes on this crate
```

The mention of "simplifying", the "type system" and "normalizing" is confusing.

An alternative proposed by @Kixiron is to just lean into "evaluating", something like:

```
error[E0391]: cycle detected when evaluating constant `main::FOO`
 --> src/main.rs:1:28
  |
1 | pub const FOO: usize = foo();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: ...which is used within function `foo()`
 --> src/main.rs:2:28
  |
2 | pub const fn foo() -> usize { FOO }
  |                               ^^^
note: ...which requires const-evaluating and checking `main::FOO`...
 --> src/main.rs:1:28
  |
1 | pub const FOO: usize = foo();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: ...which requires evaluating `main::FOO`...
  = note: ...which again requires evaluating constant `main::FOO`, completing the cycle
```
Repository: flutter
Issue: Automatic hot reload on file change
Labels: c: new feature,tool,P3,team-tool,triaged-tool

## Use case
Give all users the benefit of hot reload on file chnge.

Flutter IDE users get hot reload on file change due to logic in the VSCode and IntelliJ plugins tha triggers a hot reload every time a file saves. Users of other code editors miss out.

## Proposal

Add a flag to flutter_tools that enables hot reload on file change by using file watchers to detect when files change.
Repository: pytorch
Issue: Add a few tests to make sure new dispatch keys for backends are added properly.
Labels: triaged,module: dispatch

Currently when adding a new eager backend to PyTorch, it's required to add at least a backend key (e.g https://github.com/pytorch/pytorch/pull/57094) and it touches many files. 
To improve this process:
1. It'll be nice if the changes required by backend extender is minimal instead of touching a lot of files.
2. We probably want to add some fake tests cases to make sure printing/dispatching are working properly with the new key.
Repository: pytorch
Issue: Use the same CUDA stream for all RPCs within the same dist autograd context
Labels: oncall: distributed,feature,triaged,module: rpc

Today, each RPC will grab a stream from pool and run the target function. This works for RPC itself. However, the entire training loop contains forward-backward-opt. We have to make sure that all ops in the three steps are synchronized properly. Individual CUDA RPC stream syncs won't address the problem, as there are multiple RPCs launched separately. We tried to fix some of that problem by enforcing orders in the distributed autograd (see #57792), but it's still not sufficient, as optimizer step also needs to synchronize with the next iteration.

## Pitch

Add an argument to distributed autograd context to enforce all RPCs within the context use the same streams. And we will need a named stream to ensure CUDA stream synchronization across iterations. 

```python
named_streams = {
  torch.device(0) : "train",
  RemoteDevice("worker2/cuda:1" : "train",
}
for _ in next_batch():
  with dist_autograd.context(named_streams=named_streams):   # Better names are appreciated
    # forward
    # backward
    # opt.step
```

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @jjlilley @osalpekar @jiayisuse @mrzzd @agolynski @SciPioneer @H-Huang @cbalioglu @gcramer23
Repository: go
Issue: cmd/go: stop writing pkg.test executable in directory when profiling?
Labels: NeedsDecision

```
$ go test -bench=. -cpuprofile=cpu.pprof pkg
```

results in cmd/go writing `pkg.test` to the current directory. The original reason was so that `pkg.test` would be handy when running `go tool pprof`. But `go tool pprof` no longer requires access to the original executable, because the requisite information is in the profile itself.

Maybe we should stop writing it.
Repository: go
Issue: cmd/go: add pprof subcommand
Labels: NeedsDecision,FeatureRequest,GoCommand

`pprof` is an important part of the Go programmer's toolbox. Perhaps we should promote it to a direct subcommand of cmd/go, rather than via `go tool`. This would also let us provide a nicer help message and nicer flags for the most common and difficult to remember `pprof` command line flags, such as `-sample_index=inuse_objects`. The full `pprof` experience would still be available at `go tool pprof`, for scripts and muscle memory.
Repository: flutter
Issue: No default SkFontMgr on Fuchsia causes unexpected engine test behavior
Labels: engine,dependency: fuchsia,platform-fuchsia,P2,team-engine,triaged-engine

When tests or engine code (e.g. PerformanceOverlayLayer::MakeStatisticsText in flow/layers/performance_overlay_layer.cc) use a default constructed SkFont or otherwise rely on the default installed SkFontMgr, Skia will fallback to an empty typeface when there is no valid default font manager.

Fuchsia does not configure a font manager in this way, so unit tests run on Fuchsia will encounter this issue.  Drawn text blobs with an empty typeface can have empty bounds, which may lead to SkCanvas quick-rejecting them. This complicates or leads to incorrect test expectations when run on that platform vs. those that have a default installed font manager.

For now it seems reasonable to skip these tests on Fuchsia, but a longer term solution would be to update the engine to not rely on default SkFont in this way, or otherwise plumb SkFontMgr_New_Fuchsia to all necessary places. Another option would be to update MockCanvas to not utilize the quick-reject API and just record draw calls and update test expectations to reflect what's expected for Flutter to invoke on SkCanvas, and not what's expected of SkCanvas itself.
Repository: flutter
Issue: [web] unskip text_field_test.dart on desktop Safari
Labels: a: tests,engine,platform-web,P2,c: tech-debt,team-web,triaged-web

Test titled 'Refocuses when setting editing state' in `text_field_test.dart` fails on desktop Safari on LUCI, and only on LUCI. The test passes locally. We should figure out what's going on on LUCI and unskip it.
Repository: kubernetes
Issue: PVC using a volume snapshot data src must always provision a new PV
Labels: kind/bug,sig/storage,triage/accepted

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


#### What happened:

When a PVC is created using a volume snapshot, the pvc was bound to an available PV in the cluster

#### What you expected to happen:

A new PV should be provisioned to bind to the PVC

#### How to reproduce it (as minimally and precisely as possible):
```
1. Create a pvc pvc-src
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-src
  namespace: test
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
 
2. This dynamically provisioned a pv for me
3. Mounted this onto a pod and added some dummy data
4. Created another pvc pvc-src-1
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-src-1
  namespace: test
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

5. This dynamically provisioned another pv for me
6. Mounted this onto another pod and added some more dummy data
7. Created a volume snapshot snapshot-1 from pvc-src
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: snapshot-1
  namespace: test
spec:
  source:
    persistentVolumeClaimName: pvc-src

8. Created a new pvc pvc-snapshot-1 using snapshot-1 as the data src
9. This created a pv x for me
10. Used kubectl edit and changed the reclaim policy to Retain
11. Deleted pvc pvc-snapshot-1, the pv status changed to Released
12. Used kubectl edit and changed the pv claim ref to null. PV status became Available
13. Created a new volume snapshot snapshot-2 from pvc-src-1
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: snapshot-2
  namespace: test
spec:
  source:
    persistentVolumeClaimName: pvc-src-1

14. Created a new pvc pvc-snapshot-2 using snapshot-2 as the src
```

#### Anything else we need to know?:
https://kubernetes.slack.com/archives/C09QZFCE5/p1620669405248800

#### Environment:
- Kubernetes version (use `kubectl version`): 
```
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:02:01Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
```
- Cloud provider or hardware configuration: DigitalOcean
Repository: go
Issue: x/tools/gopls: add comma when completing the value of a key-value expression
Labels: FeatureRequest,gopls,Tools

If I complete an entire KV, I get the colon and comma:

```
_ = foo {
 <>
}
```
becomes
```
_ = foo {
  key: [value placeholder],
}
```

On the other hand, if I complete just the value, I have to go to the work of pressing the comma key myself:

```
_ = foo {
  key: <>
}
```
becomes
```
_ = foo {
  key: [value]
}
```

This could probably save me multiple keypresses per week.

@muirdm
Repository: pytorch
Issue: `type: ignore` everything
Labels: triaged,better-engineering

We have a bunch of exclusions in the mypy config at `mypy.ini`:

https://github.com/pytorch/pytorch/blob/ebb1b74f65a91626ed0e6f89bc7ebff1307ad7dc/mypy.ini#L45-L152

These are complicating local linters and make it harder for devs to see what they need to do to make their files mypy-ed (i.e. they'd have to know to go and disable it in the mypy config vs. just seeing an inline comment). We could:
1. Disable all the exclusions
2. Run mypy and save the output
3. Use the error log to codemod in `type: ignore[the-error]` to all offending lines
4. Commit removal of exclusions

cc @pytorch/pytorch-dev-infra
Repository: flutter
Issue: [flutter_markdown] MarkdownBody widgets generate links which violate kMinInteractiveDimension
Labels: package,team-ecosystem,has reproducible steps,P3,found in release: 2.0,found in release: 2.3,p: flutter_markdown,triaged-ecosystem

I'm using flutter_markdown 0.6.1 and Flutter version 2.0.6, and I really appreciate the package! It's honestly a life saver when rendering user-generated content.

When I use MarkdownBody to render markdown text with links, I notice that the links are often not large enough to successfully tap on the first try. Depending on the size of the font being used, the size of the tappable area may be well under kMinInteractiveDimension.

It's possible this could be considered a bug, but it's also possible that I am thinking about this problem incorrectly: How can I ensure that links rendered by MarkdownBody are sufficiently large so users can definitely tap them?

Possibly related? Although maybe not: https://github.com/flutter/flutter/issues/81737
Repository: rust
Issue: Bad error messages when passing and using 2 PartialEq or PartialOrd traits to function.
Labels: A-diagnostics,T-compiler

Given the following code:

```rust
<#![allow(unused)]
use std::cmp::Ordering;

fn main() {
    let m1 = MyStruct(0);
    let m2 = MyStruct(1);
    
   
    println!("{:?}",m1 == m2);
    println!("{:?}",m1 > m2);
}

fn test_eq(m1 :&impl PartialEq, m2 :&impl PartialEq) {
    println!("{:?}",m1 == m2);
}

fn test_ord(m1 :&impl PartialOrd, m2 :&impl PartialOrd) {
    println!("{:?}",m1 > m2);
}

#[derive(Debug)]
struct MyStruct(usize);

impl PartialEq for MyStruct {
    fn eq(&self, other: &Self) -> bool {
        self.0 == other.0
    }
}

impl PartialOrd for MyStruct {
        fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
            Some(self.0.cmp(&other.0))
        }
}>
```

Compilation fails with the following messages:

```
<error[E0277]: can't compare `impl PartialEq` with `impl PartialEq`
  --> src/main.rs:14:24
   |
14 |     println!("{:?}",m1 == m2);
   |                        ^^ no implementation for `impl PartialEq == impl PartialEq`
   |
   = note: required because of the requirements on the impl of `PartialEq<&impl PartialEq>` for `&impl PartialEq`
help: consider further restricting this bound
   |
13 | fn test_eq(m1 :&impl PartialEq + PartialEq<impl PartialEq>, m2 :&impl PartialEq) {
   |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> src/main.rs:18:26
   |
17 | fn test_ord(m1 :&impl PartialOrd, m2 :&impl PartialOrd) {
   |                  ---------------       --------------- found type parameter
   |                  |
   |                  expected type parameter
18 |     println!("{:?}",m1 > m2);
   |                          ^^ expected type parameter `impl PartialOrd`, found a different type parameter `impl PartialOrd`
   |
   = note: expected reference `&impl PartialOrd` (type parameter `impl PartialOrd`)
              found reference `&impl PartialOrd` (type parameter `impl PartialOrd`)
   = note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
```

Compilation fails on both "test_eq" and "test_ord" functions while the equivelant code when run from main compiles and runs. Moreover I find the errors confusing, especially the second where it states that 2 identical types are mismatched.

If the methods are changed to this:
```rust
fn test_eq<E :PartialEq>(m1 :E, m2 :E) {
    println!("{:?}",m1 == m2);
}

fn test_ord<P :PartialOrd>(m1 :P, m2 :P) {
    println!("{:?}",m1 > m2);
}
```
Then the code compiles and runs. The compiler messages don't make it clear to me at all, as a Rust noob, why any of this is happening.
Repository: rust
Issue: Automatic &mut reborrowing doesn't happen when arguments are for `impl Trait` 
Labels: A-diagnostics,T-lang,A-inference,D-confusing

Given code like this:

```rust
fn foo(a: &mut i32) {
    auto_reborrow(a); // works
    auto_reborrow(a); // works

    no_reborrow(a); // works
    no_reborrow(a); // ERROR
}

fn auto_reborrow(_: &mut i32) {}

fn no_reborrow(_: impl std::fmt::Debug) {}
```

it [currently fails to compile](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=da4bfbca0f68c6ede8308bb5228038da) with:

```
error[E0382]: use of moved value: `a`
 --> src/lib.rs:6:17
  |
1 | fn foo(a: &mut i32) {
  |        - move occurs because `a` has type `&mut i32`, which does not implement the `Copy` trait
...
5 |     no_reborrow(a); // works
  |                 - value moved here
6 |     no_reborrow(a); // ERROR
  |                 ^ value used here after move

error: aborting due to previous error
```

While not a super serious issue ergonomically it'd be great if rustc would apply the same automatic reborrowing logic here to `&mut T` arguments regardless of whether the target function takes a `&mut T` or it's satisfying an `impl Trait` bound of some form.
Repository: rust
Issue: Following compiler suggestions for fixing errors sends me in a loop between tuple syntax and struct syntax.
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics

I tried matching on the wrong error type. The compiler suggested I use a struct syntax instead of the tuple syntax. When I tried the suggested struct syntax it told me to use the same tuple syntax it had just told me not to use. I've been able to boil it down to a simpler repro case below. This is an analog of the fixed, working code:

```rust
use serde_yaml;

fn main() {
    let txt = "---\n- foo\n- bar";
    let word_list: Vec<String> = match serde_yaml::from_str(txt) {
        Ok(lst) => lst,
        Err(_) => Vec::new(),
    };
    println!("{:?}", word_list);
}
```

My first attempt I tried matching on the error type:

```rust
fn main() {
    let txt = "---\n- foo\n- bar";
    let word_list: Vec<String> = match serde_yaml::from_str(txt) {
        Ok(lst) => lst,
        serde_yaml::Error(_) => Vec::new(),
    };
    println!("{:?}", word_list);
}
```

I received this error:

```
error[E0532]: expected tuple struct or tuple variant, found struct `serde_yaml::Error`
  --> src/main.rs:7:9
   |
7  |         serde_yaml::Error(_) => Vec::new(),
   |         ^^^^^^^^^^^^^^^^^^^^ help: use struct pattern syntax instead: `serde_yaml::Error { 0 }`
   | 
  ::: /home/dvogel/.cargo/registry/src/github.com-1ecc6299db9ec823/serde_yaml-0.8.17/src/error.rs:14:1
   |
14 | pub struct Error(Box<ErrorImpl>);
   | --------------------------------- `serde_yaml::Error` defined here
```

I'm used to the errors being quite helpful so I didn't stop to think about the code I had written and tried the suggestion:

```rust
use serde_yaml;

fn main() {
    let txt = "---\n- foo\n- bar";
    let word_list: Vec<String> = match serde_yaml::from_str(txt) {
        Ok(lst) => lst,
        serde_yaml::Error{ 0 } => Vec::new(),
    };
    println!("{:?}", word_list);
}
```

Which led me to this error:

```
error[E0769]: tuple variant `serde_yaml::Error` written as struct variant
 --> src/main.rs:7:9
  |
7 |         serde_yaml::Error{ 0 } => Vec::new(),
  |         ^^^^^^^^^^^^^^^^^^^^^^
  |
help: use the tuple variant pattern syntax instead
  |
7 |         serde_yaml::Error(_) => Vec::new(),
  |                          ^^^
```

### Meta

This happens with the nightly version:

```
rustc --version --verbose
rustc 1.54.0-nightly (770792ff8 2021-05-07)
binary: rustc
commit-hash: 770792ff8d1ec542e78e77876ac936f43ffb8e05
commit-date: 2021-05-07
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.0
```

It does not happen with 1.52. With that version (as well as 1.47 and 1.50) I get:

```
error[E0532]: expected tuple struct or tuple variant, found type alias `serde_yaml::Result`
 --> src/main.rs:7:9
  |
7 |         serde_yaml::Result(_) => Vec::new(),
  |         ^^^^^^^^^^^^^^^^^^
  |
  = note: can't use a type alias as a constructor
```
Repository: pytorch
Issue: Support a dist.group_like API
Labels: oncall: distributed,module: bootcamp,triaged,pt_distributed_rampup,module: c10d

## 🚀 Feature

Sometimes it is useful to create a process group similar to another process group, but with a different backend. For example, this came up when using DDP for dense parameter synchronization and having to create a gloo pg with the same set of ranks for DDP across the sparse part (since NCCL doesn't yet support sparse tensors).

Currently we have to do something like the following:
```
gloo_pg = dist.new_group(backend='gloo', ranks=[i for i in range(dist.get_world_size())])
```

It is a bit more cumbersome if we have to create groups that not all ranks are a part of:
```
subgroup = dist.new_group(backend='nccl', ranks=...)
# create a gloo group like subgroup
ranks = [i for i in range(dist.get_world_size()) if not dist._rank_not_in_group(i, subgroup)] # have to use private API, as there is no easy way to determine if ranks are not part of a group
gloo_pg = dist.new_group(backend='gloo', ranks=ranks)
```

This also doesn't consider the user having to set the timeout and any other process group options to be the same.

Instead of that, it would be much easier if we did:
```
gloo_pg = dist.group_like(pg, backend='gloo')
```
which results in an equivalent group (ranks, timeout, etc) with the given backend.

## Motivation

The main motivation here is providing this syntactic sugar for better user code.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23