sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: integration_test (aka e2e) based performance tests are not preserving the timeline
Labels: a: tests,team,framework,team: benchmark,P2,team-framework,triaged-framework

We're only uploading the timeline summary. To get the summary we need the timeline - we should persist the whole timeline and make sure that gets uploaded to luci for various runs so we can look at regressions more easily.

See e.g. https://ci.chromium.org/ui/p/flutter/builders/prod/Linux_android%20opacity_peephole_opacity_of_grid_perf__e2e_summary/2528/overview - under log links there, there is only a timeline summary, no timeline. This means that someone looking for more details about improvements or regressions needs to run the benchmark locally.
Repository: deno
Issue: `deno coverage` - store source text and emit in output directory?
Labels: suggestion,testing

Right now `deno coverage` loads its source information from the emit cache or sources, but this information could be out of sync with the information in the coverage output directory leading to potential confusion. I think it would be better if we stored a copy of the source w/ emit in the coverage directory?

Related #15260
Repository: flutter
Issue: Compute total GC time wherever we compute new/old GC metrics
Labels: a: tests,framework,team: benchmark,P2,team-framework,triaged-framework

@jonahwilliams says we have this, but at least in the benchmark run I'm looking at I only see the GC counts and not the time. We should make sure that we get the total runtimes.

@a-siva FYI if you have further input

See https://ci.chromium.org/ui/p/flutter/builders/prod/Linux_android%20opacity_peephole_opacity_of_grid_perf__e2e_summary/2528/overview and specifically https://storage.googleapis.com/flutter_logs/flutter/81300293747d258587008c01f3a858275773006c/opacity_peephole_opacity_of_grid_perf__e2e_summary/01de952f-a9fb-4a52-a486-6d465dc5f872/e2e_perf_summary.json which has the GC counts but no times. That is further compounded by that benchmark not producing a full timeline, which is tracked in https://github.com/flutter/flutter/issues/108046
Repository: godot
Issue: CPUParticles and MultiMesh are all drawn in the same transform on Android
Labels: bug,platform:android,topic:rendering,confirmed,topic:thirdparty,topic:3d,topic:particles

### Godot version

3.4, 3.5

### System information

Andriod, Samsung galaxy s22 ultra

### Issue description

CPUParticles (GLES 2) works fine in editor, on Linux / Windows desktop, and most Android phones, but on Samsung galaxy s22 ultra (and probably other phones from that CPU/GPU family), particles seem to be emitted all at the same time at the same position and rotation, so it always looks like one particle is used even if you set the number of particles to tens or hundreds.




### Steps to reproduce

- make a scene with a simple CPUParticles instance using billboard mode
- use GLES2 renderer
- deploy to Samsung galaxy s22 ultra

### Minimal reproduction project

[ParticlesSamsung.zip](https://github.com/godotengine/godot/files/9154257/ParticlesSamsung.zip)
Repository: flutter
Issue: Deprecate `BoxDecoration.shape`
Labels: framework,c: proposal,P2,team-framework,triaged-framework

Discussion here: https://github.com/flutter/flutter/pull/103833

[According to @Hixie](https://github.com/flutter/flutter/pull/103833#issuecomment-1189401812):
> [BoxShape.oval] There is a comment saying new shapes shouldn't go here.

I should probably have included more information in the comment saying why:
Each new enum value is a lot of new code in a bunch of places, including in code we don't control (e.g. app code, that's why the Google tests are failing), so we'd need to write a migration guide and migrate a bunch of code.
- Each new enum value requires new code in a bunch of places.
- That new code likely won't get tree-shaken out, since I don't think the compiler can know which values are never used. So this has a permanent binary size cost even for people who don't use it.
- In principle, we've moved to ShapeBorders rather than BoxShape for new shapes, and the existence of BoxShape is just a legacy feature at this point. Adding more shapes encourages people to use BoxShape in the future.

So I think it is worth trying to remove it. We can't deprecate BoxShape completely because InkWell uses it. But we can remove from BoxDecoration.
Repository: axios
Issue: Allow passing URL objects as alternative to URL strings
Labels: state::in-progress

There should be an option to use URL objects a la Fetch API. Example:

```axios.get(new URL('https://some-domain.com/api/'))```
Repository: go
Issue: spec: Interplay between type conversions and embedded structs is not clear.
Labels: NeedsFix

The go 1.18 spec seems to disagree with the implementation regarding how type conversions and embedded structs interplay. Specifically:

```
type E struct {}

type A struct {
  E
}

type B struct {
  E E
}

func main() {
  _ = A(B{})
}
```
Results in
```
cannot convert B{} (value of type B) to type A
```

However, the spec seems to imply that this should work:

>  A non-constant value x can be converted to type T in any of these cases: [...] x's type and T are not type parameters but have identical underlying types.

The definition of type identity then says
> Two struct types are identical if they have the same sequence of fields, and if corresponding fields have the same names, and identical types, and identical tags.

Finally, the section on struct type says of embedded structs
> The unqualified type name acts as the field name.

So, in the case above, the corresponding fields do have the same names and types, which would imply that they are identical and can be converted. I think the definition of type identity should be updated to clarify that corresponding fields must have different "embedded-ness" as well.
Repository: go
Issue: doc: add a documentation page for reproducible builds
Labels: Documentation,NeedsFix,GoCommand

See https://github.com/golang/go/issues/51812#issuecomment-1164241450 and https://github.com/golang/go/issues/51812#issuecomment-1170245648. There are a number of Go users and developers who think Go supports reproducible builds out of the box, and some others who think Go doesn't fully support reproducible builds. Neither of those is true - they are supported, but only if you do it right.

We should have a documentation page (ideally on the website, like https://github.com/golang/go/issues/42119) to document this. Essentially, we want the docs to cover everything that one needs to consider to make builds reproducible, such as:

* use the `-trimpath` flag
* ensure that the cgo build is reproducible (toolchain, dependencies, etc), or disable cgo
* ensure that the version of Go used is recorded
* ensure that all build parameters (`-tags`, `GOOS`, `GOAMD64`, etc) are recorded

The last two are already covered thanks to build information stamping, I think. See how `go version -m` on a binary built with Go 1.18 or later records practically all Go build parameters.

This umbrella issue aims to track this work, and ensure the documentation page will cover everything that's needed before we write it. Am I missing anything in the list above?

We could also simply go with a GitHub wiki page, but just like https://github.com/golang/go/issues/42119, I am reluctant to go that route as wiki pages can be edited by any user, and this would be fairly important canonical advice where any patches should be carefully reviewed on Gerrit.
Repository: youtube-dl
Issue: Unsupported URL Riggsfilms.vip / Lukespov.vip
Labels: site-support-request,account-needed,nsfw

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.12.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2021.12.17**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://riggsfilms.vip/videos/14-fucking-the-delivery-guy
- https://lukespov.vip/videos/306-fit-kitty-gets-covered-in-cum


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

Hello, i am trying to download videos from Riggsfilms.vip and Lukespov.vip websites (same company and i think same code). I have credentials and access to these videos from browser. But neither using Username/Password options or downloading Cookies file and using --cookies option seems to work. When using directly the URL i get  a SSL: CERTIFICATE_VERIFY_FAILED error. So i tried using --no-check-certificate option also but when i do that i get : 

WARNING: Could not send HEAD request to https://riggsfilms.vip/videos/14-fucking-the-delivery-guy: HTTP Error 404: Not Found
[generic] 14-fucking-the-delivery-guy: Downloading webpage
WARNING: Falling back on generic information extractor.
[generic] 14-fucking-the-delivery-guy: Extracting information
ERROR: Unsupported URL: https://riggsfilms.vip/videos/14-fucking-the-delivery-guy

Can someone help please? Thanks
Repository: vscode
Issue: Adopt argsCanBeInterpretedByShell for external terminals
Labels: debug,debt

From https://github.com/microsoft/vscode/issues/149910 and https://github.com/microsoft/vscode/issues/149910

This is handled in a different way than for the integrated terminal - escaping never happened here...
Repository: vscode
Issue: Remove workaround in launch config arg escaping
Labels: debug,debt

From https://github.com/microsoft/vscode/issues/149910

We decided to not escape args that are simply < and >. Once debug adapters have adopted the new approach, we can remove that workaround.
https://github.com/microsoft/vscode/blob/eaeb3a74ab80384a3cd2c924d73721a290bb0f99/src/vs/workbench/contrib/debug/node/terminals.ts#L116
Repository: electron
Issue: [Bug]: WebXR API not working
Labels: bug :beetle:

### 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 bug report that matches the one I want to file, without success.

### Electron Version

19.0.8

### What operating system are you using?

Windows

### Operating System Version

Windows 11 Pro 22000.795

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Using the WebXR API successfully detects 'immersive-vr' as being supported.

The following is our react-based application running in Chrome version 103.

![image](https://user-images.githubusercontent.com/43181229/180106328-b773998d-0903-4fe7-b129-f8aa2ac80fdc.png)


### Actual Behavior

Using the WebXR API does not detect 'immersive-vr' as being supported.

![image](https://user-images.githubusercontent.com/43181229/180106284-e2f5cda2-87e4-4830-aff6-f42794e935fb.png)


### Testcase Gist URL

_No response_

### Additional Information

I was able to reproduce this behavior using Electron v19.0.8, v20.0.0-beta10, and a custom v21 nightly build with `checkout_openxr` explicitly set to `True`. I have also tried explicitly disabling the sandbox mode for the browser window as shown in the example below...

```
mainWindow = new BrowserWindow({
            backgroundColor: "#000",
            frame: false,
            width: Store.has("win.width") ? Store.get("win.width") : MIN_WIN_WIDTH,
            height: Store.has("win.height") ? Store.get("win.height") : MIN_WIN_HEIGHT,
            x: Store.has("win.x") ? Store.get("win.x") : undefined,
            y: Store.has("win.y") ? Store.get("win.y") : undefined,
            minWidth: MIN_WIN_WIDTH,
            minHeight: MIN_WIN_HEIGHT,
            webPreferences: {
                contextIsolation: false,
                nodeIntegration: false,
                preload: __dirname + "/preload.js",
                sandbox: false
            },
        });
```

Test code for detecting the VR support is as follows...

```
const [vrSupported, setVRSupported] = useState(true);

    useEffect(() => {
        if ("xr" in navigator) {
            //@ts-ignore
            navigator.xr.isSessionSupported('immersive-vr')
                .then((isSupported: boolean) => {
                    setVRSupported(isSupported);
                });
        }
    }, []);
```
Repository: rust
Issue: Rust not specifying Tag_ABI_VFP_args on some objects
Labels: A-linkage,A-codegen,O-Arm,C-bug,A-floating-point,A-ABI

<!--
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’m trying to compile a static lib for armv7 to link with a C project. Targeting cortex r5 with vfp3d16 and armv7r-none-eabihf. But it fails to link with the cproject citing an object from the static lib “has a Tag_ABI_VFP_args attribute “0” that is different than previously seen “1” 

This happens because some of the objects don’t specify it. 248 of the objects do specify 1 and the rest of the 277 don’t specify any (defaults to 0) some of the files include udivmodsi4.o umodsi3.o switch16.o

My question is, is this an issue with the custom linker I am using (should it accept mismatched tags) or should rust be setting these all to 1? Or is it something I am doing wrong. My intuition thinks these objects should specify Tag_ABI_VFP_args = 1 since setting to none aka 0 is a different setting.

### 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.
-->

`rustc --version --verbose`:
```
rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-apple-darwin
release: 1.51.0
LLVM version: 11.0.1
```

</p>
</details>
Repository: rust
Issue: Behavior when write option of std::fs::OpenOptions is false
Labels: A-diagnostics,T-compiler

In std::fs::OpenOptions, the program panics when 
`OpenOptions::new().write(false).truncate(true).`
However, when 
`OpenOptions::new().write(false).append(true)`
, it works the same as 
`write(true).append(true)` 
and does not panic.
How about adapt the spec to one or the other?
Repository: rust
Issue: Weird HRTB behavior with associated types
Labels: A-lifetimes,A-associated-items,T-types,A-higher-ranked

I've trying compile this code.

```rust
// This does not compiles
fn create_baa_in_the_foo1() {
    create_baa(Foo(()));
}

// This compiles
fn create_baa_in_the_foo2() {
    Baa(Foo(()));
}

struct Baa<A>(A);
fn create_baa<A, B>(foo: A) -> Baa<A>
where
    A: for<'a> FooTrait<'a, Output = B>,
{
    Baa(foo)
}

trait FooTrait<'a> {
    type Output;
    fn output(&'a self) -> Self::Output;
}

struct Foo(());
impl<'a> FooTrait<'a> for Foo {
    type Output = &'a ();

    fn output(&'a self) -> Self::Output {
        &self.0
    }
}
```


Everyone knows the lifetime of the `Foo(())` is general enough but it emits error.
```
error: implementation of `FooTrait` is not general enough
  |
2 |     create_baa(Foo(()));
  |     ^^^^^^^^^ implementation of `FooTrait` is not general enough
  |
  = note: `Foo` must implement `FooTrait<'0>`, for any lifetime `'0`...
  = note: ...but it actually implements `FooTrait<'1>`, for some specific lifetime `'1`
```

If we remove `Output = B` and its generic type `B` it works fine.
```rust
struct Baa<A>(A);
fn create_baa<A>(foo: A) -> Baa<A>
where
    A: for<'a> FooTrait<'a>,
{
    Baa(foo)
}
```

or in other way, moving references associate type to method signature. it also works.
```rust
trait FooTrait<'a> {
    type Output;
    fn output(&'a self) -> &'a Self::Output;
}

struct Foo(());
impl<'a> FooTrait<'a> for Foo {
    type Output = ();

    fn output(&'a self) -> &'a Self::Output {
        &self.0
    }
}
```

I guess at least this code should have same lifetime behavior as first one.
Am I doing wrong with something or this is something the bug related to https://github.com/rust-lang/rust/issues/70263?
Repository: angular
Issue: extended diagnostic for non-nullable optional is wrong
Labels: area: compiler,P3,bug,compiler: extended diagnostics

### Which @angular/* package(s) are the source of the bug?

core

### Is this a regression?

No

### Description

Having the case below produces the warning for optional chain operation.
Because of `!` it will always return a boolean to the input.
Relates to the new feature https://github.com/angular/angular/pull/46686 
https://github.com/angular/angular/issues/44870

Also can we have a `angularCompilerOptions` to disable this warnings?

First case:
```ts
optionalArrayElement: {a: 'value'}[] = [];
```
```html
<button [disabled]="!optionalArrayElement[0]?.a"></button>
```

Second case:
```ts
enum MapKeys {
  A,
  B
}

 optionalMapElement: {[key: string]: {a: string}} = {[MapKeys.A] : {a: 'value'}};
```

```html
<button [disabled]="!optionalMapElement[MapKeys.B]?.a"></button>
```

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-r3n3ec?file=src/app/app.component.ts

### Please provide the exception or error you saw

```true
warning NG8107: The left side of this optional chain operation does not include 'null' or 'undefined' in its type, therefore the '?.' operator can be replaced with the '.' operator.
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 14.1.0
Node: 16.15.1
Package Manager: npm 8.13.2
OS: win32 x64

Angular: 14.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router
... service-worker

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1401.0
@angular-devkit/build-angular   14.1.0
@angular-devkit/core            14.1.0
@angular-devkit/schematics      14.1.0
@schematics/angular             14.1.0
rxjs                            7.5.6
typescript                      4.7.4
```


### Anything else?

_No response_
Repository: deno
Issue: lsp: import-map-remap misbehaves with relative map keys
Labels: bug,lsp

After upgrading to v1.24.0, importing from local files (as long as the module is not in the root directory) triggers below warning:

`The import specifier can be remapped to "./some_dir/bar.ts" which will resolve it via the active import map. deno(import-map-remap)`

<img width="783" alt="Screen Shot 2022-07-21 at 2 16 12 PM" src="https://user-images.githubusercontent.com/1096182/180163739-ed22615d-b6f9-4b34-a100-4ce4de14ac55.png">
Repository: tensorflow
Issue: Nondeterministic result on TPU
Labels: stat:awaiting tensorflower,type:bug,comp:tpus,TF 2.9

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Bug

### Source

binary

### Tensorflow Version

2.9

### Custom Code

Yes

### OS Platform and Distribution

Linux Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

TPU v3-8

### Current Behaviour?

```shell
Use "TF_DETERMINISTIC_OPS = 1" or "tf.config.experimental.enable_op_determinism()" can get determistic result on GPU.

But the results are nondetermistic on cloud TPU.
```


### Standalone code to reproduce the issue

```shell
https://github.com/edwardyehuang/CAR

The code on repo above can get determistic result on GPU, but the result is nondetermistic on TPU.
```


### Relevant log output

```shell
TPU 1st RUN (1000 steps):

1000/1000 [==============================] - 506s 395ms/step - loss: 1.6268 - IOU: 0.3178 - g_1_orl: 0.6300 - g_1_sal: 0.0168 - val_loss: 1.3395 - val_IOU: 0.2370

TPU 2nd RUN (1000 steps):

1000/1000 [==============================] - 645s 448ms/step - loss: 1.6488 - IOU: 0.3095 - g_1_orl: 0.6314 - g_1_sal: 0.0162 - val_loss: 1.7416 - val_IOU: 0.1793
```
</details>
Repository: pytorch
Issue: Compatibility with newest MKL
Labels: module: build,triaged,module: mkl

### 🚀 The feature, motivation and pitch

libtorch 1.12.0 is currently released with version 2020.0
please make torch compatible with latest version of MKL as it is much faster. I note that the `cblas_?gemm` functions are about twice as fast on my machine(AMD) for ~1000x1000 matrices

I tried building libtorch with 2022.0.1 version of MKL.
a call to at::matmul yeilds error
`Intel MKL ERROR: Parameter 9 was incorrect on entry to cblas_sgemm_batch.`


### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @seemethere
Repository: godot
Issue: Use the same highlight effect when drag-and-dropping a node, a resource and a file to the FileSystem dock
Labels: bug,topic:editor,usability

### Describe the project you are working on

irrelevant

### Describe the problem or limitation you are having in your project

The highlight in the FileSystem dock for saving a branch as scene and saving a resource in a file is different.
Saving a resource to the disk uses the same highlight system than when moving files around in the FileSystem dock.

The bad system has a notion of a position "between" two files that is unneeded since all these actions take a target directory.

https://user-images.githubusercontent.com/71937306/180129047-09de82ee-c6a7-4d52-95ab-6515598f99a5.mp4


### Describe the feature / enhancement and how it helps to overcome the problem or limitation

Use the same one in all cases for consistency (the actual highlight one).


### Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

/

### If this enhancement will not be used often, can it be worked around with a few lines of script?

its a tiny UX improvement to a feature I use often

### Is there a reason why this should be core and not an add-on in the asset library?

/