sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Code coverage and profiling don't work on non-X86_64 -musl targets because `profiler_builtins` isn't provided for them
Labels: T-compiler,O-musl,A-code-coverage

* https://github.com/rust-lang/rust/pull/70054 added `profiler_builtins` for all Android targets
* https://github.com/rust-lang/rust/issues/57257 added support for the profiler builtins for x86_64-unknown-linux-gnu targets.
* https://github.com/rust-lang/rust/pull/60476 added the profiler builtins for aarch64-unknown-linux-gnu.

This indicates to me that it should be practical to enable the profiler feature for `-musl` targets on ARM and Intel targets, and we should do so. At a minimum, the following very common targets should have the profiler feature enabled:

- [x] x86_64-unknown-linux-musl; done in https://github.com/rust-lang/rust/issues/57257
- [x] aarch64-unknown-linux-musl; done in https://github.com/rust-lang/rust/pull/111575
- [ ] arm-unknown-linux-musleabihf
- [ ] armv7-unknown-linux-musleabihf
- [ ] i686-unknown-linux-musl
Repository: flutter
Issue: Customizable project structure (platforms)
Labels: c: new feature,tool,customer: crowd,c: proposal,P3,team-tool,triaged-tool

## Use case

Flutter supports multiple platforms, currently 6 (ios, android, windows, linux, macos, web).
 
A project with all platforms enabled feels unorganized to me. The platform folders are placed "randomly" between project-related folders. In many cases they contain no to minimal code. Thus I don't think they are important enough to be placed top-level. 

I'd prefer when all platform-specific sub-projects would be combined into a single `platforms` folder.

<table>
<tr>
<td>
Before top-level view
</td>
<td>
Proposed
</td>
<td>
Proposed top-level view
</td>
<tr>
<td>

```
flutter_project
├── .github
├── .vscode
├── android
├── assets
├── docs
├── example
├── ios
├── lib
├── linux
├── macos
├── test
├── driver_test
├── web
├── windows
├── pubspec.yaml
├── pubspec.lock
│
```
</td>
<td>

```
flutter_project
├── .github
├── .vscode
├── assets
├── docs
├── example
├── lib
├── platforms
│   ├── android
│   ├── linux
│   ├── macos
│   ├── web
│   ├── windows
│   ├── macos
├── test
├── test_driver
├── pubspec.yaml
├── pubspec.lock
```
</td>
<td>

```
flutter_project
├── .github
├── .vscode
├── assets
├── docs
├── example
├── lib
├── platforms
├── test
├── test_driver
├── pubspec.yaml
├── pubspec.lock






```
</td>
</table>


## Custom platform paths

Instead of forcing all existing and future project to migrate to the new structure, it has to be opt-in either hardcoded or customizable

### Hardcoded

When the Flutter team decides that a `platforms` directory is a brilliant idea and adopted as an alternative project layout it could be hardcoded in the `flutter_tool` supporting the old and new layout.

### Customizable

One doesn't fit all. Allowing customizations would allow everyone to place platform folders where it makes sense in their repository. It could be especially for mono repos with very different structures.

Similar to assets, the `pubspec.yaml` could contain a section to platform folders.

```yaml
flutter:
  platforms:
    android:
      - platforms/android
    ios:
      - ../../some-ios-project
```
Repository: pytorch
Issue: test_fs_pool fails
Labels: needs reproduction,module: multiprocessing,module: tests,triaged

## 🐛 Bug

When running the test on x86 I get the following failure:

```
FAIL: test_fs_pool (__main__.TestMultiprocessing)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_multiprocessing.py", line 350, in test_fs_pool
    self._test_pool(repeat=TEST_REPEATS)
  File "test_multiprocessing.py", line 322, in _test_pool
    do_test()
  File "test_multiprocessing.py", line 205, in __exit__
    self.test_case.assertFalse(self.has_shm_files())
AssertionError: True is not false
```

## To Reproduce

Steps to reproduce the behavior:

1.`PYTORCH_BUILD_VERSION=1.7.0 PYTORCH_BUILD_NUMBER=1 MAX_JOBS=12 BLAS=Eigen USE_FFMPEG=1 BUILD_CUSTOM_PROTOBUF=0 USE_IBVERBS=1 USE_CUDA=1 TORCH_CUDA_ARCH_LIST="3.7;6.1;7.0" USE_METAL=0   /sw/installed/Python/3.7.4-GCCcore-8.3.0/bin/python setup.py build` / install
1. `cd test && python run_test.py --verbose`

## Environment

```
PyTorch version: 1.7.0
CUDA used to build PyTorch: 10.1.243

OS: CentOS Linux release 7.7.1908 (Core)
GCC version: (GCC) 8.3.0
CMake version: version 3.15.3

Python version: 3.7
Is CUDA available: yes
CUDA runtime version: 10.1.243
GPU models and configuration: 
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti
GPU 2: GeForce GTX 1080 Ti

Nvidia driver version: 450.36.06
cuDNN version: 7.6.4.38

Versions of relevant libraries:
[pip3] numpy==1.17.3
```

cc @mruberry @VitalyFedyunin @walterddr
Repository: go
Issue: math/big: Float.String inconsistent with format %v
Labels: NeedsInvestigation

go version devel +926994fd7c Thu Nov 26 21:10:09 2020 +0000 linux/amd64

I was surprised today when I discovered that `big.Float.String` truncates to 10 decimal digits of precision, which is surely not a very useful default for a "big" float. I would expect the result to use as many digits of precision as necessary, as if it was using `Float.Text('g', -1)`.

Another remark: most types that implement `fmt.Stringer` work with the `%s` verb. Perhaps `big.Float` could do that too, making `%s` equivalent to `%v`.

The [following code](https://play.golang.org/p/rC58R41NImT) prints three different things. I'd expect it to print the same thing three times:

```
x := big.NewFloat(4.2949672961e+09)

fmt.Printf("%v\n", x)
fmt.Printf("%s\n", x.String())
fmt.Printf("%s\n", x)
```
Repository: pytorch
Issue: torch.save() fails when attempting to save to mounted drives
Labels: needs reproduction,module: serialization,triaged

## 🐛 Bug

I get a error of type _OSError: [Errno 5] Input/output error_ using torch.save. This error is not happening systematically but only roughly 1 out of 10 times so it is difficult to reproduce it. Below you can find the error message.

```
    torch.save(net.state_dict(), os.path.join(save_dir, 'params.pth'))
  File "/anaconda/envs/bone_mets/lib/python3.7/site-packages/torch/serialization.py", line 328, in save
    _legacy_save(obj, opened_file, pickle_module, pickle_protocol)
  File "/anaconda/envs/bone_mets/lib/python3.7/site-packages/torch/serialization.py", line 196, in __exit__
    self.file_like.close()
OSError: [Errno 5] Input/output error
```

## Environment
PyTorch version: 1.4.0
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.15.5

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: Tesla V100-PCIE-16GB
Nvidia driver version: 455.32.00
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.2
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               10.1.243             h6bb024c_0
[conda] mkl                       2020.2                      256
[conda] mkl-service               2.3.0            py37he904b0f_0
[conda] mkl_fft                   1.2.0            py37h23d657b_0
[conda] mkl_random                1.1.1            py37h0573a6f_0
[conda] numpy                     1.19.2           py37h54aff64_0
[conda] numpy-base                1.19.2           py37hfa32c7d_0
[conda] pytorch                   1.4.0           py3.7_cuda10.1.243_cudnn7.6.3_0    pytorch
[conda] torchvision               0.5.0                py37_cu101    pytorch

cc @mruberry
Repository: ant-design
Issue: Sticky table header scrolls one pixel because of disappearing border
Labels: help wanted,Inactive,good first issue

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/fixed-header-and-scroll-bar-with-the-page-antd486-forked-sx7i9?file=/index.js)

### Steps to reproduce
Have bordered table with sticky headed and the table with margin around it. When scrolling, the top border disappears and the header moves up 1px

### What is expected?
The header stays at the same place with a border

### What is actually happening?
The border is gone and the header moves

| Environment | Info |
|---|---|
| antd | 4.8.6 |
| React | 16.13.1 |
| System | Mac 10.15 |
| Browser | Chrome 86.0.4240.198 |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: ResourceLoader returns Exists(path) -> true for non-existent assets (renamed)
Labels: bug,topic:core,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3.stable.mono.official

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Win10

**Issue description:**
<!-- What happened, and what was expected. -->
I tried to create a plugin-workaround for the case where renamed scripts were not recognized as missing, so resources just plainly lost their values. But now i think that's due to another bug that occured with the attempted workaround:
ResourceLoader.Exists(path) returns true even though the asset at path doesn't exist anymore (was renamed in this case).
My assumption is that this may be due to some internal caching. Unfortunately ResourceLoader doesn't seem to expose a way to clear or refresh or re-validate that cache.
If that's the cause, ideally godot would expose a setting to - or just automatically- refresh assets (as unity has/does) and/or those caches.

**Steps to reproduce:**
Create a script (c# here) inheriting from resource. Create a new resource, add the script to it, rename the script file from outside godot (IDE here), switch back to godot, inspect the resource and see it not complaining about the missing script (not invoking the fix-dependencies dialog), which is likely a symptom of the misbehaviour/bug of the ResourceLoader.
(This dialog get's shown when godot is restarted and resources are inspected again, but at that point they already lost their values (very bad!), which makes this a real showstopper bug)

OR
open the attached project, and rename the CustomResource.cs file outside of godot, then use the 'Test'Addon' view option at the top, click load once and Debug once, then inspect the Output panel.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[ResourceBug.zip](https://github.com/godotengine/godot/files/5616727/ResourceBug.zip)
Repository: pytorch
Issue: [feature request] Give `torch.cholesky` an optional fallback to test whether the tensor is positive definite
Labels: triaged,module: linear algebra

Cholesky decomposition only works for positive definite matrices (AFAIK extensions of the Cholesky algorithms for positive semi-definite do exist also). Ironically, a very fast way to test whether a matrix is positive definite is to try a Cholesky decomposition. This is actual much more efficient than the more naive approach of checking the sign of all eigenvalues. Unfortunately, catching the `RuntimeError` (`cholesky_cpu: U(x,x) is zero, singular U.`) is forbidden in TorchScript (?) and so one has to fallback to calling `torch.symeig` (if the matrix is at least symmetric).
I guess that at least for the CPU implementation catching the exception should be possible and so I was wondering whether you could extend `torch.cholesky` with a fallback value which is returned when the matrix is not positive definite. If the error handling on the GPU is not possible the algorithm could still do the `torch.all(torch.symeig(x, eigenvectors=False)[0] > 0.)` shenanigan ...
Alternatively, you could also make this a new function such as `try_choleksy` or `cholesky_or` to stress the possibility of an expensive call.

cc @vishwakftw @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr
Repository: node
Issue: [Buffer] Buffer.from( ArrayBuffer ) showing stale data on subsequent executions
Labels: question,buffer


* **Version**: 14.15.1
* **Platform**: 5.4.0-45-generic #49-Ubuntu SMP Wed Aug 26 13:38:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
* **Subsystem**: Buffer

### What steps will reproduce the bug?

I'm getting the data from the stream as a Buffer 24 bytes long, which contains different data each time called. In the callback I'm trying to split the buffer into two, and log the two new buffers:

```js
    // data is an instance of Buffer, 24 bytes long, and changing each time called (which is dozens of times per second)
    console.log('data1:', data);
    const timestamp = Buffer.from(data.buffer, 0, 16);
    const eventType = Buffer.from(data.buffer, 16, 24);
    console.log('data2:', timestamp, eventType);  // <- showing stale data
```


What is going on?

Even though my first console.log shows the correct data, the second console.log is showing the stale data for the next events (calls), and only after 12 seconds it updates, and then the next 12 seconds it shows the stale data again, and so on.

### How often does it reproduce? Is there a required condition?

Always.

### What is the expected behavior?

The second console.log should show the same underlying data as the first console.log

### What do you see instead?

I see the stale data

```
data1:  <Buffer 4c 0f c5 5f 00 00 00 00 96 12 00 00 00 00 00 00 02 00 00 00 ff ff ff ff>
data2: <Buffer 4c 0f c5 5f 00 00 00 00 96 12 00 00 00 00 00 00> <Buffer  02 00 00 00 ff ff ff ff> 

data1:  <Buffer 4d 0f c5 5f 00 00 00 00 96 12 00 00 00 00 00 00 02 00 00 00 ff ff ff ff>
data2: <Buffer 4c 0f c5 5f 00 00 00 00 96 12 00 00 00 00 00 00> <Buffer  02 00 00 00 ff ff ff ff> 
```

Note that in the second pair of outputs data1 changed the first byte, but data2 remained stale.

### Additional information

<!--
Tell us anything else you think we should know.
-->
Repository: storybook
Issue: Storybook doesn't update my SVG files
Labels: bug,core

**Describe the bug**

Once I start my Storybook with a story that has an SVG file in it, when I update that file, Storybook doesn't show the updated version, even when I kill the process and start Storybook once again.

It seems that this bug is connected with cache because when I change the name of the file it works then just fine.
I also tried to run `start-storybook --no-manager-cache` but it didn't help.

**To Reproduce**
1. Create a React component that imports an SVG file. I use [babel-plugin-inline-react-svg](https://github.com/airbnb/babel-plugin-inline-react-svg) to enable that
2. Create a story of that component
3. Start storybook
4. Provide some changes to the SVG file
5. Storybook doesn't show that changes even when you restart it

**Expected behavior**

Storybook reloads itself and shows the updated version of the SVG file

**Code snippets**

Test.jsx
```jsx
import React from "react";
import TestSVG from "./test.svg";

function Test() {
  return <TestSVG />;
}

export default Test;
```

Test.story.jsx
```jsx
import React from "react";
import Test from "./Test";

export default {
  title: "Test",
  component: Test,
};

export const Default = args => <Test {...args} />;
```

**System**
```
Environment Info:
  System:
    OS: macOS 11.0.1
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
  Binaries:
    Node: 14.7.0 - ~/.nvm/versions/node/v14.7.0/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v14.7.0/bin/yarn
    npm: 6.14.7 - ~/.nvm/versions/node/v14.7.0/bin/npm
  Browsers:
    Chrome: 87.0.4280.67
    Firefox: 82.0.2
    Safari: 14.0.1
  npmPackages:
    @storybook/addon-a11y: ^6.1.9 => 6.1.9 
    @storybook/addon-essentials: ^6.1.9 => 6.1.9 
    @storybook/react: ^6.1.9 => 6.1.9 
```
Repository: flutter
Issue: showModalBottomSheet does not move along with keyboard
Labels: framework,f: material design,has reproducible steps,found in release: 3.3,found in release: 3.7,team-design,triaged-design

Here is my simple flutter application with showModalBottomSheet, it contains a textfield and a button. When the text field is pressed keyboard pops up. But, modalbottomsheet does not move up along with the keyboard. Tried adding bottom viewInsets padding. Is there any other way to move modalbottomsheet along with the keyboard?
```dart
import 'package:flutter/material.dart';

`void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        resizeToAvoidBottomInset: false,
        body: HomeScreen(),
      ),
    );
  }
}

class HomeScreen extends StatelessWidget {
  const HomeScreen({
    Key key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.yellow[200],
      child: Center(
        child: RaisedButton(
          color: Colors.purple[100],
          child: Text('Button'),
          onPressed: () {
            showModalBottomSheet(
                context: context,
                builder: (BuildContext context) {
                  return MyBottomSheet();
                });
          },
        ),
      ),
    );
  }
}

class MyBottomSheet extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Container(
        color: Colors.pink[200],
        child: Column(
          children: [
            TextField(
              autofocus: true,
            ),
            RaisedButton(
              child: Text('Next'),
              onPressed: () {},
            ),
          ],
        ),
      ),
    );
  }
}
```
Repository: TypeScript
Issue: Add (relative) URL imports for modules
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

- import url
- relative url import

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

Add a new `moduleResolution` mode (e.g. "url") that treats non-bare specifiers in `import` statements and -expressions as URLs, matching the behavior of browser and node ESM. Mostly for relative URLs but potentially also for absolute URLs. It likely shouldn't change the resolution of `require` calls.

There's a similar issue ([Add support for URI style import](https://github.com/microsoft/TypeScript/issues/35749)) that focusses on HTTP URLs but I would consider supporting HTTP URLs out of scope for this issue. It may be possible to layer HTTP support on top of the basic feature, so they aren't mutually exclusive.

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

Write code that works as-is in browsers and node, using filenames that contain characters that would typically be URL encoded (like spaces).

## Examples

<!-- Show how this would be used and what the behavior would be -->

Right now the "classic" and "node" (~CommonJS/babel) resolution modes treat relative specifiers as file system paths and don't support absolute `file://` URLs at all. For browser ESM and node ESM, these should typically be treated as relative URLs. E.g.:

```
// main.ts
import {name} from './dep%20file.js';
console.log(name);

// dep file.ts:
export const name = 'Robin';
```

TypeScript generates working code for this (if emit on error is allowed) but it will fail to trace the import correctly because it expects an imported filename that contains the literal string "%20".

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: [NNC] Bugs Exposed in Binary Op Testing
Labels: module: bootcamp,triaged,NNC

## 🐛 Bug

@ZolotukhinM  found the following bugs in https://github.com/pytorch/pytorch/pull/48282 (and some others that have already been fixed)

- [x] comparison-ops produce incorrect results with dtype=uint8 and negative scalar (@bertmaher)
- [ ] cuda compilation fails with dtype=float16 for pow
- [x] shift ops don't support dtypes correctly (fixed by #49396)
- [x] lshift segfaults on cpu when tensors are int8 *// might be the same as the previous one* (fixed by #49396) 
- [x] remainder and fmod yield wrong results with int8 (fixed by #49357)
- [x] `and` fails with unsupported dtype in IR Eval with int64 dtype (fixed in #48179) 
- [x] `abs` fails with unsupported dtype in IR Eval with int8 dtype (fixed in #49357)

To claim one of these issues just edit and put your git handle next to it. 

## To Reproduce

Steps to reproduce the behavior:

1. Run `python test/test_jit_fuser_te.py -k test_binary_div_ops` and uncomment the op/dtype failure you're working on
2. If working on an IR eval issue, you could use `PYTORCH_TENSOREXPR_DONT_USE_LLVM=1` to enforce using IR eval even if LLVM is available in your pytorch build.

If you have any questions feel free to ping me (Elias Ellison) or @ZolotukhinM  (Mikhail Zolotukhin)
Repository: flutter
Issue: Consider setting up Gold for flutter/tests
Labels: a: tests,c: new feature,framework,P3,team-framework,triaged-framework

I'm not sure if this is feasible. I'm hoping @Hixie and/or @Piinks will know.

When a 3p customer test (e.g. flutter_svg) fails on a golden file, perhaps because of minor and visually acceptable change in Skia, it requires updating the golden in the downstream repo and coordinating that change with an engine roll.

It would be far preferable if Skia gold, or something like it, could be used instead so that reviewers could triage these changes (with approval from the 3p owner of the package).