sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Test string-view forwarding improvements in MSVC
Labels: Area-Performance,Product-Meta,Issue-Task

VSO-1265022 and VSO-1526191 improve MSVC's code generation when accessing 128-bit types passed by value. After these have been released in Visual Studio we should retest the performance
* in general as we use a lot of string-views throughout the code base
* after reverting ee3259847af233d24b517c9c1c252c815b6e990e as that commit should optimally not be necessary anymore

AMD and especially Intel Atom CPUs should be most affected by these improvements, as both have slower SSE loads than other, higher end Intel CPUs AFAIK.
Repository: vscode
Issue: Markdown preview resets when switching tabs
Labels: bug,help wanted,markdown

<!-- ⚠️⚠️ 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.66.2, 1.67.0-insider
- OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

1. See gif below, or: Open markdown file
2. Show preview
3. Change markdown file
4. Switch to another tab to hide preview
5. Get back to preview

![Code_-_Insiders_i6uW3MTnMI](https://user-images.githubusercontent.com/5781692/164087683-8a46aacb-68b8-4531-aed1-826b231fa49a.gif)
Repository: go
Issue: cmd/go: the .Deps field is used to determine whether test-variant packages have import cycles
Labels: NeedsInvestigation,GoCommand

Currently cmd/go uses the Deps field to determine cycles on test variant packages. This requires us to call collectDeps and examine the entire set of transitive dependencies for each test variant package even if we're not doing a go list command that requires presenting the transitive set of dependencies for each package in the output.

We should probably find another way to determine whether test-variant packages have import cycles.

cc @bcmills
Repository: material-ui
Issue: [Autocomplete] Long text in list item is being cut off
Labels: bug 🐛,component: autocomplete

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Currently when there is long text for the list items, the text extends out of the menu and is cut off. There should be an option for the text to wrap and be fully visible. An alternative would be if the overflow text would display an ellipsis, and hover title could be seen.

This is somewhat possible with the help of [react-window](https://react-window.vercel.app/#/examples/list/variable-size), but then the list is not accessible by keyboard. 

### Examples 🌈

The text should wrap (or `overflow:ellipsis` with a hover title) and be fully accessible by keyboard.

<img width="275" alt="virtualizedAutocomplete-longText" src="https://user-images.githubusercontent.com/16760818/164092815-2ed6c82f-6d13-4e6a-b113-22779040c153.png">


### Motivation 🔦

My UX team and I are developing fully accessible sites and webapps with complex form elements. Some of our autocompletes may contain lists with thousands of items. It's crucial for these components to be as user friendly as possible.
Repository: pytorch
Issue: NVFuser microbenchmark classifier - hash on memory formats
Labels: triaged,module: nvfuser

### 🚀 The feature, motivation and pitch

in https://github.com/pytorch/benchmark/blob/main/torchbenchmark/util/classify_graphs.py, we should consider memory formats (e.g. stride orders) as part of the hash. This will separate fusion groups that have different memory formats.

### Alternatives

_No response_

### Additional context

_No response_
Repository: flutter
Issue: Add external texture partial repaint tests
Labels: a: tests,engine,a: platform-views,customer: google,P2,from: postmortem,team-engine,triaged-engine

Currently an error with partial repaint was caught by https://github.com/flutter/flutter/issues/96188. It's more desirable to have one directly impacting this.
Repository: pytorch
Issue: HIPFFT_EXEC_FAILED when using AMD GPU run FFT
Labels: module: cuda,triaged,module: fft

### 🐛 Describe the bug

When running the following function in my code, it reports an error:

The code is:
```
import torch
import torch.nn as nn
import torch.fft
import torch.cuda

...

def fft_loss(patterson, electron_density):
    patterson = patterson[0,0,:,:,:]
    electron_density = electron_density[0,0,:,:,:]
    f1 = torch.fft.fftn(electron_density)
    f2 = torch.fft.fftn(torch.roll(torch.flip(electron_density, [0, 1, 2]), shifts=(1, 1, 1), dims=(0, 1, 2)))
    f3 = torch.mul(f1,f2)
    #f3 = torch.mul(f1.real,f1.real)
    f4 = torch.fft.ifftn(f3)
    f4 = f4.real

    vx = f4 - torch.mean(f4)
    vy = patterson - torch.mean(patterson)

    cost = (torch.sum(vx * vy) / (torch.sqrt(torch.sum(torch.square(vx)) + epsilon) * torch.sqrt(torch.sum(torch.square(vy)) + epsilon)))
    return cost
```

The patterson and electron_density are all tensors.

The error is:
Traceback (most recent call last):
  File "20220418_draft_seblock_20.py", line 274, in <module>
    loss5 = fft_loss(x, yhat)
  File "20220418_draft_seblock_20.py", line 187, in fft_loss
    f1 = torch.fft.fftn(electron_density)
RuntimeError: cuFFT error: HIPFFT_EXEC_FAILED

I'm doubting the AMD GPU doesn't support some of the FFT module? The same script runs successfully on NVIDIA GPUs.

Best,
Sky

### Versions

PyTorch version: 1.8.0a0+56b43f4
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 4.2.21155-37cb3a34

OS: CentOS Linux 7 (Core) (x86_64)
GCC version: (GCC) 11.2.0
Clang version: 3.4.2 (tags/RELEASE_34/dot2-final)
CMake version: version 2.8.12.2
Libc version: glibc-2.17

Python version: 3.8.9 (default, Jan 26 2022, 00:42:48)  [GCC 7.3.1 20180303 (Red Hat 7.3.1-5)] (64-bit runtime)
Python platform: Linux-3.10.0-1127.19.1.el7.x86_64-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: Vega 20
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 3.27.5
MIOpen runtime version: 2.11.0
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.1
[pip3] torch==1.8.0a0+56b43f4
[pip3] torchvision==0.9.0a0+01dfa8e
[conda] Could not collect

cc @ngimel @mruberry @peterbell10
Repository: flutter
Issue: Consider updating web app template to include a splash screen
Labels: c: new feature,tool,d: api docs,platform-web,P3,team-web,triaged-web

- [ ] Need to get the source image
- [x] Update index.html.tpl in `package:flutter/flutter_tools`
Repository: electron
Issue: [Feature Request]: Use commit time instead of zip epoch for deterministic build archives
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Build files essentially strip file modification times to make build files deterministic. There's no practical issue with this approach, but it is unnecessarily misleading.

### Proposed Solution

The time of the current commit that should be used instead as a better deterministic value.

### Alternatives Considered

The current approach is an alternative. It is alright.

### Additional Information

_No response_
Repository: flutter
Issue: Opacity widget always assumes compositing
Labels: framework,c: performance,P2,team-framework,triaged-framework

Most widgets that modify the rendering of their children, or rather the RenderObject associated with those widgets, have code that detects if the children need compositing. If the children need compositing then they inject themselves into the tree as a layer. If the children do not need compositing then they simply issue rendering commands (usually along with a save() or saveLayer()) to set the rendering modification into the current picture/display list.

See the way that the `pushTransform` method tests compositing and changes the way it applies itself to rendering the tree:
https://github.com/flutter/flutter/blob/b9f1a907b1aa5f13d0443cecb7e9f851b153c11f/packages/flutter/lib/src/rendering/object.dart#L562

OpacityLayer does not have the same tests and always adds a layer, it could simply emit a saveLayer with a Paint object that has the opacity in it if the children don't need compositing.
Repository: rust
Issue: Error typechecking lifetime-GAT bound when "parent" bound is inferred
Labels: A-lifetimes,T-compiler,fixed-by-next-solver,A-GATs

I tried this code:

```rust
#![feature(generic_associated_types)]

use std::fmt::Debug;

trait Classic {
    type Assoc;
}

trait Gat {
    type Assoc<'a>;
}

struct Foo;

impl Classic for Foo {
    type Assoc = ();
}

impl Gat for Foo {
    type Assoc<'i> = ();
}

fn classic_debug<T: Classic>(_: T)
where
    T::Assoc: Debug,
{
}

fn gat_debug<T: Gat>(_: T)
where
    for<'a> T::Assoc<'a>: Debug,
{
}

fn main() {
    classic_debug::<Foo>(Foo); // fine
    classic_debug(Foo); // fine

    gat_debug::<Foo>(Foo); // fine
    gat_debug(Foo); // boom
}
```

I expected to see this happen: It compiles

Instead, this happened: It fails type checking, with:

```
error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): `<_ as Gat>::Assoc<'a>` doesn't implement `Debug`
  [--> src/main.rs:40:5
](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#)   |
40 |     gat_debug(Foo); // boom
   |     ^^^^^^^^^ `<_ as Gat>::Assoc<'a>` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `for<'a> Debug` is not implemented for `<_ as Gat>::Assoc<'a>`
note: required by a bound in `gat_debug`
  [--> src/main.rs:31:27
](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#)   |
29 | fn gat_debug<T: Gat>(_: T)
   |    --------- required by a bound in this
30 | where
31 |     for<'a> T::Assoc<'a>: Debug,
   |                           ^^^^^ required by this bound in `gat_debug`
```

### Meta
[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ba44c85386d3ea3bab20a7ae6e30336)
Repository: rust
Issue: Rustdoc warns about comments in code blocks
Labels: T-rustdoc,A-doctests

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
/// ```rust
/// // Hello!
/// ```
fn main() {}
```

The current output of rustdoc is:

```
$ rustdoc src/main.rs --document-private-items
warning: Rust code block is empty
 --> src/main.rs:1:5
  |
1 |   /// ```rust
  |  _____^
2 | | /// // Hello!
3 | | /// ```
  | |_______^
  |
  = note: `#[warn(rustdoc::invalid_rust_codeblocks)]` on by default

warning: `rustdoc-sample` (bin "rustdoc-sample" doc) generated 1 warning
```

Ideally, the output should not give any warnings.

While a standalone comment in a code block is not a common situation, the resulting webpage will highlight it as a comment. I have a code generator, which creates rust code for build scripts. There is a function to generate a comment, and part of the documentation is the resulting comment. Using ```text would solve the warning, but it would not be highlighted as a comment in the resulting webpage. As far as I can tell, this doesn't seem like an empty code block, and I don't think this lint should trigger over it.

Using stable and switching editions doesn't change the output.

Here is a link to a sample repository: [https://github.com/macmv/rustdoc-empty-code-block-sample](https://github.com/macmv/rustdoc-empty-code-block-sample)
Repository: rust
Issue: ICE in `compiler/rustc_monomorphize/src/collector.rs` when combining `#[marker]` and min_specialization
Labels: I-ICE,T-compiler,C-bug,requires-nightly,F-specialization,F-marker_trait_attr,T-types

<!--
Thank you for finding an Internal Compiler Error! 🧊  If possible, try to provide
a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for
how to create smaller examples.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

-->

### Code

This specialization:

https://github.com/the8472/rust/blob/b1e92bfba5406b63839ced943261d89d287f97dc/library/core/src/iter/loop_desugar.rs#L99-L115

Together with these marker + specialization traits

https://github.com/the8472/rust/blob/b1e92bfba5406b63839ced943261d89d287f97dc/library/core/src/iter/adapters/zip.rs#L271-L293

ICEs the 1st compiler stage while building the 2nd compiler when running `./x.py build src/tools/cargo`

### 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.
-->

building a custom rustc, failing commit: https://github.com/the8472/rust/tree/b1e92bfba5406b63839ced943261d89d287f97dc


### Error output

```
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorGuaranteed(())', compiler/rustc_monomorphize/src/collector.rs:927:84

[...]

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.62.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C debuginfo=2 -C incremental -C target-cpu=native -C symbol-mangling-version=v0 -Z unstable-options -Z macro-backtrace -C link-args=-Wl,-z,origin -C link-args=-Wl,-rpath,$ORIGIN/../lib -Z tls-model=initial-exec -Z unstable-options -C prefer-dynamic -C llvm-args=-import-instr-limit=10 -Z binary-dep-depinfo -Z force-unstable-if-unmarked

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
error: internal compiler error: no errors encountered even though `delay_span_bug` issued

error: internal compiler error: encountered ambiguity selecting `Binder(<std::iter::loop_desugar::ForLoopDesugar<std::iter::Zip<std::vec::IntoIter<rustc_middle::ty::Predicate>, std::vec::IntoIter<rustc_span::Span>>> as std::iter::loop_desugar::DesugarCleanup<(rustc_middle::ty::Predicate, rustc_span::Span)>>, [])` during codegen, presuming due to overflow or prior type error
  |
  = note: delayed at compiler/rustc_trait_selection/src/traits/codegen.rs:50:47

```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
# Backtrace

[gist](https://gist.github.com/the8472/cb52ca4cf0e15a58c63ac7e2373e29cc) since it's too large for an issue
Repository: pytorch
Issue: Eliminate uses of deprecated `FindCUDA.cmake`
Labels: module: build,module: cuda,triaged,better-engineering

`find_package(CUDA)` is the legacy way of using CMake to build CUDA code and was deprecated in CMake 3.10. #62445 transitioned over to `enable_language(CUDA)` which gives first class support for `CUDA` as a language in CMake.  However, `find_package(CUDA)` is still being used to locate the CUDA toolkit libraries. This is potentially dangerous because we have two different mechanisms searching for the CUDA installation, each with their own configuration variables. So, it would be best to stop using `FindCUDA.cmake` entirely.

The modern CMake equivalent for library targets is `find_package(CUDAToolkit)` which requires CMake 3.17, so we can't assume it's present yet. However, it might also be possible to vendor `FindCUDAToolkit.cmake` and use it anyway.

There are also dependencies in `third_party` which still use `find_package(CUDA)`
- [ ] [gloo](https://github.com/facebookincubator/gloo/blob/c22a5cfba94edf8ea4f53a174d38aa0c629d070f/cmake/Cuda.cmake#L133)
- [ ] [tensorpipe](https://github.com/pytorch/tensorpipe/blob/52791a2fd214b2a9dc5759d36725909c1daa7f2e/tensorpipe/CMakeLists.txt#L237)
- [ ] [kineto](https://github.com/pytorch/kineto/blob/b2b48c00c6e5bd8e807e2231adb229db6a1d1c22/libkineto/CMakeLists.txt#L181)

cc @malfet @seemethere @ngimel
Repository: flutter
Issue: Improve performance measurement usability
Labels: a: tests,framework,engine,c: performance,d: devtools,P2,team-engine,triaged-engine

As a developer, I want to run some portion of my app and get information about:

- How many frames were rendered
  - Average/P90/P99 build times
  - Average/P90/P99 raster times
  - Information about the top N worst build/raster frames
- How much time was spent in network or disk IO from dart:io
  - The ability to break this down by what files/hosts were accessed and how long it took
- How much time was spent in platform channels
  - The ability to break this down by channel name/method call
- GC stats:
  - Total UI thread time in GC
  - Total time of other thread(s) in GC
  - How many GCs ran/what types
- Average/P90/P99 memory usage during the run
- Average/P90/P99 CPU usage during the run
- Average/P90/P99 GPU usage during the run

I would like to get this information with _minimal_ impact on actual performance of my application. 

A lot, but not all of this information is available in the timeline today. Some of this information is currently provided on some platforms, whereas on other platforms it is missing or only available via polling that devtools may do.

It would probably be best to start with some of our existing performance benchmarks and see what we can do to get the output to look more like this. We should also evaluate whether we can use timeline/perfetto tracing or not and how much of an impact it is having on performance as part of this bug.

/cc @gaaclarke @iskakaushik - I think this intersects with some of the work you're currently doing.
/cc @jiahaog fyi
/cc @kenzieschmoll @polina-c @jacob314 for devtools input
Repository: rust
Issue: Inferred lifetime bound for generic trait parameter is incorrect
Labels: C-bug,T-types,A-implied-bounds

<!--
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
pub trait Womble<R>
{
    fn is_womble(&self, a: &R) -> bool;
}

struct WrapWomble<'s, R> 
where
    Self: 's
{
    womble: Box<dyn Womble<R> + 's>
}

impl<'s, R> Womble<R> for WrapWomble<'s, R>
{
    fn is_womble(&self, a: &R) -> bool {
        self.womble.is_womble(a)
    }
}

fn stack_wombles<'s, R>(a: Box<dyn Womble<R> + 's>) -> Box<dyn Womble<R> + 's> {
    Box::new(WrapWomble { womble: a })
}
```

I expected to see this happen:

Here, `Womble` is a trait whose dependence on `R`  is only that `R` is an input type to the trait method. The lifetime of R is not related to the lifetime of a Womble object, so for example, I should be able to implement this for references or objects which do not outlive `'s` (imagine for example, I have buiit my `dyn Womble<R>` instances out of outer shared state, and now want to process some Rs from some inner state, like a query response).

In particular, I have already given a valid bound, as I understand it. I have promised that regardless of R, my boxed implementors of Womble will live for lifetime `'s`.  It's not valid to assume for a trait that there is a direct dependence in terms of lifetime on its generic parameters.

Instead, this happened: 

The compiler reports R doesn't live long enough; that `R: 's` is inferred but not stipulated. It's quite straightforward to extend the example code with an instantiatable implementor of Womble, wrap it, and never have stored any Rs at all (or even in principle need to).

At the very least, this seems underspecified. I have read, and re-read the relevant RFCs I could find (2093, 599, 1214, 34, 1156), but I can't find a discussion of how an object with generic parameters has its lifetime inferred.

Removing `Self: 's` does not change the outcome, only the error message, which still wants `R: 's`.

### 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.
-->
Tested with: 
nightly
```
rustc 1.62.0-nightly (4ca19e09d 2022-04-19)
binary: rustc
commit-hash: 4ca19e09d302a4cbde14f9cb1bc109179dc824cd
commit-date: 2022-04-19
host: x86_64-unknown-linux-gnu
release: 1.62.0-nightly
LLVM version: 14.0.1
```

stable
```
rustc 1.60.0 (7737e0b5c 2022-04-04)
binary: rustc
commit-hash: 7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c
commit-date: 2022-04-04
host: x86_64-unknown-linux-gnu
release: 1.60.0
LLVM version: 14.0.0
```
Repository: godot
Issue: "Found invalid node path" error when renaming node to match nodepath field default value
Labels: bug,topic:editor

### Godot version

3.4.4.stable.mono.official

### System information

Windows 10

### Issue description


https://user-images.githubusercontent.com/8841352/164180992-7ea27a8f-b6f9-4868-b1c9-aece46e04076.mp4

See this attached video. The default nodepath value of the script is 'ExitPoint'. When a child node with a different name is renamed to match this name, an error is printed to the console 'Found invalid node path [...]'.

P.S. With this case it occurred to me, that even though the automatic nodepath refactoring is nice and helpful, it also seems like a way to unknowingly mess up setups, because once the internal mechanism catches a renamed node (node path matches) it locks onto the caught node and adjusts to its name changes, even though that may have happened accidentally (temporary rename).
Maybe there should be a message instead of this error that notifies of such an implicit capture.

### Steps to reproduce

Have a script export a nodepath with a default value, create a node and assign it that script. Add a child with a random name. Change that name to match the exported nodepath value and see the error printed in the console.

### Minimal reproduction project

_No response_