sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: -buildmode=c-shared without specifying output file fails does not add .dll extension on Windows and .so extension on linux
Labels: help wanted,OS-Windows,NeedsInvestigation,GoCommand

<!--
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.14.1 windows/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>
set GO111MODULE=auto
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\anon\AppData\Local\go-build
set GOENV=C:\Users\anon\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\anon\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\anon\AppData\Local\Temp\go-build481521658=/tmp/go-build -gno-record-gcc-switches
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
I tried to build a c-shared library
```golang
package main
import "fmt"
import "C"

//export test
func test() {
	fmt.Println("Hello World!")
}

func main() {

}
```

The archive is linked against a C which just calls `test()` with:
```shell
gcc main.c -L<path to dll folder> -l<dll name without extension> -o test.exe
```
Executing `test.exe` does not produce any output.

### What did you expect to see?
A valid dll file (standard dynamic library format on windows)

### What did you see instead?
The call `go build -buildmode=c-shared`does not yield a valid dll (I think; it does not have any extension by default). It produces a `[folder name]` file without any extension.

I'm not sure what happens, but if you try to link it against a C `main`the `main` function does not get executed. The linker does not produce any warnings or errors about the file (after renaming [name] to [name].dll).

If you produce the archive with `go build -buildmode=c-shared -o <name>.dll` everything works as expected, but `go build -buildmode=c-shared` should be sufficient, but it isn't.
Repository: flutter
Issue: [macos] force touch trackpad support.
Labels: c: new feature,engine,platform-mac,a: desktop,P3,team-macos,triaged-macos

There's currently no way to react to force touch actions on MacOS systems with a force touch trackpad.

Related issues:
#23604
Repository: pytorch
Issue: About tensorboard in pytorch record graph in different state
Labels: triaged,oncall: visualization

## ❓ Questions and Help
I want to save a model graph which changed along with training. For example, if the training epoch > 5, the model has a new structure. If I need to save both models' graph, how should I do? or can I achieve this? the graph will be overwritten if I save the model twice.

## Environment
- Pytorch: 1.3.1
- OS (e.g., Linux): ubuntu16.04
- Python version: 3.7

## Code

```
import torch
import torchvision
from torch.utils.tensorboard import SummaryWriter
from torchvision import datasets, transforms
import torch.nn as nn
import torch.nn.functional as F

writer = SummaryWriter('./log')

transform = transforms.Compose([transforms.ToTensor(), transforms.Normalize((0.5,), (0.5,))])
trainset = datasets.MNIST('./data/', train=True, download=True, transform=transform)
trainloader = torch.utils.data.DataLoader(trainset, batch_size=64, shuffle=True)

class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        self.conv1 = nn.Conv2d(in_channels=1, out_channels=5, kernel_size=5)
        self.conv2 = nn.Conv2d(5, 10, 5)
        self.conv3 = nn.Conv2d(10, 20, 3)

        self.fc = nn.Linear(6480, 10)

        self.fc1 = nn.Linear(6480, 40)
        self.fc2 = nn.Linear(40, 10)
        self.epoch = 0

    def forward(self, x):
        self.epoch += 1

        in_size = x.size(0)
        x = F.relu(self.conv1(x))
        x = F.relu(self.conv2(x))
        x = F.relu(self.conv3(x))

        x = x.view(in_size, -1)

        if self.epoch < 5:
            x = self.fc(x)
        else:
            x = self.fc1(x)
            x = self.fc2(x)

        return F.log_softmax(x)

model = Net()
images, labels = next(iter(trainloader))

writer.add_graph(model, images)

model.epoch = 5
writer.add_graph(model, images)

writer.close()
print("-----Finish!-----")
```
Repository: rust
Issue: Generate better memcpy code for types with alignment padding
Labels: A-LLVM,I-slow,C-enhancement,T-compiler

Consider the type `S0` below, which has 9 bytes of payload data, but because of alignment requirements its size is 16 bytes. It implements `Copy`, so it can be cloned and copied by `memcpy`. rustc tends to emit 9-byte `memcpy` calls for it in several cases, even though it would be legal to emit `memcpy` calls of size anywhere between 9 bytes and 16 bytes. On x86-64, a 9-byte memcpy is 2x slower than a 16-byte memcpy: the former requires 2 loads and 2 stores, whereas the latter can use just 1 load and 1 store. It would be nice for Rust to emit the more efficient memcpy calls. Currently I'm working around this issue by manually padding my type up to 16 bytes of payload data, like in `S1`.

Compare the generated assembly of `copy_s0` and `copy_s1`:

```asm
playground::copy_s0:
	movq	(%rsi), %rax
	movb	8(%rsi), %cl
	movq	%rax, (%rdi)
	movb	%cl, 8(%rdi)
	retq

playground::copy_s1:
	movups	(%rsi), %xmm0
	movups	%xmm0, (%rdi)
	retq
```

Similar issues show up for `clone_from_slice`.

```rust
#[derive(Clone, Copy)]
pub struct S0(u64, u8);

pub fn clone_s0(dst: &mut S0, src: &S0) {
    *dst = src.clone();
}

pub fn copy_s0(dst: &mut S0, src: &S0) {
    *dst = *src;
}

pub fn clone_s0_array(dst: &mut [S0; 8], src: & [S0; 8]) {
    *dst = src.clone();
}

pub fn copy_s0_array(dst: &mut [S0; 8], src: & [S0; 8]) {
    *dst = *src;
}

pub fn clone_s0_slice(dst: &mut [S0; 8], src: & [S0; 8]) {
    dst.clone_from_slice(src);
}

pub fn copy_s0_slice(dst: &mut [S0; 8], src: & [S0; 8]) {
    dst.copy_from_slice(src);
}

#[derive(Clone, Copy)]
pub struct S1(u64, u8, [u8; 7]);

pub fn clone_s1(dst: &mut S1, src: &S1) {
    *dst = src.clone();
}

pub fn copy_s1(dst: &mut S1, src: &S1) {
    *dst = *src;
}

pub fn clone_s1_array(dst: &mut [S1; 8], src: & [S1; 8]) {
    *dst = src.clone();
}

pub fn copy_s1_array(dst: &mut [S1; 8], src: & [S1; 8]) {
    *dst = *src;
}

pub fn clone_s1_slice(dst: &mut [S1; 8], src: & [S1; 8]) {
    dst.clone_from_slice(src);
}

pub fn copy_s1_slice(dst: &mut [S1; 8], src: & [S1; 8]) {
    dst.copy_from_slice(src);
}


```

([Playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=820411986f8028ac6ad00a93ac953898))
Repository: rust
Issue: Switching from `impl` to `dyn` changes lifetime inference (maybe?)
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler

I'm not really sure how to report this bug, as I'm not even sure it actually is a bug in Rust, due to my not understanding enough how lifetimes are at work in this example.

So I'll just give the code and try to explain (it's quite long, so I've just put it on the playground). The interesting code is at the bottom of the playground links.

#### Failing code

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5bb42243a4f952045f4991f280c101e0

This code doesn't compile. It is basically an extraction of the commented code, which compiles.

I originally assumed that this was a mistake on my part of providing the correct lifetimes.

However…

#### Working code

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b7f082cd3912f0ad1d7176c0adb51928

Here, the code does compile. The only change is to replace `Pin<Box<dyn 'static + Send + Future<...>>>` with `Pin<Box<RetFut>>` with `RetFut: 'static + Send + Future<...>`

It appears quite weird that this code compiles but not the previous one, and I'm thus reporting this bug.

As usual, thank you for all your work on Rust!
Repository: flutter
Issue: Add keyline to Material Scaffold
Labels: c: new feature,framework,f: material design,a: quality,c: proposal,P3,team-design,triaged-design

The spacing methods in material spec appear to intentionally be open to the designers interpretation. In particular, Material offers *keylines* for adjusting spacing for child widgets, as described at the bottom of the [Spacing section](https://material.io/design/layout/spacing-methods.html#spacing) and illustrated in the animation below:

![mio-staging-mio-design-1584058305895-assets-18jQtl1D15-nyc5FlL-mEcaMLLYJHZRog-custom-keylines](https://user-images.githubusercontent.com/666539/78453888-9791aa80-7662-11ea-85c6-a0c05b798a37.gif)

This was originally discussed in #4460 and reemerged in #21026 as part of a discussion about padding. 

/cc @lukepighetti
Repository: rust
Issue: Missing write coalescing
Labels: A-LLVM,C-enhancement,A-codegen,T-compiler

Function `make_constant()` writes a constant to `S`. Optimally it would be a single 16-byte write to memory, but in fact it generates four separate writes. Function `make()` writes a nonconstant and a constant. Ideally it would generate two writes (one nonconstant, one constant), or perhaps an OR followed by a single write. Instead, it also generates four writes.

```asm
playground::make:
	movq	%rdi, %rax
	movq	%rsi, (%rdi)
	movb	$1, 8(%rdi)
	movl	$0, 9(%rdi)
	movl	$0, 12(%rdi)
	retq

playground::make_constant:
	movq	%rdi, %rax
	movq	$5, (%rdi)
	movb	$1, 8(%rdi)
	movl	$0, 9(%rdi)
	movl	$0, 12(%rdi)
	retq
```

```rust
pub struct S(u64, bool, [u8; 7]);

pub fn make(x: u64) -> S {
    S(x, true, [0; 7])
}

pub fn make_constant() -> S {
    S(5, true, [0; 7])
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=66237b264939df6f7670b6398c60fdd1))
Repository: tensorflow
Issue: Named Dimensions
Labels: stat:awaiting tensorflower,type:feature,comp:ops

**System information**

- TensorFlow version (you are using): 2.1
- Are you willing to contribute it (Yes/No): No

**Describe the feature and the current behavior/state.**

Currently, TensorFlow ops receive axes as integer indices, e.g. `tf.reduce_sum(tensor, axis=(2, 3))`. Keep track of axes after applying several operations on them and passing tensors around through multiple functions can be challenging.

I've seen many researchers and developers grab a sheet of paper and manually work through how axes should change. We can avoid this slow and often frustrating process by supporting optional axes names for tensors and having the most common ops annotate their outputs:

```python
image = tf.name_axes(image, ('B', 'H', 'W', 'C'))  # assert len(image.shape) == 4
print(image)  # <tf.Tensor dtype=uint8 shape={B: 500, H: 64, W: 64, C: 3}>

grid = tf.repeat(tf.repeat(image, 4, axis='H'), 4, axis='W')
print(grid)  # <tf.Tensor dtype=uint8 shape={B: 500, H: 256, W: 256, C: 3}>

gray = tf.reduce_mean(grid, axis='C')
print(gray)  # <tf.Tensor dtype=uint8 shape={B: 500, H: 256, W: 256}>

flipped = tf.transpose(gray[0], ('W', 'H'))
print(flipped)  # <tf.Tensor dtype=uint8 shape={W: 256, H: 256}>
```

A function starting with the line `tf.name_axes(...)` for its input tensors will immediately be easier to read. Moreover, developers could place `assert tensor.shape.names == ('B', 'F')` statements throughout their code so it becomes immediately clear from the written code how shapes are changing.

An advanced version of named axes would be to keep track of combined axes:

<details>

```python
video = tf.name_axes(image, ('B', 'T', 'H', 'W', 'C'))
print(video)  # <tf.Tensor dtype=uint8 shape={B: 500, T: 100, H: 64, W: 64, C: 3}>

frames = tf.reshape(frames, ('B*T', 'H', 'W', C'))
print(frames)  # <tf.Tensor dtype=uint8 shape={B*T: 50000, H: 64, W: 64, C: 3}>

logits = model(frames)
print(logits)  # <tf.Tensor dtype=float32 shape={B*T: 50000, 10}>

logits = tf.reshape(logits, ('B', 'T', 10))
print(logits)  # <tf.Tensor dtype=float32 shape={B: 500, T: 100, 10}>

logits = tf.name_axes(logits, ('B, 'T', 'K'))
print(logits)  # <tf.Tensor dtype=float32 shape={B: 500, T: 100, K: 10}>
```

</details>

**Will this change the current api? How?**

This would extend the current API in a fully backward compatible way. Common low-level TensorFlow operations (e.g. reduce_sum, concat, slice, tile) have to check for input tensors with named axes to annotate their outputs correctly.

**Who will benefit with this feature?**

Named axes have the potential to increase productivity of both researchers and engineers. Especially when developing large TensorFlow applications, named axes can help keep the overview. For product development with multiple developers, it can increase readability.

**Any Other info.**

JAX supports axes names. PyTorch 1.3 added experimental support for [named dimensions](https://pytorch.org/docs/stable/named_tensor.html).
Repository: java-design-patterns
Issue: Rule engine design pattern 
Labels: info: help wanted,epic: pattern,type: feature

**Description:**
The Rules design pattern is a behavioral design pattern that enables the encapsulation of business rules into isolated, reusable units. This pattern allows for the dynamic application of business logic at runtime and promotes the separation of concerns, making the system more modular and easier to maintain.

**Main Elements of the Pattern:**
1. **Rule Interface**: Defines the contract for all rules, typically including a method to evaluate the rule and another to execute the rule's action.
2. **Concrete Rules**: Implementations of the Rule interface, each encapsulating a specific piece of business logic.
3. **Rule Engine**: Responsible for managing and executing rules. It evaluates which rules should be applied based on the given context and executes them accordingly.
4. **Context**: The data or state that the rules operate on. This is passed to the rule engine and rules during execution.

**References:**
- [Rules Design Pattern by Michael Whelan](https://www.michael-whelan.net/rules-design-pattern/)
- [Project Contribution Guidelines](https://github.com/iluwatar/java-design-patterns/wiki)

**Acceptance Criteria:**
1. Create a Rule interface with methods to evaluate and execute a rule.
2. Implement at least three concrete rule classes demonstrating different business logic scenarios.
3. Develop a RuleEngine class capable of evaluating and executing a set of rules against a provided context.
4. Include unit tests for the RuleEngine and the concrete rule classes to ensure correctness and robustness.
Repository: flutter
Issue: "Welcome to Flutter" and "Waiting for lock" messages break --machine commands
Labels: tool,P2,team-tool,triaged-tool

`sudo flutter channel --version --machine` is responding with a non json output, this break other toolkit/ci-cd that are relying on this `--machine` flag https://github.com/go-flutter-desktop/go-flutter/issues/384.   
```sh
$ sudo flutter channel --version --machine     
Woah! You appear to be trying to run flutter as root.
   We strongly recommend running the flutter tool without superuser privileges.
  /
📎
{
  "frameworkVersion": "1.16.4-pre.88",
  "channel": "master",
  "repositoryUrl": "https://github.com/flutter/flutter.git",
  "frameworkRevision": "ab14307e0c77e4a03ea23ccaa68436d9128a445d",
  "frameworkCommitDate": "2020-04-03 00:56:01 -0400",
  "engineRevision": "f5127cc07a762de774b7e941fe6eb402c97aa1b3",
  "dartSdkVersion": "2.8.0 (build 2.8.0-dev.19.0 fae35fca47)"
}

  ╔════════════════════════════════════════════════════════════════════════════╗
  ║                 Welcome to Flutter! - https://flutter.dev                  ║
  ║                                                                            ║
  ║ The Flutter tool uses Google Analytics to anonymously report feature usage ║
  ║ statistics and basic crash reports. This data is used to help improve      ║
  ║ Flutter tools over time.                                                   ║
  ║                                                                            ║
  ║ Flutter tool analytics are not sent on the very first run. To disable      ║
  ║ reporting, type 'flutter config --no-analytics'. To display the current    ║
  ║ setting, type 'flutter config'. If you opt out of analytics, an opt-out    ║
  ║ event will be sent, and then no further information will be sent by the    ║
  ║ Flutter tool.                                                              ║
  ║                                                                            ║
  ║ By downloading the Flutter SDK, you agree to the Google Terms of Service.  ║
  ║ Note: The Google Privacy Policy describes how data is handled in this      ║
  ║ service.                                                                   ║
  ║                                                                            ║
  ║ Moreover, Flutter includes the Dart SDK, which may send usage metrics and  ║
  ║ crash reports to Google.                                                   ║
  ║                                                                            ║
  ║ Read about data we send with crash reports:                                ║
  ║ https://flutter.dev/docs/reference/crash-reporting                         ║
  ║                                                                            ║
  ║ See Google's privacy policy:                                               ║
  ║ https://policies.google.com/privacy                                        ║
  ╚════════════════════════════════════════════════════════════════════════════╝
```
Repository: rust
Issue: Compiler error references non-existent/undefined lifetimes?
Labels: A-diagnostics,A-lifetimes,A-closures,T-compiler,C-bug,D-confusing

I'm trying to box the `impl Future` returned from an `async fn`; to that end, I tried wrapping it in a closure that does the boxing:

```rust
    let _clousre = |r: &Request<'_>| Box::new(index_get(r));
```

(`index_get` is an `async fn`.)

I expected to see this happen: Well, I had hoped it would compile! I do not know if it should, however.

Instead, this happened:

```
error: lifetime may not live long enough
  --> src/main.rs:19:38
   |
19 |     let _clousre = |r: &Request<'_>| Box::new(index_get(r));
   |                        -           - ^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
   |                        |           |
   |                        |           return type of closure is std::boxed::Box<impl std::future::Future>
   |                        let's call the lifetime of this reference `'1`

error: lifetime may not live long enough
  --> src/main.rs:19:38
   |
19 |     let _clousre = |r: &Request<'_>| Box::new(index_get(r));
   |                                 -- - ^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'3` must outlive `'4`
   |                                 |  |
   |                                 |  return type of closure is std::boxed::Box<impl std::future::Future>
   |                                 let's call this `'3`
```

Here, the error message references lifetimes `'1` and `'2`; it defines `'1`, **but what is `'2`?**

(It also repeats the message twice, which seems odd.)

`rustc --version --verbose`:
```
» rustc --version --verbose
rustc 1.40.0 (73528e339 2019-12-16)
binary: rustc
commit-hash: 73528e339aae0f17a15ffa49a8ac608f50c6cf14
commit-date: 2019-12-16
host: x86_64-unknown-linux-gnu
release: 1.40.0
LLVM version: 9.0
```

While this isn't the latest stable, I can also replicate this in the playground, using both nightly and stable there. [Playground Example](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=098996eb7fdd4e8850986f59e7cd9b7a)
Repository: TypeScript
Issue: Use a data object instead of function closures for oldPrograms
Labels: Suggestion,In Discussion

## Search Terms

structured clone algorithm, oldProgram, function closure

## Suggestion

Create some transformer that transforms a `Program` to an `OldProgram`, which, instead of using function closures, would store the data, necessary  for "rehydrating" a program, directly on the `OldProgram` object.
The `createProgram` function would then take a `Program|OldProgram` as the parameter for `oldProgram`.
The `OldProgram` object should be compatible with the [structured clone algorithm](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm), which would involve creating similar "serialized++" versions of all of the transitive objects contained in the data of `OldProgram`

## Use Cases & Motivation

When caching a `Program` for use in a later compiler step, it contains many functions not consumed when taking in an `oldProgram`, these functions are needlessly holding variables in their closure/memory.
By trimming the methods down to only those used, the memory footprint is reduced, but they still have a memory cost of about 15MB for most of our projects (this number calcuated by observing ~2300MB freed after deleting 150 Programs from a cache). In our case this becomes ~22GB for all our projects. It would be nice to create a more lightweight version of these that can still be efficiently rehydrated for quick compiler actions.
This could also allow users in a specific use case to trim down the data more than is prudent to allow them to cache all of the Programs.
As an added bonus, if the `OldProgram` type could be made compatible with the structured clone algorithm, then it would be much easier to share a single, much larger, cache between a dozen-or-so compiler hosts.

As noted in #37701, compile times are slow when not able to reuse an oldProgram, this is aimed at helping users to be able to reuse an oldProgram more often.