sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ant-design
Issue: Caption missing in Table Component 
Labels: Inactive,improvement

- [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
[https://github.com/ant-design/ant-design](https://github.com/ant-design/ant-design)

### Steps to reproduce
no option exists

### What is expected?
We need a caption tag for accessibility

http://www.edition-w3.de/TR/1999/REC-html401-19991224/struct/tables.html#h-11.4

### What is actually happening?
no caption tag

| Environment | Info |
|---|---|
| antd | 4.1.5 |
| React | 16 |
| System | Windows |
| Browser | Chrome |

---
thank you


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: qnnpack's quantized-add gives wrong result
Labels: oncall: quantization,triaged,oncall: mobile

## 🐛 Bug

qadd two qint8 tensor with qnnpack backend gives the wrong result in some condition.
I have compared the result with fbgemm backend. This bug might caused by rounding.

## To Reproduce

```python
import torch
import struct


def make_quint8_tensor(qint, scale, zero_point):
    return torch.quantize_per_tensor(
        torch.Tensor([(qint - zero_point) * scale]).to(torch.float32),
        scale=scale,
        zero_point=zero_point,
        dtype=torch.quint8,
    )

def print_qtensor(t):
    print(
        f'\tquantized={t.int_repr().tolist()[0]}\n'
        f'\tfloat={t.dequantize()[0].item()}\n'
        f'\tscale={t.q_scale()}\n'
        f'\tzero_point={t.q_zero_point()}\n'
    )

def set_backend(backend):
    torch.backends.quantized.engine = backend

a_scale = struct.unpack('f', b'\xf1$&=')[0] # ~0.040562573820352554
b_scale = struct.unpack('f', b'.\xe5\xb5=')[0] # ~0.08881603181362152
c_scale = struct.unpack('f', b'L\xed\xb8=')[0] # ~0.09029635787010193
az, bz, cz = 112, 126, 124
aq = make_quint8_tensor(158, a_scale, az)
bq = make_quint8_tensor(136, b_scale, bz)

print('quint8 tensor a:')
print_qtensor(aq)
print('quint8 tensor b:')
print_qtensor(bq)

set_backend('fbgemm')
cq = torch.ops.quantized.add(aq, bq, c_scale, cz)
print('[fbgemm] quint8 tensor a+b=c:')
print_qtensor(cq)

set_backend('qnnpack')
cq = torch.ops.quantized.add(aq, bq, c_scale, cz)
print('[qnnpack] quint8 tensor a+b=c:')
print_qtensor(cq)
```

output:
```
quint8 tensor a:
        quantized=158
        float=1.8658783435821533
        scale=0.040562573820352554
        zero_point=112

quint8 tensor b:
        quantized=136
        float=0.8881603479385376
        scale=0.08881603181362152
        zero_point=126

[fbgemm] quint8 tensor a+b=c:
        quantized=154
        float=2.708890676498413
        scale=0.09029635787010193
        zero_point=124

[qnnpack] quint8 tensor a+b=c:
        quantized=155
        float=2.799187183380127
        scale=0.09029635787010193
        zero_point=124
```

Similar results can be reproduced with a=66, b=116, too.

## Expected behavior

Give a right result.

## Environment

PyTorch version: 1.5.0
Is debug build: No
CUDA used to build PyTorch: 10.2

OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: version 3.10.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.105
GPU models and configuration:
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti

Nvidia driver version: 440.64
cuDNN version: /usr/local/cuda-10.1/targets/x86_64-linux/lib/libcudnn.so.7

Versions of relevant libraries:
[pip3] numpy==1.18.2
[pip3] torch==1.5.0
[pip3] torchfile==0.1.0
[pip3] torchsummary==1.5.1
[pip3] torchsummaryX==1.3.0
[pip3] torchvision==0.6.0
[conda] Could not collect

## Additional context



cc @jerryzh168 @jianyuh @dzhulgakov @raghuramank100 @jamesr66a
Repository: go
Issue: x/build/cmd/gerritbot: inline comments not synchronized to GitHub
Labels: Builders,NeedsFix

### What did you do?

1. Opened golang/scratch#35 which got imported into Gerrit as https://go-review.googlesource.com/c/scratch/+/230213
2. Replied with an inline code comment on the CL in Gerrit: https://go-review.googlesource.com/c/scratch/+/230213/1/tklauser/main.go#6

### What did you expect to see?

Inline code comment synchronized to the GitHub PR by GerritBot.

### What did you see instead?

GerritBot posted a comment to the PR, but the comment content was not added: https://github.com/golang/scratch/pull/35#issuecomment-619994256

Also, "global" reply comments on the CL get posted properly to the GitHub PR, see the "Testing with a CL comment" message https://go-review.googlesource.com/c/scratch/+/230213/2#message-7705eb20fe25b49c54c2c928532651e83a4e118f which got posted as https://github.com/golang/scratch/pull/35#issuecomment-619994274
Repository: svelte
Issue: Animation rects need to be measured before any other updates
Labels: bug,temp-stale,transition/animation

**Describe the bug**
When using the `animate:` directive, DOM nodes are measured immediately before updates are applied to them. But if an update to a parent element already happened, this can result in them being in the wrong place at the time of being measured.

**To Reproduce**
https://svelte.dev/repl/8c4d61bba033437bb9add90f5355df25?version=3.21.0 (via https://stackoverflow.com/questions/61430023/svelte-out-transition-in-flip-animation-in-grid-layout-flies-off-from-top-left)

**Expected behavior**
Toggling the column should cause 3, 6 and 9 to smoothly move to their new location. To achieve this, I think we'd need to measure DOM nodes before any DOM updates happened at all, which sounds tricky to do.

**Severity**
Medium. It's a bad bug, but a fairly niche situation.
Repository: storybook
Issue: addon-docs: Support lineHeight and letterSpacing in Typeset
Labels: feature request,addon: docs,block: other

**Is your feature request related to a problem? Please describe.**
Support lineHeight and letterSpacing in Typeset

**Describe the solution you'd like**
Add support via props
https://github.com/storybookjs/storybook/blob/next/lib/components/src/blocks/Typeset.tsx

**Describe alternatives you've considered**
 - Ejecting from typset altogether.
 - Using style props (with side effects)
```
<Typeset fontSizes={['24px']} sampleText="Headline 1" fontWeight="700" style={{ letterSpacing: '0.15px', lineHeight: '32px'}} />
<Typeset fontSizes={['20px']} sampleText="Headline 2" fontWeight="700" style={{ letterSpacing: '0.15px', lineHeight: '28px'}} />
<Typeset fontSizes={['18px']} sampleText="Headline 3" fontWeight="700" style={{ letterSpacing: '0.15px', lineHeight: '24px'}} />
```

**Are you able to assist bring the feature to reality?**
no 

**Additional context**
Other typeset props might be worth considering
Repository: TypeScript
Issue: expose textChanges API
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
api, textChanges
<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

expose textChanges api to avoid total file transformer for sourcecode level tools.

<!-- A summary of what you'd like to see added or changed -->

## 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: tensorflow
Issue: Using tf.data.Dataset has big overhead
Labels: stat:awaiting tensorflower,comp:data,type:performance,TF 2.4

**System information**
- Have I written custom code (as opposed to using a stock example script provided in TensorFlow): yes
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): RHEL 7.5
- TensorFlow installed from (source or binary): binary
- TensorFlow version (use command below): 2.1.0
- Python version: 3.7.4
- CUDA/cuDNN version: 10.1
- GPU model and memory: GTX 1080

**Describe the current behavior**

Using a `Dataset` reduces performance by a small but significant amount, ~7% for ImageNet like data

**Describe the expected behavior**

Using `Dataset` has no or only marginal performance impact

**Standalone code to reproduce the issue**

```
import tensorflow as tf
from timeit import timeit


@tf.function
def train_step(x, y):
    model.train_on_batch(x, y)


for useData in (True, False):
    model = tf.keras.applications.ResNet50(weights=None, classes=1000)
    model.compile(
        loss=tf.losses.SparseCategoricalCrossentropy(),
        optimizer=tf.keras.optimizers.SGD(),
        metrics=['accuracy'],
        experimental_run_tf_function=True)

    if useData:
        x = tf.random.uniform([1, 32, 224, 224, 3])
        y = tf.random.uniform([1, 32, 1], minval=0, maxval=999, dtype=tf.int64)
        dataset = tf.data.Dataset.from_tensor_slices((x, y)).repeat()

        def train(steps):
            for x, y in dataset.take(steps):
                train_step(x, y)
    else:
        x = tf.random.uniform([32, 224, 224, 3])
        y = tf.random.uniform([32, 1], minval=0, maxval=999, dtype=tf.int64)

        def train(steps):
            for _ in range(steps):
                train_step(x, y)

    # warmup
    train(2)
    t = timeit(lambda: train(50), number=10)
    print('useData: %s -> %s' % (useData, t))
```

Sample output:
useData: True -> 89.92945478390902
useData: False -> 86.73652107780799

For more realistic training loops (e.g. including callbacks) the difference is even bigger.
Some of my tests:

```
constant: total images/sec: 496.47 (calculation(497.53) + preprocessing(1.06)) 
dataset:  total images/sec: 465.09 (calculation(478.64) + preprocessing(13.55)) 
```

First number is calculated from training loop execution time (after warmup) the latter only the train-step and the difference (to the first number) which I called "preprocessing" as it is iterating over the dataset (calling next on the iterator by the for loop) and hence dominated by preprocessing functions if present (none here) including the `repeat` and `take` Dataset adapters.

So 2 conclusions: Getting elements from the iterator seems to be quite costly (1->13.6) and even the training loop itself gets slower (498 -> 479)

This would be a reason to avoid the dataset API.
Repository: next.js
Issue: amp-custom attribute gets stripped (if react-jss is used)
Labels: good first issue

Hello again! 

# Bug report

## Describe the bug

It seems that if [react-jss](https://cssinjs.org/react-jss/?v=v10.1.1) is used as described in [Next.js official example](https://github.com/zeit/next.js/tree/master/examples/with-react-jss), `amp-custom` attribute gets striped from the `<style>` element.

## To Reproduce

I've created [simple repository](https://github.com/cibulka/nextjs-amp-jss) with two Next.js projects. Each tries to make `react-jss` work with AMP a bit differently with a slightly different outcomes (everything is described there).

The repo was created with `create-next-app` command and its only dependency is `react-jss`.

Repo is here: https://github.com/cibulka/nextjs-amp-jss

## Expected behavior

Styles (both global and local) get applied as requested and `amp-custom` attribute is not stripped from markup.

## System information

- OS: macOS 10.15.4 
- Browser: Chrome 81
- Version of Next.js: 9.3.5
- Version of Node.js: 13.12.0

## Additional context

I've created [discussion topic](https://github.com/zeit/next.js/discussions/12188), but it did not receieve much love. 

Sorry for duplicating my question, but the current behaviour seems like a bug (not sure if with `react-jss` or `Next.js though).

---

I might be missing something obvious as this is pretty much my start with AMP. 

Thank you!
Repository: ant-design
Issue: Input component has difference in behavior to the React input component and doesn't show errors when switching from controlled to uncontrolled or vice versa
Labels: Inactive

- [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/antd-reproduction-template-898r3?file=/index.js)

### Steps to reproduce
1. Write some text in both inputs
2. Click on both `change` buttons
4. Observe results, click the buttons again, observe the results again
4. Set values to `undefined` instead of `null` and observe results

### What is expected?
Both inputs to behave the same way. If the decision to allow `null` as a valid value to `Input` is purposeful, or for `Input` to reset when given `value=undefined` or `value=null`, at least there should be warnings about changing `Input` from uncontrolled => controlled or vice versa.

### What is actually happening?
Observe that React input warns about input value `null` is not valid input value and doesn't reset the input, Antd Input doesn't warn, accepts the `null` as a valid value and resets the input text. The same happens when value is `undefined`, Antd `Input` resets the value, React input doesn't. React input also warns about uncontrolled => controlled changing.

| Environment | Info |
|---|---|
| antd | 4.1.5 |
| React | 16.12.0 |
| System | Ubuntu 18.04.4 LTS |
| Browser | Version 80.0.3987.163 (Official Build) (64-bit) |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: Godot Fix Dependency on material refuses to replace old material with new renamed one
Labels: bug,topic:editor

The title says it all. I just renamed a material file (Material.material) to DanceFloor.material. However, when I decide to fixe the dependency issue by replacing the path to the DanceFloor.material file, Godot stubbornly refuses and does not change a thing. Screenshots below:

Fix dependencies button does not work...
![image](https://user-images.githubusercontent.com/15871822/80399978-1bb50780-8888-11ea-8ae8-c6310ad14d54.png)

Manually setting it to a new file does not work because Godot refuses to change the original path.
![image](https://user-images.githubusercontent.com/15871822/80400037-3a1b0300-8888-11ea-84d4-aa713e93355f.png)
Repository: go
Issue: all: understand binary size changes vs 1.14
Labels: Suggested,help wanted,NeedsInvestigation,binary-size

I was curious about binary size changes from 1.14 to tip. The results:

```
file      before    after     Δ        %        
addr2line 4307728   4415680   +107952  +2.506%  
api       5972696   5256224   -716472  -11.996% 
asm       5134472   5098312   -36160   -0.704%  
buildid   2843720   2901096   +57376   +2.018%  
cgo       4823736   4843608   +19872   +0.412%  
compile   24899576  19983664  -4915912 -19.743% 
cover     5259800   5292392   +32592   +0.620%  
dist      3665080   3718888   +53808   +1.468%  
doc       4672712   4071904   -600808  -12.858% 
fix       3372856   3422024   +49168   +1.458%  
link      6613720   6755112   +141392  +2.138%  
nm        4253280   4373520   +120240  +2.827%  
objdump   4655376   4763232   +107856  +2.317%  
pack      2294280   2364760   +70480   +3.072%  
pprof     14747604  14618708  -128896  -0.874%  
test2json 2819320   2889496   +70176   +2.489%  
trace     11669292  11783892  +114600  +0.982%  
vet       8342376   7231080   -1111296 -13.321% 
total     120347624 113783592 -6564032 -5.454%  
```

This immediately raises a few questions.

*  Why are a few tools significant smaller? (cmd/compile shrank mostly because of the rulegen changes at the beginning of the cycle. I don't understand cmd/doc, cmd/vet, and cmd/api.)
* Why are most tools a bit larger? Did a core package (like runtime) grow considerably? Was it due to compiler regressions? Something about the new linker?

There may not be any bugs here, but it'd be nice to understand a bit better what happened.

Anybody up for doing some sleuthing?

Of note for anyone investigating, you'll discover that object files are ~50% bigger at tip than 1.14. This is due to the -newobj flag being enabled by default. If you're going to use object files to investigate, you probably want to disable it.
Repository: go
Issue: cmd/gofmt: refuses to format file with invalid column in line directive
Labels: NeedsInvestigation

```go
package p

//line :7:0
var x int
```

```
$ gofmt x.go     
x.go:3:11: invalid column number: 0
```

I don't see why an invalid line directive should prevent gofmt from formatting the file. It doesn't change its behavior based on its contents.

Low priority.
Repository: godot
Issue: Godot server version fails to run projects.
Labels: bug,topic:dotnet

**Godot version:**
Godot v3.2.1 stable mono linux server 64 bit

**OS/device including version:**
Ubuntu Linux 18.04/PC

**Issue description:**
Trying to launch a project fails. For example:
```
./godot --path /path/to/project
```
Results in:
```
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1693.
```
Or sometimes with some projects:
```
ERROR: can_instance: Method failed. Returning: __null
   At: modules/mono/csharp_script.cpp:2912.
```

I had one other random person test it and it failed for them too. Bug seems to be present in latest preview also. Didn't test older versions.

The project runs perfectly in the GUI version of Godot.

**Steps to reproduce:**
0) Download and unpack fresh Godot server:
https://downloads.tuxfamily.org/godotengine/3.2.1/mono/Godot_v3.2.1-stable_mono_linux_server_64.zip
1) Create a minimal project with one node.
2) Attach a C# script.
3) Put `Console.WriteLine("Hello");` in the script or anything that gives output to console.
4) Try to run it from command line either with:
`./godot --path path/to/project`
Or with:
`./godot path/to/project/project.godot`
5) See it fail miserably.

**Minimal reproduction project:**
https://www.dropbox.com/s/voqut71tdloj5sd/bugtest.tar.gz?dl=0
Repository: pytorch
Issue: Efficient handling special gradient values in the autograd
Labels: module: performance,feature,module: autograd,triaged

We now have a few code places where we have special case where we return specific subgradients.
For example [here](https://github.com/pytorch/pytorch/blob/201ba139115adeecae4f094a9c9790200e53ff99/tools/autograd/templates/Functions.cpp#L115) for the norm function at 0.

We now have few functions that perform the same thing.
It would be interesting to allow users that know that they won't encounter these problematic points a way to disable these operations.

We could provide a general flag that disable these operations during the backward pass.
- Either while the flag is set (so the flag should be set for the whole backward pass in general). Unless hooks are used to change it.
- Either during the forward pass and we record it as an argument to the backward function.



cc @ezyang @SsnL @albanD @zou3519 @gqchen @VitalyFedyunin @ngimel
Repository: rust
Issue: Paramater type deduction fails to coerce fn item to function pointer if surrounded by Option.
Labels: T-lang,A-inference,C-feature-request,A-coercions

<!--
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 foo(_: Option<fn()>) {}
fn bar() {}

pub fn main() {
    foo(Some(bar)); // Works
    let f = Some(bar);
    foo(f) // error[E0308]: mismatched types expected fn pointer, found fn item
}
```

I expected to see this happen: 
IMHO this should compile. The fn item should coerce into the function ptr, even if surrounded by `Option`.

Instead, this happened:

```
  |
7 |     foo(f) // error[E0308]: mismatched types expected fn pointer, found fn item
  |         ^ expected fn pointer, found fn item
  |
  = note: expected enum `std::option::Option<fn()>`
             found enum `std::option::Option<fn() {bar}>`
```

### 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.43.0 (4fb7144ed 2020-04-20)
```
Repository: flutter
Issue: A11y of nested Navigator seems broken
Labels: framework,a: accessibility,customer: money (g3),has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-framework,triaged-framework

b/155104967

When putting a Navigator in a Row/Column, it seems that the semantics nodes that come before the Navigator are not collected. See:

```dart
Semantics(
  explicitChildNodes: true,
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.stretch,
    children: [
      Expanded(child: Text('1')),
      Expanded(
        child: Navigator(
          initialRoute: '/',
          onGenerateRoute: (_) =>
              PageRouteBuilder(pageBuilder: (_, __, ___) => Text('2')),
        ),
      ),
      Expanded(child: Text('3')),
    ],
  ),
);
```

This looks like the following in SemanticDebugger. I would have expected Row `1` to be rendered as well.

![image](https://user-images.githubusercontent.com/6687929/80415591-99c4de80-8887-11ea-9ee6-d39f89b2ea7f.png)
Repository: rust
Issue: Compiler error for move involving struct instantiation with ..default isn't clear
Labels: C-enhancement,A-diagnostics,A-borrow-checker,T-compiler,D-confusing,D-papercut

The compiler error for moves incurred by `..default` syntax could be more user-friendly.

Test program:

```rust
struct MyStruct {
    boolean: bool,
    collection: std::collections::HashMap<String, String>,
}

impl Default for MyStruct {
    fn default() -> Self {
        Self {
            boolean: false,
            collection: std::collections::HashMap::new(),
        }
    }
}

impl Drop for MyStruct {
    fn drop(&mut self) {
        println!("dropping");
    }
}

fn main() {
    let foo = MyStruct {
        boolean: true,
        ..MyStruct::default()
    };
}
```

And here is the compiler error:
```
error[E0509]: cannot move out of type `MyStruct`, which implements the `Drop` trait
  --> src/main.rs:22:15
   |
22 |       let foo = MyStruct {
   |  _______________^
23 | |         boolean: true,
24 | |         ..MyStruct::default()
25 | |     };
   | |     ^
   | |     |
   | |_____cannot move out of here
   |       move occurs because value has type `std::collections::HashMap<std::string::String, std::string::String>`, which does not implement the `Copy` trait

error: aborting due to previous error

For more information about this error, try `rustc --explain E0509`.
error: could not compile `move-error`.
```

This stumped me because I couldn't figure out why a move was being incurred. I learned from Twitter (thanks @mbrubeck) that the `..default` syntax is triggering that move.

Perhaps the compiler error could say something about the `..default` syntax being responsible for the move?
Repository: pytorch
Issue: cdist docs imply only one batch dimension is possible, but actually arbitrarily many are allowed
Labels: module: docs,triaged,module: distance functions

self explanatory

cc @jlin27 @mruberry