sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/tools/gopls: add "if err != nil" snippet completion for net/http's HandlerFunc
Labels: Thinking,gopls,Tools

The net/http HandlerFunc is a very common function that Go developers write: 

```golang
func handler(w http.ResponseWriter, r *http.Request)
```

Since the function doesn't return any errors, most users will have to handle the error in the following way: 

```golang
func handler(w http.ResponseWriter, r *http.Request) {
  results, err := doSomething()
  if err != nil {
    http.Error(w, err.Error(), http.StatusInternalServerError)
    return
  }
  // use results
}
```

This can be quite tedious to write and people (aka me) often forget to add the "return" statement which ends up causing the net/http library to spit out errors about multiple status codes being written to the same response. 

In production applications, Go developers typically structure their http servers in a way that will minimize the amount they have to do the HTTP error handling above. But they most likely still have to do it once per handler, or sometimes they want to prototype a server quickly without having to think about how to nicely structure their code to DRY up the error handling logic.

Therefore, as a continuation of improvements to our snippet completions mentioned in [43310](https://github.com/golang/go/issues/43310), I'd love to add a completion that will simply offer to write the above error handling snippet for you. It should also put placeholders on the error and status code arguments while picking sane defaults such as `err.Error()` and `http.StatusInternalServerError`. 

Since the code structure for snippet completions is already in place, adding this use case should be a minimal change. I've included a CL to show the type of change needed, which can be reviewed/merged if this issue is accepted. 

Thanks!
Repository: pytorch
Issue: Make it easier to accurately reflect storage/view relationships in meta/wrapper tensors
Labels: triaged,module: meta tensors,module: __torch_dispatch__

When writing a wrapper tensor you typically want the wrapper to "look like" the wrapped tensor as much as possible. Some things are obvious and directly accepted like `_make_wrapper_subclass` such as size, dtype, device, layout, requires grad. But there are some things that are not so obvious:

* What storage() returns
* Whether or not the tensor reports as a view()
* What the strides are
* What the storage offset is

It's not so easy to get these to report correctly, since you have to create a whole "phantom" universe of storages at your wrapper level to make everything look right. @bdhirsh had to do some of this in his functionalization pass. Need to make it easier for people in general to do.

cc @albanD
Repository: flutter
Issue: [in_app_purchase] ChangeSubscriptionParam requires GooglePlayPurchaseDetails object that cannot be constructed
Labels: platform-android,p: in_app_purchase,package,c: proposal,P2,team-android,triaged-android

## Use case
Subscriptions that are paused are not included in `InAppPurchaseAndroidPlatformAddition.queryPastPurchases()` response.
If user purchases same subscription but with another duration, they will have two active subscriptions. Info about old subscription could be taken from application backend, but `GooglePlayPurchaseDetails` object, that is required in `ChangeSubscriptionParam`, cannot be constructed inside application code.

## Proposal
Make object that is inside `ChangeSubscriptionParam` to have only `oldSku` and `purchaseToken` that are needed for `BillingClient.launchBillingFlow()`.
Repository: rust
Issue: Redundant `RefUnwindSafe` impls (and other auto trait impls) listed in standard library docs for some primitive types.
Labels: T-rustdoc,A-trait-system,C-bug

E.g. https://doc.rust-lang.org/1.55.0/std/primitive.pointer.html#impl-RefUnwindSafe-2
```rs
impl<T> RefUnwindSafe for *const [T]
where
    T: RefUnwindSafe, 
```
which is actually already a consequence of
```rs
impl<T: ?Sized> RefUnwindSafe for *const T
where
    T: RefUnwindSafe, 
```
and
```rs
impl<T> RefUnwindSafe for [T]
where
    T: RefUnwindSafe, 
```

<hr>

Or https://doc.rust-lang.org/nightly/std/primitive.slice.html#impl-RefUnwindSafe-1
```rs
impl RefUnwindSafe for [u8]
```
which is actually already a consequence of
```rs
impl<T: ?Sized> RefUnwindSafe for *const T
where
    T: RefUnwindSafe, 
```
and
```rs
impl RefUnwindSafe for u8
```
Repository: vscode
Issue: Bracket pair colorization - options for showing
Labels: feature-request,editor-bracket-matching,bracket-pair-colorization

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
I think the bracket pair colorization feature is a great feature, but it's too distracting for me to see it all the time. I would prefer to see it only when the editor caret position is adjacent to a bracket (and while typing), or if I have a bracket selected.

What I'm suggesting would be a combination of the [bracket matching feature](https://code.visualstudio.com/docs/editor/editingevolved#_bracket-matching), which currently only outlines the matching bracket, and then would also color the bracket.
Repository: pytorch
Issue: Improve DDP tutorial
Labels: high priority,triage review,oncall: distributed,module: docs,triaged,better-engineering,module: ddp

## 📚 Documentation

Current [DDP tutorial](https://pytorch.org/tutorials/intermediate/ddp_tutorial.html) covers initializing distributed environment, DDP, checkpointing, and combining with model parallelism. To cover all of the recent features we've added to distributed training, integration with other parts of PyTorch training stack, and more accurately represent production training use cases we could enhance or create a new tutorial that:

1. Showcases how to initialize DDP with PyTorch elastic/torch.distributed.run
2. Demonstrates how to seamlessly scale from single node/laptop to cluster of machines
3. Cover a variety of useful features in DDP, such as support for unused parameter training, gradient compression, static graph, etc
4. Show how to do performance analysis/tuning
5. Show how to do inference in distributed setting and aggregate results as https://github.com/pytorch/pytorch/issues/64905 requests. 
6. Recover from batches that cause OOM/inf/nan grads. 

Overall this will make the DDP tutorial more comprehensive and similar to real-world training use cases.


cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @brianjo @mruberry @gcramer23
Repository: go
Issue: cmd/go,cmd/compile: let cmd/compile choose how much concurrency to use
Labels: ToolSpeed,NeedsInvestigation,compiler/runtime

In reviewing [CL 351049](https://golang.org/cl/351049), my attention was drawn to a complicated function that `cmd/go` uses to decide whether to request `cmd/compile` to use internal concurrency:
https://github.com/golang/go/blob/b1bedc0774d8a3a7ff8778e933ee92e8638e9493/src/cmd/go/internal/work/gc.go#L213-L285

I asked the compiler team about it, and @rsc pointed out a parallel function in `cmd/compile`, which ultimately [terminates the process](https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/compile/internal/base/flag.go#L237-L239) if the flags are not compatible:
https://github.com/golang/go/blob/c7f2f51fed15b410dea5f608420858b401887d0a/src/cmd/compile/internal/base/flag.go#L329-L364

Those two functions implement slightly different logic for when concurrent compilation is allowed, and I expect that they will only tend to drift more over time. Moreover, having the compiler reject values of `-N` greater than 0 when certain flags are in use makes it harder for users to override `cmd/go`s current [hard-coded default](https://github.com/golang/go/blob/b1bedc0774d8a3a7ff8778e933ee92e8638e9493/src/cmd/go/internal/work/gc.go#L262-L263) for the concurrency limit (which may be a factor in #17751).

The extra complexity in `cmd/go` also leads to subtle bugs like #48490.

It's obviously reasonable for the compiler to use internal synchronization to avoid races and to produce deterministic output, and at the limit “dropping the concurrency to 1” is equivalent to “using internal synchronization”. So, I think:

* `cmd/go` should avoid setting the `-c` flag explicitly at all, and instead let `cmd/compile` choose its own reasonable defaults.

* If `cmd/compile` detects that other `gcflags` are incompatible with concurrent compilation, it should drop to sequential compilation on its own. (That is, the `-c` flag should specify an upper limit, not an exact one.) That way, users can set `GOFLAGS=-gcflags=-c=N` and not worry about what other flags they might end up needing to pass.

* Ideally `cmd/compile` should choose defaults based on `GOMAXPROCS` rather than a hard-coded constant, since not all packages have uniform shape (especially machine-generated API bindings!) and not all users' workstations have the same number of hardware threads.

CC @josharian @randall77 @mvdan
Repository: flutter
Issue: Cannot use Chrome debug extension with flutter CLI
Labels: tool,platform-web,P2,team-web,triaged-web

Originally reported in https://github.com/dart-lang/webdev/issues/1410

Flutter tools does not pass a devtools launcher to dwds, so clicking dart debug extension in chrome does not open devtools.

command: `flutter run -d web-driver --debug`
Repository: rust
Issue: Clean up handling of `SelectionContext` 'intercrate' mode
Labels: A-trait-system,T-compiler,T-types

The struct `SelectionContext` has an `intercrate` field. This field is only enabled during coherence checking, when we want to see if two impls overlap.

Unfortunately, this flag ends up 'infecting' a large amount of the trait selection / projection logic. In particular, `InferCtxt` is not aware of this flag, so we can end up caching a particular result (candidate, evaluation, or projection) in intercrate mode, and then using the cached result in non-intercrate mode.

The need for this flag may go away once we fully transition to Chalk. However, it might be worthwhile to investigate if it's possible to move (some of) the necessary logic out of `SelectionContext`, and into coherence checking. If we could make intercrate mode just record additional information (instead of actually altering the results of trait selection), we could safely re-use the same `InferCtxt` caches across different `SelectionContext`s.
Repository: pytorch
Issue: Exception thrown in final autograd callback (queue_callback) not caught if not on CPU thread: terminate called after throwing an instance of 'python_error'
Labels: module: crash,module: bootcamp,module: autograd,triaged

Steps to reproduce:

```
import torch
from torch.autograd import Variable
from torch.autograd.function import once_differentiable

def cb():
    raise RuntimeError("blah")

class MyFunc(torch.autograd.Function):
    @staticmethod
    def forward(ctx, input):
        return input

    @staticmethod
    @once_differentiable
    def backward(ctx, grad):
        Variable._execution_engine.queue_callback(cb)
        return grad

a = torch.rand((3, 3), device='cuda', requires_grad=True)
b = MyFunc.apply(a)
b.sum().backward()
```

device='cuda' is important; if you run this on CPU device the exception gets caught.

Backtrace looks like this:

```
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7c58859 in __GI_abort () at abort.c:79
#2  0x00007fffd7f59951 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fffd7f6547c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fffd7f654e7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007fffd7f65799 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007fffcb96501f in std::_Function_handler<void (), THPEngine_queue_callback(_object*, _object*)::{lambda()#2}>::_M_invoke(std::_Any_data const&) [clone .cold] ()
   from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_python.so
#7  0x00007fffc4711778 in torch::autograd::GraphTask::exec_post_processing() ()
   from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_cpu.so
#8  0x00007fffc471319f in torch::autograd::GraphTask::mark_as_completed_and_run_post_processing() ()
   from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_cpu.so
#9  0x00007fffc47179e2 in torch::autograd::Engine::thread_main(std::shared_ptr<torch::autograd::GraphTask> const&) () from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_cpu.so
#10 0x00007fffc470f20f in torch::autograd::Engine::thread_init(int, std::shared_ptr<torch::autograd::ReadyQueue> const&, bool) () from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_cpu.so
#11 0x00007fffcbe5f1c0 in torch::autograd::python::PythonEngine::thread_init(int, std::shared_ptr<torch::autograd::ReadyQueue> const&, bool) () from /raid/ezyang/pytorch-tmp/torch/lib/libtorch_python.so
#12 0x00007fffd7f91d84 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#13 0x00007ffff7e2e609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#14 0x00007ffff7d55293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```

Crashing here is very unpleasant as TORCH_SHOW_CPP_STACKTRACES doesn't work so you have to attach with gdb to diagnose.

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @albanD @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: terminal
Issue: We should expose the actual line from the settings that caused a warning
Labels: Help Wanted,Area-Settings,Product-Terminal,Issue-Task

From #11225 originally. 

> It would be helpful if the error message showed either the actions or the keybindings causing the error. Otherwise the user has to guess.

We do this already for some types of serialization error, but not all. Maybe we could expose the action name? Or the line that the action is on, to at least point them in the right direction.
Repository: terminal
Issue: We need to do something about these feature tests
Labels: Area-Build,Product-Meta,Issue-Task

Seriously. I'd reckon that 50% of our CI runs fail due to this. Dunno what happened to make these flakier. EIM seems like a good time to address this.

Previous notes:
* #11858
* #8534
* #15106

We're definitely correctly waiting on the conhost / openconsole process to start. It's just that some percent of the time, it still just fails to re-open the stdout handle and attach to that console. Crazy.
Repository: pytorch
Issue: Make python_error use c10/util/Exception.h C++ backtrace machinery
Labels: module: error checking,triaged,better-engineering

python_error directly inherits from std::exception and isn't thrown via macro, which means that we cannot easily give the same affordances we give for C++ exceptions, e.g., working with `TORCH_SHOW_CPP_STACKTRACES`. It would be nice if it used the same machinery that `TORCH_CHECK` uses so we can give accurate C++ backtraces.
Repository: pytorch
Issue: [LTC] Setup a subset of TorchBench for the current implementation
Labels: triaged,module: lazy

This is the umbrella to keep track of the status of setting up a subset of TorchBench for the current implementation. For more detailed information, please refer to [this document](https://fb.quip.com/po1cA6te8aXd).

Objectives of this task includes:
- [x] Setup a testbed for prototyping. (AWS GPU Cluster)
- [x] Setup on-demand PR CI for the actual low-noise A/B testing. (#64863, [\#456](https://github.com/pytorch/benchmark/pull/456))
- [x] Collect a subset. ([Initial Benchmark for LTC](https://fb.quip.com/NlWtArfNIb0k))
- [x] Run the subset with CPU lazy device and figure out some numbers. (#64863)
- [x] Run the subset with CPU lazy device and figure out missing operators.
- [ ] [Optional] Enhance TorchBench with LTC metrics.

CC @wconstab.
Repository: go
Issue: cmd/compile: inline-able function with named results performs worse
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

```Go
package functions

import "testing"

const N = 1<<12
var buf = make([]byte, N)
var r [128][N]byte

func Benchmark_SliceToArray_Named(b *testing.B) {
	for i := 0; i < b.N; i++ {
		r[i&127] = SliceToArray_Named(buf)
	}
}

func Benchmark_SliceToArray_Unnamed(b *testing.B) {
	for i := 0; i < b.N; i++ {
		r[i&127] = SliceToArray_Unnamed(buf)
	}
}

func SliceToArray_Named(b []byte) (ret [N]byte) {
	ret = *(*[N]byte)(b)
	return
}

func SliceToArray_Unnamed(b []byte) [N]byte {
	return *(*[N]byte)(b)
}
```

### What did you expect to see?

No performance difference

### What did you see instead?

The named reult version is slower than the anonymous result version.

```
Benchmark_SliceToArray_Named-4     	 2983450	       397.7 ns/op
Benchmark_SliceToArray_Unnamed-4   	 4106510	       293.0 ns/op
```

It looks this is related to code inlining.
Repository: rust
Issue: Compiler error for improper syntax on trait-bounding lacks proper direction
Labels: A-diagnostics,T-compiler,C-bug,D-confusing

<!--
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.
-->

I tried this code:

```rust
impl<T> Add<Into<T>> for Sequence {
    type Output = Self;
    fn add(self, rhs: T) -> Self::Output {
      todo!();
    }
}
```

I expected to see this happen:

> Error: Did you mean to implement `Add` over all things that implement `Into<T>`, if so try this `impl<T: Into<u64>> Add<T> for Sequence {`

Instead, this happened: I wrote up what actually happened in a question on StackOverflow, it tells you both the input I got and how I reacted to it: https://stackoverflow.com/q/69264060/124486

### Meta
`rustc --version --verbose`:
```
rustc 1.57.0-nightly (c3c0f80d6 2021-09-14)
binary: rustc
commit-hash: c3c0f80d6081092faff801542dd82f0e2420152b
commit-date: 2021-09-14
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0
```
Repository: pytorch
Issue: torch.sparse.sum result has wrong dtype when reducing over all dimensions
Labels: high priority,module: sparse,triaged,needs design,module: correctness (silent)

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

As in the title.

## To Reproduce

```python
>>> import torch
>>> t = torch.sparse_coo_tensor([[0, 1], [1, 0]], [1, 2], dtype=torch.int16)
>>> torch.sparse.sum(t).dtype
torch.int64
```

## Expected behavior

According to https://pytorch.org/docs/master/generated/torch.sparse.sum.html#torch.sparse.sum, the default dtype of result is the dtype of input:
```python
>>> torch.sparse.sum(t).dtype
torch.int16
```

## Environment

 - PyTorch Version (e.g., 1.0): 1.10.0a0

## Additional context

When `dim` argument is specified, the result dtype is correct:
```python
>>> torch.sparse.sum(t, dim=0).dtype
torch.int16
```
but
```python
>>> torch.sparse.sum(t, dim=(0, 1)).dtype
torch.int64
```
is still incorrect.

Moreover, the explicit usage of dtype argument is sometimes ignored:
```
>> torch.sparse.sum(t, dim=(0, 1), dtype=t.dtype).dtype   # expecting torch.int16
torch.int64
>>> torch.sparse.sum(t, dtype=t.dtype).dtype
torch.int16
```

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @nikitaved @pearu @cpuhrsch @IvanYashchuk
Repository: godot
Issue: [GodotPhysics] VehicleBody3D (RigidBody) collision with static mesh cases sub zero framerate
Labels: bug,confirmed,topic:physics,topic:3d,performance

### Godot version

4.0 dev

### System information

Windows 10, Vulkan, RTX2060(Mobile), 471.41
Edit - Commit hash: 2d1699ef82a29ef65d810194ee76dddc0d9e0389

### Issue description

Collision of VehicleBody3D (Single Simple Convex Shape) and static body (Capsule Trimesh) causes frame rate to essentially go to zero.

### Steps to reproduce

Simple scene with ground cube + trimesh and capsule mesh + trimesh collisions.
Collide VehicleBody3D collision mesh with static capsule trimesh.

### Minimal reproduction project

[collision_bug.zip](https://github.com/godotengine/godot/files/7201825/collision_bug.zip)
Repository: TypeScript
Issue: Enable `declarationMap` for the `typescript` project itself
Labels: Suggestion,Needs More Info

# Suggestion

## 🔍 Search Terms

source maps, enable, sourcemaps, declarationmap

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

It would be quite nice if `typescript` would be shipped with declaration maps. This could help with debugging TS itself.

## 📃 Motivating Example

Debugging with https://replay.io/ . 

## 💻 Use Cases

I'm currently debugging the inference algorithm to understand it better. However, TS uses a lot of bitmasks, and reading the final code output is not as informative as it could be. TS source code also contains a lot of useful comments that could help during the debugging sessions.