sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Add quick fix to export unexported members to fix unresolved symbol errors
Labels: Suggestion,Awaiting More Feedback,Domain: Quick Fixes

## Search Terms

import
export
unexported
symbols
auto import
completion
global
globals
intellisense

## Suggestion

tsserver can auto-complete exported symbols from other modules, and add an import statement that imports the symbol you selected.

It should also suggest **global symbols** from other modules that are ***not* exported**, and add the *export* keyword if the suggestion is selected.

## Use Cases

When I write a module I can't predict every use case of it, and I only export the global symbols that I think other modules would need to use. But when I'm working on a different module and I realize I want to use a symbol which is not exported by the other module (or maybe I don't even remember if it is or isn't exported), I would like my editor to export and import it for me instead of me having to find that symbol manually (because even go-to definition won't work) and export it, and then go back and auto-complete to auto-import.

This is also very very **very** useful when converting a web project to use imports. You can just go over all of the "undeclared symbol" errors and auto-complete to export and import the correct symbol.

## Examples

*module.ts*:
```ts
function foo(name = 'World') {
  console.log('Hello ' + name);
}

export function bar() {
  foo();
}
```

*app.ts*:
```ts
import { bar } from './module.ts';

bar();
```

I now want to customize the "hello" message, so I start typing `foo` and then wait for completion suggestions which include the function `foo` from `module.ts`.

After selecting that, the symbol `foo` is automatically exported and imported for me, and I can use it immediately:

*module.ts*:
```ts
export function foo(name = 'World') {
  console.log('Hello ' + name);
}

export function bar() {
  foo();
}
```

*app.ts*:
```ts
import { bar, foo } from './module.ts';

bar();
foo('TypeScript');
```

## Checklist

My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: reflective padding for 5D tensor
Labels: triaged,function request,module: padding

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
Reflective padding can be implemented for 5D tensor.
## Motivation
Reflective padding works great in image convolution. However, it is not yet implemented for 3D data (5D tensors)
<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch
Reflective padding be implemented for 5D tensor.
<!-- A clear and concise description of what you want to happen. -->

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

I've made a python implementation of this in #28215.  However, a fix implemented in [csrc](https://github.com/pytorch/pytorch/blob/master/torch/csrc) would be better

## Additional context
This padding can be applied for 5D tensors, however, it is not implemented.
<!-- Add any other context or screenshots about the feature request here. -->
Repository: bitcoin
Issue: bench: Add BIP 143 sighash benchmark
Labels: Feature,Tests

I believe there is no benchmark for the BIP 143 signature hash. Just for completeness, it would be nice to have a few different sighash flags benchmarked.
Repository: pytorch
Issue: index_sub, index_mul and index_div
Labels: triaged,enhancement,OSS contribution wanted

## 🚀 Feature
Provide `index_sub`, `index_sub_`, `index_mul` etc. functions that work like existing functions `index_add` and `index_add_`

## Motivation
If we have a 2-dimensional tensor `T`, and want to multiply `T[0]`, `T[3]` and `T[15]` by 2, there seems to be no way to do this at the moment (in the case where the number of rows we want to multiply by 2 is variable). `index_mul_` would enable us to accomplish this by calling `T.index_mul_(0, torch.tensor([0, 3, 15]), torch.full((3, T.shape[1]), 2.0))`, the way `index_add_` allows adding 2 right now.

## Alternatives
`index_sub`, in particular, can be worked around using `index_add` right now, but is less efficient since it involves negating a tensor first. I do not know of any alternatives to the other two, short of taking exponents and logarithms of the entire tensor.
Repository: create-react-app
Issue: Coverage report not working
Labels: issue: bug,issue: needs investigation

### Describe the bug
The problem is that I can't get the coverage report for any project. I used a brand new cra project to test if something is wrong locally but I still have the same problem.
This is what I am supposed to see:
![image](https://user-images.githubusercontent.com/18174459/67017097-16dbf380-f0ae-11e9-9fed-f9689bd67029.png)
Taken from: https://create-react-app.dev/docs/running-tests/#coverage-reporting

And this is what I see instead:
![image](https://user-images.githubusercontent.com/18174459/67017174-33782b80-f0ae-11e9-8f17-ede231fce6f9.png)


### Did you try recovering your dependencies?
I did.
yarn --version
1.19.1

### Environment

Environment Info:

  System:
    OS: macOS 10.15
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
  Binaries:
    Node: 12.12.0 - /usr/local/bin/node
    Yarn: 1.19.1 - /usr/local/bin/yarn
    npm: 6.11.3 - /usr/local/bin/npm
  Browsers:
    Chrome: 77.0.3865.120
    Firefox: 69.0
    Safari: 13.0.2
  npmPackages:
    react: ^16.10.2 => 16.10.2 
    react-dom: ^16.10.2 => 16.10.2 
    react-scripts: 3.2.0 => 3.2.0 
  npmGlobalPackages:
    create-react-app: 0.3.0

### Steps to reproduce
1. Create a new project using CRA
2. You will see the 3.2.0 version of react-scripts
3. Run npm test -- --coverage or yarn test --coverage

### Expected behavior
I should see the coverage report including the App.js file.

### Actual behavior
I see no file included in the report:
![image](https://user-images.githubusercontent.com/18174459/67017602-ddf04e80-f0ae-11e9-9aa7-8957165d282d.png)


### Reproducible demo
Just used the latest CRA version in an empty project.
Repository: go
Issue: runtime: throw should print more diagnostics
Labels: NeedsFix,compiler/runtime

As of Go 1.14 tip, `runtime.throw` enables slightly more diagnostic information in the traceback. It would help with debugging runtime crashes if it printed more diagnostics, such as:

1. FP/SP/and PC for all frames in all goroutines, not just the throwing goroutine (which doesn't even work if the throw happens on a system stack)
2. Runtime frames on all goroutines.
3. The `*g` of each goroutine. When a crash involves the scheduler or GC, we often see g pointers in arguments, but generally can't match these up to goroutines in the traceback.
4. Whether or not the world is stopped, or GC is running.

Most calls to `runtime.throw` are for internal runtime issues, but some of them are user errors that can't be caught and need to tear down the process (e.g., deadlocks, map races, out of memory). We probably want to distinguish these so the user errors don't include potentially confusing runtime-internal diagnostics.

/cc @mknyszek
Repository: pytorch
Issue: TorchScript custom ops like `cuda` `byte` etc. doesn't support memory_format argument
Labels: oncall: jit,triaged



cc @suo
Repository: pytorch
Issue: TorchScript doesn't support torch.channels_last or any other memory format constants
Labels: oncall: jit,triaged,module: memory format



cc @suo @VitalyFedyunin
Repository: pytorch
Issue: Convert manually bound `cuda` `cpu` `byte` `float` operators to native_functions
Labels: triaged,module: ux

I am a bit skeptical that these should be manually bound. They seem like fairly simple functions that the code generator should be able to understand...

_Originally posted by @ezyang in https://github.com/pytorch/pytorch/pull/27228#discussion_r335551596
Repository: pytorch
Issue: Allow to disable polling for CUDA synchronization
Labels: high priority,module: performance,module: cuda,triaged,enhancement

## 🚀 Feature

When using CUDA, by default, synchronization of the host and GPU works through a tight loop that polls a particular memory location, running a CPU core at 100%. CUDA provides two alternative modes: (1) a tight loop that yields to other threads in between, and (2) synchronization via an interrupt (translated into an event by the driver). PyTorch should provide some way to select either of the three modes.

## Motivation

Burning a CPU core at 100% is not very green. It doesn't save a lot of time either, especially when the GPU has to process large workloads in between synchronizations. And it makes it harder to see how much the CPU is actually utilized.

## Pitch

On the backend, the way to select the synchronization mode is to run either of:
* [`cudaSetDeviceFlags(cudaDeviceScheduleAuto)`](https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1g69e73c7dda3fc05306ae7c811a690fac)
* `cudaSetDeviceFlags(cudaDeviceScheduleSpin)`
* `cudaSetDeviceFlags(cudaDeviceScheduleYield)`
* `cudaSetDeviceFlags(cudaDeviceScheduleBlockingSync)`

This can be done right after the first `cudaSetDevice()` call, but before the device is used (otherwise it's a cudaErrorSetOnActiveProcess error) -- this may be hard to guarantee. However, it can also be done *before* any `cudaSetDevice()` call, in that case it will set the default for any future activated devices.

So I'd suggest to add a function such as `torch.cuda.set_sync_mode()` that takes a string `"auto"`, `"spin"`, `"yield"`, or "`block`" and directly issues the corresponding `cudaSetDeviceFlags()` call. It's up to the user to run this early enough then.

Disclaimer: I haven't looked into what would happen with multiprocessing.

## Alternatives

The main alternative for implementing this would be figuring out where to safely place a `cudaSetDeviceFlags()` call in the device managing code, and have it read some global variables at that time. We could have a `torch.cuda.sync_mode` variable then, or still guard it by a setter function.

It's also possible to solve this in user code doing something like:
```python
import ctypes
ctypes.CDLL('libcudart.so').cudaSetDeviceFlags(4)  # = cudaDeviceScheduleBlockingSync
```

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @anjali411 @ngimel @VitalyFedyunin @mruberry
Repository: rust
Issue: Use structured suggestion for closure needed instead of inner function
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

We currently emit the following error
```
error[E0434]: can't capture dynamic environment in a fn item
  --> $DIR/bad-env-capture3.rs:4:31
   |
LL |         fn bar() { log(debug, x); }
   |                               ^
   |
   = help: use the `|| { ... }` closure form instead
```

It'd be nice if we provided a structured suggestion instead.
Repository: pytorch
Issue: torch native functions cannot be used with inspect.signature
Labels: triaged,module: pybind,module: language binding

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

It would be nice if native functions were annotated with the necessary metadata to allow runtime introspection via the `inspect` module.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

Right now using e.g. `inspect.signature` with a function defined natively produces a `ValueError`:

```
>>> import inspect
>>> import torch
>>> inspect.signature(torch.mm)
*** ValueError: no signature found for builtin <built-in method mm of type object at 0x7ff8961cc940>
```

## Pitch

<!-- A clear and concise description of what you want to happen. -->
It would be nice if the native function generation facilities in the pytorch build could create the function objects with the necessary metadata.

Cython is [able to do this](https://stackoverflow.com/questions/46033277/how-to-introspect-a-function-defined-in-a-cython-c-extension-module), so it's definitely possible:

```
>>> import cython
>>> import inspect
>>> scope = cython.inline("""def f(a,*args,b=False): pass """)
>>> inspect.signature(scope['f'])
<Signature (a, *args, b=False)>
```

Unfortunately I don't know enough about how cython does this or how python builtins can get annotated with the necessary metadata to point to further resources for doing this in pytorch.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

Another way to do this would be for pytorch to make a public API that provides this information, since it's available in `native_functions.yaml` at build time. I think this is less nice since it should be possible to integrate with python's native introspection facilities.
Repository: vscode
Issue: Provision trusted domains for enterprise setup
Labels: feature-request,workbench-link

As referenced in https://github.com/microsoft/vscode/issues/80595#issuecomment-539794968, currently there's no way to pre-configure VS Code with a list of trusted domains. This is a common case in enterprise setup.
Repository: rust
Issue: Quadratic slowdown for lookup of bounds on associated types.
Labels: A-trait-system,I-compiletime,A-associated-items,T-compiler

There are two factors here, which we've spotted combined in the wild:
1. we hoist all `type X: ...;` bounds to the trait-level, i.e.:
    ```rust
    trait Trait {
        type X: A + B;
        type Y: C + D;
    }
    ```
    is sugar for:
    ```rust
    trait Trait
    where
        Self::X: A,
        Self::X: B,
        Self::Y: C,
        Self::Y: D,
    {
        type X;
        type Y;
    }
    ```
    * I doubt we can do much about this, perhaps group/index the bounds?
2. lookup of `<_ as Foo>::X: Bar` in `Foo`'s `where` clauses appears to be quadratic
    * this wouldn't have a noticeable impact without 1.
    * probably easier to fix, I would've assumed it was already linear

<hr/>

And here's our stress test - apologies for the macro, but it takes *a lot* to push it into multiple seconds (the version in the wild had more sophisticated, and actually useful, macros):
```rust
macro_rules! stress {
    (type $name:ident: $($i:expr,)*) => {
        type $name: $(From<[(); $i]> + Into<[(); $i]> +)*;
    };
    (fn $($underscore:tt)*) => {
        const _: () = {
            $({fn _f<T: Trait>() {
                #[derive(Copy, Clone)]
                struct Foo<X>(X);
                let $underscore = Foo(T::X::default()).clone();
            }})*
        };
    };
}

trait Trait {
    type X: Copy + Default;

    // The bounds would normally be on many separate
    // associated types, but that makes no difference.
    stress!(type _Unused:
        00, 01, 02, 03, 04, 05, 06, 07, 08, 09,
        10, 11, 12, 13, 14, 15, 16, 17, 18, 19,

        // Uncomment to (almost) quadruple compile time:
        //20, 21, 22, 23, 24, 25, 26, 27, 28, 29,
        //30, 31, 32, 33, 34, 35, 36, 37, 38, 39,

        // Add more to raise the total time to minutes.
    );
}

stress!(fn
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
);
```

Using `-Zself-profile` and `summarize`, we get this (times are total "self" times):

| Query | 20 (`00`-`19`) | 40 (`00`-`39`) | Slowdown |
|---|---|---|---|
| `type_op_prove_predicate` | 2.52s | 9.17s | 3.64x |
| `typeck_tables_of` | 1.78s | 5.83s | 3.28x |
| `check_item_well_formed` | 1.43s | 4.47s | 3.13x |

cc @rust-lang/wg-traits
Repository: pytorch
Issue: support class annotations in __init__
Labels: oncall: jit,triaged,jit-backlog

```
class MyMod(torch.nn.Module):
    def __init__(self):
        self.foo : List[int] = []
```

should work.

cc @suo
Repository: rust
Issue: Reduce the places where `stable` annotations are needed
Labels: C-enhancement,P-medium,A-stability,T-compiler,F-staged_api

Looking at the definition of `std::option::Option`, we have the following `stable` annotations:

```rust
#[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
    /// No value
    #[stable(feature = "rust1", since = "1.0.0")]
    None,
    /// Some value `T`
    #[stable(feature = "rust1", since = "1.0.0")]
    Some(#[stable(feature = "rust1", since = "1.0.0")] T),
}
```

Is it strictly _necessary_ for the stability checker to look at the fields of enum variants (or of structs, for that matter)?

It seems to me that `MissingStabilityAnnotations` could be modified to allow stability markings to flow down from at least a variant to its fields, as _changing_ them is not a backwards compatible change and shouldn't ever happen. Even extending an existing enum would be backwards incompatible, so I would even flow from ADT attribute downwards. This would let the definition above to be:

```rust
#[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
    /// No value
    None,
    /// Some value `T`
    Some(T),
}
```

This is normally not an issue, but with [the new output in #65421](https://github.com/rust-lang/rust/pull/65421#issuecomment-542869234) we will start showing this code to end users in errors, and it'd be nice if we could eliminate unnecessary boilerplate.
Repository: rust
Issue: [Edition vNext] Consider deprecating weird nesting of items
Labels: T-lang,finished-final-comment-period,disposition-postpone,A-maybe-future-edition

For example, do we really want `mod`s inside random function?  Similarly, IIRC https://youtu.be/LIYkT3p5gTs mentioned that it's unfortunate for incremental that we allow `impl`s of random things inside functions.

Though at the same time, it's nice to allow all sorts of things for how `?eval` bots work on Discord and IRC -- just put all the code inside a block that's passed to `println!` and it just works.
Repository: rust
Issue: Direct users to crate-type=cdylib in crate-type=dylib documentation
Labels: A-frontend,C-enhancement,A-FFI,T-compiler

The dylib crate type is well known to be misleading and rarely useful (to put it politely) among rustc developers, but if a user reads about crate types in `rustc --help`, [the reference](https://doc.rust-lang.org/reference/linkage.html), or [the rustc book](https://doc.rust-lang.org/rustc/command-line-arguments.html#--crate-type-a-list-of-types-of-crates-for-the-compiler-to-emit) they won't get much indication of this. This probably contributes to the constant stream of users picking it or recommending it to each other when they really need `cdylib`. Generally this is only prevented if someone with "insider knowledge" is in the same room when the decision is made, and otherwise only corrected when something breaks and the user seeks help or files a bug report.

I still believe it would be best to deprecate the crate type entirely but since that probably involves more process and pushback, for now I propose to add a note to all the aforementioned documents that says something like:

> As with `lib`, the file produced from a `dylib` crate can only be consumed by the same version of rustc and is not guaranteed to be in any particular format or contain any symbols that other programs could use. If you wish to produce a dynamic library to be loaded dynamically by Rust programs or linked against by other languages, you need to use the `cdylib` crate type.
Repository: flutter
Issue: Fix invalid WeakPtr usage in Shell::Setup()
Labels: engine,P2,team-engine,triaged-engine

Shell::Setup() is called on the platform thread, but we deref the Engine WeakPtr to get the display refresh rate which requires us to deref it on the UI thread.
Repository: flutter
Issue: Fix invalid WeakPtr usage in Shell::CreateShellOnPlatformThread()
Labels: engine,P2,team-engine,triaged-engine

Shell::CreateShellOnPlatformThread() calls into PlatformView::CreateResourceContext which requires us to be on the IO thread (and so it does so in an IO task) and derefs the PlatformView's WeakPtr inside that lambda, which was created on the platform thread.
Repository: flutter
Issue: Remove WeakPtr::getUnsafe()
Labels: engine,P2,team-engine,triaged-engine

getUnsafe() is used as a stopgap measure to allow us to turn on thread safety checks again for most WeakPtr usages.

These are the issues that need fixing to remove getUnsafe():

https://github.com/flutter/flutter/issues/42946
https://github.com/flutter/flutter/issues/42947
https://github.com/flutter/flutter/issues/42948
Repository: pytorch
Issue: ProcessGroupMPI reports incorrect world size
Labels: oncall: distributed,triaged

## 🐛 Bug

## To Reproduce

If you add the test method below to `ProcessGroupGlooTest` in test_c10d.py it fails:

```
def test_new_group(self):                                                   
        print ('WORLD SIZE: {}\n'.format(self.world_size))                      
        store = c10d.FileStore(self.file_name, self.world_size)                 
        c10d.distributed_c10d.init_process_group(                               
            backend='mpi', store=store, world_size=self.world_size, rank=self.rank,
            timeout=timedelta(seconds=1))                                       
        print ('PG WORLD SIZE: {}\n'.format(c10d.distributed_c10d.get_world_size()))
        self.assertEqual(self.world_size, c10d.distributed_c10d.get_world_size())
```

`self.world_size` is 4, but `get_world_size` returns 1.

## Expected behavior

ProcessGroupMPI should return the world_size that we pass into `init_process_group`.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528
Repository: pytorch
Issue: PyTorch RPC should expose critical metrics to the application.
Labels: feature,triaged,module: rpc

## 🚀 Feature

Context for Model Parallel: https://github.com/pytorch/pytorch/issues/23110

## Motivation

When applications are using complex distributed primitives like RPC, RRef and Distributed Autograd, debugging issues can be cumbersome. We should have a way of exposing metrics to applications. This could simply be a `def get_metrics() -> Dict[str, int]` API that returns information about various things. The full list of metrics needs to be decided, although a few examples could be number of owner rrefs, number of user rrefs, RPC latency, Distributed autograd latency etc.

cc @ezyang @gchanan @zou3519 @jerryzh168 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528