sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Building in release mode with LTO breaks RPM build process for some code
Labels: A-linkage,T-compiler,C-bug,A-LTO

When building a dynamic library from my Rust code with LTO enabled, the resulting binary includes a seemingly invalid slash-terminated directory table entry, which in turn prevents building an RPM from the library on RHEL (details follow below).

The Rust code (reduced to the minimal code that reproduces the issue) in `src/lib.rs`:

```rust
#[no_mangle]
pub extern "C" fn on_load() {
    let _ = std::panic::take_hook();
}
```

The `Cargo.toml`:
```toml
[package]
name = "lto-bug"
version = "0.1.0"
edition = "2018"

[lib]
crate-type = ["cdylib"]
name = "lto_bug"

[profile.release]
lto = true
```

The build command:
```
cargo build --release
```

I expected to see this happen: Get a valid binary for the dynamic library.

Instead, this happened: 

The resulting binary includes a directory table entry that ends with a slash, which in turn breaks the RPM build process.

The output of `objdump -g target/release/liblto_bug.so` includes:
```
 The Directory Table (offset 0x19d4c):
  1     /cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src
  2     /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src
  3     /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/slice
  4     /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/
  5     /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops
...
```

Entry 4 ends with a slash, which wreaks havoc with RPM's `debugedit` utility that is run while building an RPM.

Reproducing this:
```
$ /usr/lib/rpm/debugedit -b / -d / target/release/liblto_bug.so
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
```

See [this Red Hat bug report](https://bugzilla.redhat.com/show_bug.cgi?id=304121) that describes the problem.
It could be considered a bug in `debugedit`, but it's very longstanding and would be great if Rust didn't do this.

It seems to be some an unintentional side effect that the directory `/rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/` is added to the directory table, certainly with the terminating slash.

I tried to see if I could work around this by using `--remap-path-prefix`, but that seems to have no effect at all on this path.

### 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.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0
```

Also happens with nightly:
```
rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)
binary: rustc
commit-hash: ffa2e7ae8fbf9badc035740db949b9dae271c29f
commit-date: 2020-10-24
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0
```

</p>
</details>
Repository: godot
Issue: Full screen start-up not working on HTML5 with slow network connection
Labels: bug,platform:web,topic:porting

**Godot version:**
Godot 3.2.3


**OS/device including version:**
HTML5 (Chrome/Firefox on Linux)


**Issue description:**
The exported HTML5 project with setting

`window/size/fullscreen=true `

starts in full screen if you test it with a fast connection (as example in a local development server), but if you test it with a relatively slow connection (I've tried with a 10 Mbit ADSL) you get this error on browser console

`Uncaught (in promise) TypeError: Fullscreen request denied`


**Steps to reproduce:**
1) Create a new godot project
2) Enable full screen start-up in project settings
3) Export HTML5 project
4) change default html code adding a button to manually start the engine
5) limit network speed form browser dev tools (set DSL or slower)

**Minimal reproduction project:**
[godot-test.zip](https://github.com/godotengine/godot/files/5446467/godot-test.zip)
Repository: flutter
Issue: [Material] Datatable - Create example docs for single column sorting
Labels: framework,f: material design,d: api docs,P3,team-design,triaged-design

See "Sorting" in https://material.io/components/data-tables#anatomy
Repository: next.js
Issue: withApollo example is still firing queries server-side
Labels: good first issue,examples

# Bug report

## Describe the bug

In the client-only example, Apollo still fires queries during SSR. 
I've noticed that after installing Node fetch har.

`ssr: false` seems to work, but why would I need it in the first place? In my own app it doesn't work either, though I couldn't repro on a simpler app. Setting up is kind of tedious since you have to do it for each query, given that I did not set SSR for Apollo in the first place.
## To Reproduce

```
git clone https://github.com/eric-burel/with-apollo-ssr-query-bug.git
cd with-apollo-ssr-query-bug
yarn && yarn run dev
```
Open `client-only` page and look at the console, some queries are fired.
Link: https://github.com/eric-burel/with-apollo-ssr-query-bug
## Expected behavior

It should fire no query server-side, so no log from Node fetch HAR

## System information

- Version of Next.js: 10.0.0
- Version of Node.js: 10
- `@apollo/client`: 3.1.1

## Additional context

I might definitely have misunderstood something, maybe this is an expected behaviour ? Quite confusing anyway.

In particular, in the context of private app, the SSR call will gives 401 (and I don't want to introduce auth + SSR, I am actually in the process of removing it totally from my app).
Repository: pytorch
Issue: Pooling code does not allow sliding window starting in right padded region
Labels: triaged,module: pooling

The current pooling code does not allow the sliding window to start inside the right padding when ceil_mode=True which is inconsistent with the equation on the docs. This PR https://github.com/pytorch/pytorch/pull/46558 adds a note to the documentation but does not address this issue because it requires further investigation into existing code assumptions.

The code that computes the output shape here does not include right padding on ceil_mode correction. https://github.com/pytorch/pytorch/blob/bbe5bfaa4f5ec1d80cd971198e4abcfd2ea96a7a/aten/src/ATen/native/Pool.h#L34

cc @heitorschueroff
Repository: create-react-app
Issue: Dev server startup increased from 20 seconds to 2 minutes after upgrade to 4.0.0
Labels: needs triage,issue: bug report

### Describe the bug

Dev server startup time increased drastically after upgrade to `4.0.0` from `3.4.3`. From 20 seconds to more than 2 minutes afte upgrade.

### Did you try recovering your dependencies?

Removed all node_modules before upgrading.

### Which terms did you search for in User Guide?

Did not find anything related to this issue - slow startup time of devserver.

### Environment

```
  current version of create-react-app: 4.0.0

System:
    OS: Linux 5.4 Ubuntu 20.04 LTS
   CPU: (8) x64 Intel(R) Core(TM) i7-** CPU @ 1.80GHz
Binaries:
    Node: 14.4.0 - ~/.nvm/versions/node/v14.4.0/bin/node
    Yarn: 1.22.4 - /usr/bin/yarn
npmPackages:
    react: 16.12.0 => 16.12.0 
    react-dom: 16.13.1 => 16.13.1 
    react-scripts: 4.0.0 => 4.0.0
   
   "typescript": "4.0.3",
```

### Steps to reproduce

TBD - it might be somehow specific to our project. Which is medium size TypeScript project.

### More info

I know that this report might be hard to reproduce and I will probably need to provide more information. But there also might be more people having same issue when comparing build/startup times and we might be able to figure out why is this happening - because this seems def as a bug, as build is incredibly slow now and this is blocker for upgrading to new version.

It might be related to project setup, but I dont have idea where to start debugging issue - maybe someone from maintainers will know what might be cause. And where to start look.
Repository: TypeScript
Issue: Suggestion: add flag to notify when awaiting a non-promise
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

async promise force error

## Suggestion

Add a `tsconfig.json` flag to display info/warning/error when awaiting non-PromiseLike code. This will catch developer errors.

## Use Cases

Catch developer errors when writing async code.

## Example

The following code is valid:
```ts
await Promise.all(urls.map(url => {
  fetch(url);
});
console.log('fetching complete');
```

The developer intends to do something once all the `fetch`es complete, but since `map` is not returning any value, it ends up awaiting `[undefined, undefined, ...]`, which means `fetching complete` is logged before the `fetch`es complete. It would be nice if TS gave an info/warning/error in this case. 

The correct code is:

```ts
await Promise.all(urls.map(url => {
  return fetch(url);
});
console.log('fetching complete');
```

This example is paired down to the bare minimum for simplicity, but IRL code is more complex.

## 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: flutter
Issue: Android with a physical mouse should still show text selection menu
Labels: a: text input,platform-android,framework,a: mouse,P3,team-design,triaged-design

If I connect a physical mouse to a Pixel phone and run Google Keep, the text selection menu and text selection handles still appear when I select text using the mouse.  However, Flutter apps don't show either.  Flutter should mimic native and continue to show the menu and handles when a mouse is used on Android.

<details>

<summary>Code (just a text field)</summary>

```dart
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            TextField(),
          ],
        ),
      ),
    );
  }
}
```

</details>
Repository: storybook
Issue: No way to import doc components when using `addon-essentials`
Labels: question / support,addon: docs,addon: essentials

**Is your feature request related to a problem? Please describe**
I'm trying to create a modified DocsPage, and so I'm trying to import the components required.  But, because I'm using `addon-essentials` there doesn't seem to be any way to import the components from `@storybook/addons-docs/blocks`.  Is the only way to do this to disable addon-essentials all together and install everything individually? 

**Describe the solution you'd like**
Ideally, it would be great if the same components could be exported from addon-essentials somehow. 


**Are you able to assist to bring the feature to reality?**
no
Repository: godot
Issue: Improve the error message when attempting to use `not >` or `not <` in GDScript
Labels: enhancement,topic:gdscript,usability

very minor error

operating windows 10

version 3.2.2 stable

this isn't at all major but just wanted to mention

my code:

if $"explosion/white circle".scale not > Vector2(2,2):
___________$"explosion/white circle".scale+=Vector2(0.08,0.08)

the same happens with !>

error:

Parser Error: ':' expected at end of line.

if I change 'not >' to '<' it works fine.
but I think the error should be changed or 'not >' should = <
Repository: TypeScript
Issue: Add `trim` as new intrinsic for use with template literal types
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 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

intrinsic
trim
whitespace

possible related: https://github.com/microsoft/TypeScript/issues/41210

## Suggestion

Add `trim` as a new intrinsic alongside the existing intrinsic types:
Uppercase
Lowercase
Capitalize
Uncapitalize

## Use Cases

Trim can be implemented with the current types pretty easily by doing something like:

```ts
type Whitespace = '\n' | ' ';
type Trim<T> = T extends `${Whitespace}${infer U}` ? Trim<U> : T extends `${infer U}${Whitespace}` ? Trim<U> : T;
```

But this can quickly run into depth limits if there is a lot of repeated whitespace. 

```ts
type Whitespace = | '\n'|  ' ' | 'x' // Add x as whitespace to make example easier to read
type Trim<T> = T extends `${Whitespace}${infer U}` ? Trim<U> : T extends `${infer U}${Whitespace}` ? Trim<U> : T;
type Test = Trim<`abc
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
`>
```

This can be improved by adding strings of repeated whitespace to the Whitespace type, but will still run into limitations:
```ts
type Whitespace = | '\n' | '      ' | '     ' | '    ' | '   ' | '  ' | ' '
type Trim<T> = T extends `${Whitespace}${infer U}` ? Trim<U> : T extends `${infer U}${Whitespace}` ? Trim<U> : T;
```

This seems like a good case for an intrinsic implementation since it is a fairly simple and common operation on strings.

One use case would be to correctly type template literal helpers that trim leading indent whitespace, but there are probably many cases where trimming whitespace from a string would be useful. 

## Examples
```ts
Trim<`

   abc

`> // 'abc'
```

## 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: Export TorchScript Classes as TorchScript code
Labels: oncall: jit

## 🚀 Feature

Add an option to export TorchScript classes as TorchScript code when `torch.jit.save`-ing a module. That way, the resulting file will be hermetically sealed, without relying on any particular code versioning to get it to execute.

## Motivation
Right now, if you `torch.jit.script` a class, PyTorch relies on the actual class code to being available after `torch.jit.load`-ing the model for instance, in the code below I cannot actually execute my `Module` without having access to the `A` class

```python
@torch.jit.script
class A:
    def __init__(self, x: int):
        self.x = x
class Module(torch.nn.Module):
    def forward(self):
        return A(1)
scripted = torch.jit.script(Module())
torch.jit.save(scripted, "test.pt")
```

This creates a really unfortunate coupling between the code defining the `A` class and the code need to run the `Module` class. This is also quite unintuitive, b/c scripted modules do *not* rely referencing code -- the code dependence seems only to beh ere for TorchScript non-module classes.

In our particular use case, we are using a `TorchScript` class as a "tuple but with some simple helper methods".  Unfortunately, this dependence on our code is preventing us from refactoring our classes in our codebase (e.g. adding new fields) b/c of backwards compatibility with older models we've already serialized.

## Pitch

Add an option to export the `A` class's code into the serialized torchscript module. This would allow `torch.jit.script` to produce hermetically sealed modules that don't need anything except PyTorch to execute correctly (which would massively simplify deployment for us).

## Alternatives

If we don't do this, I think we should clearly document this behavior in the TorchScript classes section -- as I said earlier, b/c serializing a custom `nn.Module` does *not* require the underlying class definition, this code dependence came as a surprise to us.


cc @gmagogsfm
Repository: pytorch
Issue: Changing order of field assignments breaks TorchScript classes
Labels: oncall: jit

## 🐛 Bug

If I have a `TorchScript` class, changing the order of assignments in the constructor breaks loading old models, even though this entails no logical Python change

## To Reproduce

Consider the following script:

```python
import torch
import sys

class Module(torch.nn.Module):
    def forward(self):
        return A(1, 2)
if __name__ == "__main__":
    if sys.argv[1] == "serialize":
        @torch.jit.script
        class A:
            def __init__(self, a: int, b: int):
                self.a = a
                self.b = b
            def __repr__(self):
                return f"A(a={self.a}, b={self.b})"

        module = torch.jit.script(Module())
        torch.jit.save(module, "test.pt")
    elif sys.argv[1] == "load":
        @torch.jit.script
        class A:
            def __init__(self, a: int, b: int):
                self.b = b  # Note: we only flipped the order of assignments
                self.a = a
            def __repr__(self):
                return f"A(a={self.a}, b={self.b})"
        module = torch.jit.load("test.pt")
    print(module.forward())
```

Notice that the only difference between the two definitions of `A` is the *order* to which we assign `self.b` and `self.a` -- but the *values* should still be the same.

Now, if we run:
```
$ python test.py serialize
A(a=1, b=2)
$ python test.py load
A(a=2, b=1)
```

Which means that the loading of an older model has broken!



## Expected behavior

`python test.py load` should also give us `A(a=1, b=2)`

## Environment

 - PyTorch Version (e.g., 1.0):  1.6 and 1.7
 - OS (e.g., Linux): Linux (Fedora 32)
 - How you installed PyTorch (`conda`, `pip`, source): `conda` with `cpuonly`
 - Python version: 3.6

## Additional context

For context, this is biting us due to the backwards compatibility constraints from https://github.com/pytorch/pytorch/issues/46944.

cc @gmagogsfm
Repository: pytorch
Issue: Add Optimistic Mirror Descent (OMD)
Labels: module: optimizer,triaged

## 🚀 Feature

<!-- A clear and concise description of the feature proposal -->

Add [Mirror-Prox](https://dl.acm.org/doi/abs/10.1137/S1052623403425629) / Optimistic Mirror Descent (OMD) to PyTorch's [optimizers](https://pytorch.org/docs/stable/optim.html). 

Vanilla OMD is described in equation 5 of paper 1 and equation OMD of paper 2.

Adam OMD (optimistic Adam) is described in algorithm 1 of paper 1 and algorithm 3 of paper 2.

Papers:
1. [Training GANs with Optimism](https://arxiv.org/abs/1711.00141) (2017)
2. [Optimistic mirror descent in saddle-point problems: Going the extra (gradient) mile](https://arxiv.org/abs/1807.02629) (2018)

There seems to be a PyTorch implementation [here](https://discuss.pytorch.org/t/optimistic-mirror-descent-in-saddle-point-problems-adam-optimizer-modification/26928), a PyTorch implementation [here](https://github.com/georgepar/optimistic-adam/blob/master/optim.py), and a Tensorflow implementation [here](https://gist.github.com/EndingCredits/b5f35e84df10d46cfa716178d9c862a3).

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

As these papers show, OMD works better than vanilla MD for solving saddle-point problems.

These saddle-point problems arise in adversarial settings, e.g. training [GANs](https://en.wikipedia.org/wiki/Generative_adversarial_network) and multi-agent reinforcement learning.

cc @vincentqb
Repository: pytorch
Issue: Record shaping assertions and use them for tracing / scripting optimization and codegen
Labels: oncall: jit,module: codegen

Motivated in https://github.com/pytorch/pytorch/issues/40373#issuecomment-716842407.

Recording assertions `assert X.shape[1] == Y.shape[2] and X.shape[2] == 64 and Z.ndim == 3` (or directly via `torch.assert_shapes(...)`) as part of tracing / scripting can help and streamline codegen (as can eliminate unneeded checks or broadcasts). https://github.com/pytorch/pytorch/issues/40373 contains a wider discussion, but @ezyang suggested that a more limited scope can be of value as well.

cc @gmagogsfm @apaszke
Repository: go
Issue: cmd/link: c-shared build mode not working with UPX
Labels: help wanted,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
go version go1.15.2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/root/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/golang"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build986805596=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I wrote a simple Golang file. is as follows:

```
package main
func main() {
}
```

Then build it :
`go build -buildmode=c-shared -o library.so main.go`

After library.so created I want to compress it with UPX

run `upx -9 library.so` and got error

### What did you expect to see?

92200 ->     49976   54.20%   linux/amd64   library.so                    


### What did you see instead?

`upx: library.so: CantPackException: PT_NOTE 0xa71cc above stub`


I opened a [issue in GitHub UPX](https://github.com/upx/upx/issues/410). They told me the problem the library.so does not have the correct format to allow compression.

This problem only when use -buildmode=c-shared in command-line.

Thanks.