sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: pow CUDA tensor raised to CPU scalar tensor result can't backward properly
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

Here is a short snippet to demonstrate how difficult this could be to traceback.
```
>>> a = torch.tensor(1.0, device='cuda')
>>> b = torch.tensor(2.0, device='cuda')
>>> c = torch.tensor(2.0, device='cpu')
>>> a.requires_grad = True
>>> (a**c).backward()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/amai/.conda/envs/th/lib/python3.9/site-packages/torch/_tensor.py", line 363, in backward
    torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)
  File "/home/amai/.conda/envs/th/lib/python3.9/site-packages/torch/autograd/__init__.py", line 173, in backward
    Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
RuntimeError: Expected condition, x and y to be on the same device, but condition is on cpu and x and y are on cuda:0 and cuda:0 respectively
>>> (a**b).backward()
```
When running with anomaly mode, it just points to the PowBackward1 as the issue, but there is no explanation of why.

### Versions

1.11.0, 1.13.0. The other issue is present across different environments and comptuers.

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @gchanan
Repository: pytorch
Issue: FakeTensor: Support torch.tensor([FakeTensor, 0])
Labels: triaged,module: meta tensors

### 🚀 The feature, motivation and pitch

Repro:
```
with enable_torch_dispatch_mode(FakeTensorMode(inner=None)):
    torch.tensor([torch.ones([], dtype=torch.int64), 0],)
```
> NotImplementedError: Could not run 'aten::_local_scalar_dense' with arguments from the 'Meta' backend. This could be because the operator doesn't exist for this backend, or was omitted during the selective/custom build process

`torch.tensor` undergoes a special path that doesn't go through a lot of the typical `__torch_dispatch__`. 



### Alternatives

_No response_

### Additional context

This showed up in the `maml` benchmark with torch dynamo. 

cc @Chillee @ezyang @zou3519 @albanD @samdow
Repository: rust
Issue: HRTBs, implementation is not general enough
Labels: A-lifetimes,C-bug,T-types,A-implied-bounds,A-higher-ranked

<!--
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
fn shortened_first<'b, 'a: 'b>(first: &'a str, second: &'b str, _: &'b &'a ()) -> &'b str {
    first
}

fn call_shortened_first<F>(f: F)
where
    F: for<'a, 'b> FnOnce(&'a str, &'b str, &'b &'a ()) -> &'b str
{
    let a = "a".to_owned();
    let b = "b".to_owned();
    
    let result = f(&a, &b, &&());
    println!("{result}");
}

fn main() {
    call_shortened_first(shortened_first);
}
```

I expected to see this happen: I expected this code to compile

Instead, this happened: 
```
   Compiling playground v0.0.1 (/playground)
error: implementation of `FnOnce` is not general enough
  --> src/main.rs:17:5
   |
17 |     call_shortened_first(shortened_first);
   |     ^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: `fn(&str, &'3 str, &'3 &()) -> &'3 str {shortened_first::<'3, '_>}` must implement `FnOnce<(&'a str, &'1 str, &'1 &'a ())>`, for any two lifetimes `'1` and `'2`...
   = note: ...but it actually implements `FnOnce<(&str, &'3 str, &'3 &())>`, for some specific lifetime `'3`
```

However, If I remove an explicit `'a: 'b` bound the code compiles. 

```rs
fn shortened_first<'b, 'a>(first: &'a str, second: &'b str, _: &'b &'a ()) -> &'b str {
    first
}

fn call_shortened_first<F>(f: F)
where
    F: for<'a, 'b> FnOnce(&'a str, &'b str, &'b &'a ()) -> &'b str
{
    let a = "a".to_owned();
    let b = "b".to_owned();
    
    let result = f(&a, &b, &&());
    println!("{result}");
}

fn main() {
    call_shortened_first(shortened_first);
}
```
### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Reproducible on `1.61-stable`, `1.62.0-beta.5(2022-06-13 1bc802e990a3393731b1)`, `1.63.0-nightly(2022-06-20 5750a6aa2777382bf421)`

I suspect it has something to do with `'a: 'b` makes `'b` early bound, but when `'a: 'b` is implied from `&'b &'a ()` it doesn't make `'b` early bound. The behavior is inconsistent and therefore very confusing.
Repository: rust
Issue: Regression in error reporting on {integer} type ambiguity between 1.61 and 1.62
Labels: A-diagnostics,P-medium,T-compiler,regression-from-stable-to-stable,C-bug

_This is strongly related to #98357._

The presence of a `Mul` impl for both `u8` and `i32` introduces an ambiguity in `main()` where the type of the literal `7` cannot be determined. #98357 goes into why this is an error since it *can* be fixed by assigning a type (`Foo`) to `prod`, but this issue is about a regression in rustc 1.62 which drops information about the ambiguity in the literal integer's type from the error message/notes as compared to 1.61 (which does not).

```
use core::ops::Mul;

#[derive(Debug)]
struct Foo(i32);

impl Mul<Foo> for i32 {
    type Output = Foo;

    fn mul(self, other: Foo) -> Self::Output {
        Foo(self * other.0)
    }
}

impl Mul<Foo> for u8 {
    type Output = Foo;
    
    fn mul(self, other: Foo) -> Self::Output {
        Foo(self as i32 * other.0)
    }
}

fn main() {
    let prod = 7 * Foo(6);
    assert_eq!(prod.0, 42);
}
```

[Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b9ca0cd7e764967b872e9985fdf4de74)

The error message emitted by 1.61 (current stable):

```
error[[E0282]](https://doc.rust-lang.org/stable/error-index.html#E0282): type annotations needed
  --> src/main.rs:24:16
   |
23 |     let prod = 7 * Foo(6);
   |         ---- consider giving `prod` a type
24 |     assert_eq!(prod.0, 42);
   |                ^^^^ cannot infer type
   |
   = note: type must be known at this point

error[[E0283]](https://doc.rust-lang.org/stable/error-index.html#E0283): type annotations needed
  --> src/main.rs:23:18
   |
23 |     let prod = 7 * Foo(6);
   |                  ^ cannot infer type for type `{integer}`
   |
note: multiple `impl`s satisfying `{integer}: Mul<Foo>` found
  --> src/main.rs:6:1
   |
6  | impl Mul<Foo> for i32 {
   | ^^^^^^^^^^^^^^^^^^^^^
...
14 | impl Mul<Foo> for u8 {
   | ^^^^^^^^^^^^^^^^^^^^

Some errors have detailed explanations: E0282, E0283.
For more information about an error, try `rustc --explain E0282`.
```

The error message emitted by 1.62 (2022-06-13 1bc802e990a3393731b1) (the current beta):

```
error[[E0282]](https://doc.rust-lang.org/beta/error-index.html#E0282): type annotations needed
  --> src/main.rs:24:16
   |
23 |     let prod = 7 * Foo(6);
   |         ---- consider giving `prod` a type
24 |     assert_eq!(prod.0, 42);
   |                ^^^^ cannot infer type
   |
   = note: type must be known at this point

For more information about this error, try `rustc --explain E0282`.
```

Notice that while one perhaps valid resolution has been provided, the actual cause of the error is completely obscured.

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged
-->
Repository: rust
Issue: Tracking Issue `--extern` crate modifiers
Labels: C-tracking-issue

This is a tracking issue for command line option syntax currently used by several modifiers affecting behavior of extern crates.
Specific tracking issues for those modifiers:
- https://github.com/rust-lang/rust/issues/98399
- https://github.com/rust-lang/rust/issues/98398
- https://github.com/rust-lang/rust/issues/98400
- https://github.com/rust-lang/rust/issues/111302

The currently used syntax is
```
--extern [MODIFIERS:]NAME[=PATH]
```

Before stabilization it should likely be harmonized with command line syntax already used for native library modifiers, see item (3) in https://github.com/rust-lang/rust/pull/93901#issuecomment-1041325522.
- Modifiers can be converted to `+/-` form
  - `priv` - `+priv` or `-pub`
  - `noprelude` - `-prelude`
  - `nounused` - `+used`
- Position of the `MODIFIERS` component in the option can also be changed.
Repository: pytorch
Issue: Complex support in DDP
Labels: oncall: distributed,triaged,module: ddp

### 🐛 Describe the bug

There are a few issues to support complex tensors in DDP:

1. Currently, passing in complex tensors to DDP does not work because ProcessGroupNCCL doesn't know how to handle the type. @kumpera has a WIP fix in https://github.com/pytorch/pytorch/pull/74039. 
2. Conjugated tensors won't work out of the box as they need to be materialized before calling `view_as_real` for correctness.

As an e2e test, we should verify that training local model with complex inputs and DDP with complex inputs for conjugated /unconjugated complex tensors is equivalent. 

### Versions

main

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @kwen2501
Repository: vscode
Issue: Conflicting File Nesting Patterns
Labels: bug,file-nesting

There seems to be some sort of pattern conflict with the following `explorer.fileNesting.patterns` setting:

This works:
```json
  "*": "${basename}.*"
```

And this works:
```json
  "*": "${basename}*.${extname}"
```

But when putting them together:
```json
  "*": "${basename}.*, ${basename}*.${extname}"
```
...it appears to break _**all**_ of the defined patterns. (ie. no patterns are applied)

<!-- ⚠️⚠️ 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.68.1
- OS Version: MacOS 12.4

Steps to Reproduce:

1. Add the following pattern to the `explorer.fileNesting.patterns` setting:
   - ```json
      "*": "${basename}.*, ${basename}*.${extname}"
      ```
Repository: rust
Issue: Tracking Issue for `Exclusive`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(exclusive_wrapper)]`

This is a tracking issue for the `Exclusive` wrapper struct.

This structure can be used to upgrade non-`Sync` objects into `Sync` ones, by only offering mutable access to the underlying object. This can be useful with `Send`-but-not-`Sync` futures (like `BoxFuture`s)


### Public API

```rust
// core::sync
#[derive(Default)]
struct Exclusive<T: ?Sized> { ... }

impl<T: ?Sized> Sync for Exclusive {}

impl<T> Exclusive<T> {
    pub const fn new(t: T) -> Self;
    pub const fn into_inner(self) -> T;
}

impl<T: ?Sized> Exclusive<T> {
    pub const fn get_mut(&mut self) -> &mut T;
    pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>;
    pub const fn from_mut(&mut T) -> &mut Exclusive<T>;
    pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive<T>>;
}

impl<T: Future> Future for Exclusive { ... }

impl<T> From<T> for Exclusive<T> { ... }
impl<T: ?Sized> Debug for Exclusive { ... }
```


### Steps / History


- [x] Implementation: https://github.com/rust-lang/rust/pull/97629
- [x] Determine other nice-to-have trait impls
  - [x] https://github.com/rust-lang/rust/pull/116241
- [ ] Final comment period (FCP)
- [ ] Stabilization PR


### Unresolved Questions


- None yet.
Repository: flutter
Issue: Send low memory event to DevTools
Labels: framework,d: devtools,perf: memory,P2,team-framework,triaged-framework

DevTools should be able to listen to these events and add messaging to users in the DevTools memory page.

This information is already broadcasted from the Engine to the Framework, and we just need to post this information over a stream that DevTools is subscribing to. 

CC @dnfield @polina-c
Repository: go
Issue: testing: coverprofile can't profile coverage of test cases themselves
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

1.18

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

N/A, but Mac or Linux both.

### What did you do?

Wrote test cases with non-trivial infrastructure and used -coverprofile.

### What did you expect to see?

Coverage information for my test code and test infrastructure.

### What did you see instead?

Coverage information only for the package being tested.

The issue here is that in some cases, tests may reasonably want some non-trivial infrastructure or setup code, which isn't logically relevant to the package *outside* of its unit tests, but which is complex enough that I want to be carefully verifying that code too, not just the overall results of unit tests using it. Being able to confirm/deny that the test code is running as expected, and not skipping things early or happening to hit only happy paths in the test logic, would be useful for diagnosing this.
Repository: flutter
Issue: audit TODOs in Android embedding
Labels: platform-android,engine,P2,c: tech-debt,team-android,triaged-android

The Android embedding has multiple TODOs with no associated issue that are likely obsolete or need issues filed.

We should remove obsolete ones and file issues for the ones missing issues.

/cc @GaryQian @camsim99
Repository: flutter
Issue: Audit logging in the Android embedding
Labels: platform-android,engine,P2,c: tech-debt,team-android,triaged-android

The Android embedding has numerous places where logs are used that are not actionable to end developers. Some of these logs never show up unless specifying a separate logging level for Android (in particular, `Log.v`).

We should audit logging usage in the Android embedding and do the following:

- Remove logs that violate the style guide, which requires that all logs print something actionable by the developer.
- Consider adding trace events for some logs that are good candidates for tracing.
- Rephrase logs that could be actionable where possible.

/cc @GaryQian @camsim99
Repository: flutter
Issue: Drop MockCanvas recording in favor of DlCanvas->DisplayList recording in tests
Labels: engine,P2,team-engine,triaged-engine

See https://github.com/flutter/engine/pull/34233#discussion_r904271894
Repository: godot
Issue: CLI exits for no reason when packing PCK if Hide Console Window is enabled in the editor settings
Labels: platform:windows,topic:porting,documentation,topic:export

### Godot version

3.4.4.stable

### System information

Windows 10, Vulkan, AMD A9 Radeon R5

### Issue description

I'm trying to pack a PCK file from CMD and when I run the command below, Godot pops up, packs the PCK and then kills the whole CMD process.
```
F:\Engine\godot.exe --path F:\Projects\dlcs --export-pack dlc_win64 F:\Projects\dlcs\export\blackmambaaltdlc_dlcdata.pck
```
But in the end, the PCK file does get created once the CMD window gets killed. I'm running this command in a Node.JS script therefore I cannot do anything after the packing part since Godot exists for no reason.

### Steps to reproduce

1. Open CMD
2. Paste this `F:\Engine\godot.exe --path F:\Projects\dlcs --export-pack dlc_win64 F:\Projects\dlcs\export\blackmambadlc_dlcdata.pck`

### Minimal reproduction project

[example.zip](https://github.com/godotengine/godot/files/8962205/example.zip)
Repository: kubernetes
Issue: Rethinking the growSlice function in staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

https://github.com/kubernetes/kubernetes/blob/1d811065345bfe9f3be7f6757a9938c1760180c7/staging/src/k8s.io/apiserver/pkg/storage/etcd3/store.go#L760-L789

> Can you open an issue to capture these two points? (I won't block this PR on them since the bug looks disastrous)
> * I am skeptical that this function is actually an improvement over just letting the go runtime pick the size. I'd like to see benchmarks with it swapped out for just calling append.
> * If we do keep it, this desperately needs to be rewritten to use the new type parameters instead of reflection.

_Originally posted by @lavalamp in https://github.com/kubernetes/kubernetes/pull/110652#discussion_r903954034_

### Why is this needed?

Read https://github.com/kubernetes/kubernetes/pull/110652 for more background information
Repository: pytorch
Issue: Provide error message when thread pool is exhausted in RPC
Labels: high priority,oncall: distributed,triaged,module: rpc

### 🐛 Describe the bug

See issue raised in https://github.com/pytorch/pytorch/issues/80017. We should provide a better error message when we can no longer send requests due to exhaustion of threads in thread pool. Docs: https://pytorch.org/docs/master/rpc.html#torch.distributed.rpc.TensorPipeRpcBackendOptions

### Versions

current

cc @ezyang @gchanan @zou3519 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @kwen2501 @jjlilley @mrzzd @H-Huang
Repository: godot
Issue: Ternary with sibling classes warns of incompatible types
Labels: bug,topic:gdscript

### Godot version

3.4.4

### System information

macOS 10.15.7

### Issue description

Sibling classes extending the same base class report incompatible types when assigning using a ternary. A warning is produced stating the following.
> Values of the ternary conditional are not mutually compatible

The same does not occur for a ternary producing type of superclass or subclass as follows.
```
var _dummy: DummySuper = DummySuper.new() if true else DummySub0.new()
```

### Steps to reproduce

1. Create a superclass.
    ```
    extends Node
    class_name DummySuper
    ```
1. Create two subclasses that each extend the superclass.
    ```
    extends DummySuper
    class_name DummySub0
    ```
    ``` 
    extends DummySuper
    class_name DummySub1
    ```
1. Instatiate a variable of type superclass as one or the other subclass in a ternary.
    ```
    var _dummy: DummySuper = DummySub0.new() if true else DummySub1.new()
    ```

### Minimal reproduction project

[ternary_repro.zip](https://github.com/godotengine/godot/files/8962523/ternary_repro.zip)
Repository: flutter
Issue: Embedder API dylibs should not expose any symbols other than the ones in embedder.h
Labels: engine,e: embedder,P2,customer: going,team-engine,triaged-engine

We already do this for iOS and Android. We used to have a check that queried global symbols that tripped if unexpected symbols were found. We depended on this check for the embedder dylib as well. Some time ago, this post link check was replaced by a linker script that finely controlled the exposed symbols. The linker script was not applied to the embedder API dylibs.

This caused the issue in https://github.com/flutter/flutter/issues/106118. The chronology of events:
* 4 months ago, FreeType was rolled to 2.11.1 in https://github.com/flutter/engine/pull/31678. This roll included a change to the GN rule where the `FT_PUBLIC_FUNCTION_ATTRIBUTE` was unset. The default `FT_PUBLIC_FUNCTION_ATTRIBUTE` implementation unsets symbol visibility which engine builds set to `hidden`. Now FreeType symbols were exposed by the embedder API dylibs (found using `nm --dynamic`).
* `customer: vroom` rolls in the embedder dylib. This embedder also depends on libfreetype2 and there are symbol overrides.
*  The symbol visibility leak is patched in https://flutter-review.googlesource.com/c/third_party/freetype2/+/31480
* The embedder works around the issue using `RTLD_DEEPBIND` in https://github.com/flutter/flutter/issues/106118#issuecomment-1163753246

We should guarantee that no symbols used by the internal dependencies of Flutter leak from the Flutter engine dylib accidentally. we can either do this via a linker script like the Android or iOS embedders or via a post link check (or both).
Repository: pytorch
Issue: Allow a user provided "test name - test time" mapping file work with pytorch's test sharding mechanism
Labels: module: ci,triaged

### 🚀 The feature, motivation and pitch

We're running pytorch unit tests with sharding, but we can only do plain test sharding because "test time-based sharding" is only available from pytorch's past CI data, for example, `get_shard_based_on_S3` needs `test_times_file` from S3.

A plain sharding doesn't always work well because some shards finish in 20 minutes while other shards take longer than 3 hour to finish. This happens more frequently as we're having more primTorch tests and they all occurred in one test file (suite).

### Alternatives

It's ok that pytorch CI collects their own time data. Can we add some mechanism that allows users to collect and export their own test time data? Can I then save this mapping file somewhere and later reuse this data file to get a better sharding?

We currently run our tests with the below command like the pytorch CI does:
```
CI=1 python test/run_test.py -v --save-xml
```
This outputs CI stats to xml files `test/test-reports/python-unittest/` which contain test name - test time mapping. It's nice if we can rework the stats parser `upload_test_stats.py` to dump a mapping file and let the "test sharder" `get_shard_based_on_S3` be able to reuse this file.

(impl details: If I run test in 4 shards and there are 4 mapping files dumped, do we take an extra step to merge them or do we allow the "test sharder" to take 4 sharded mapping files?)

### Additional context

N/A

cc @seemethere @malfet @pytorch/pytorch-dev-infra @mruberry @janeyx99 @suo @ptrblck