sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Additional register with same const behaviour 
Labels: I-slow,T-compiler,C-bug

In `rustc 1.44.1 (c7087fe00 2020-06-17)` and `linux x86_64`. When use a struct use additional useless register. An example is a simple copy bytes. Without structure https://github.com/botika/buf-min/blob/3ad9833bee4f748f2089ad39fcf9047f9a39b064/benches/src/main.rs#L74-L108 . 
```asm
benches::raw_dyn:
 push    rbx
 sub     rsp, 32
 mov     rbx, rdi
; ...
```
Only push `rbx` register.
While with the structure and exactly the same behavior: https://github.com/botika/buf-min/blob/3ad9833bee4f748f2089ad39fcf9047f9a39b064/benches/src/main.rs#L110-L156
```asm
benches::ibuffer:
 push    r14
 push    rbx
 sub     rsp, 40
 mov     rbx, rdi
 mov     r14d, 12
; ...
```
 An `r14d` I have a constant length, of `"Hello World!"`. 
~~Therefore, the optimization does not work correctly when using a structure.~~
Edit: Sorry my English is not very advanced, the translator's fault. The optimizer does not behave the same in the case of a structure.
Repository: PowerToys
Issue: Add support for .emf in File Explorer Preview 
Labels: Idea-New PowerToy,Product-File Explorer

Please add the feature :
.emf preview
PLEASE!!!
Repository: go
Issue: x/tools/present: unexpected eof on slide header only
Labels: NeedsInvestigation,Tools

<!--
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
go version go1.14.4 darwin/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>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tz70s/Library/Caches/go-build"
GOENV="/Users/tz70s/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tz70s/WorkSpace/golang/golang"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f9/zc8k9cr145557jz3bqwmsz880000gn/T/go-build573678616=/tmp/go-build -gno-record-gcc-switches -fno-common"
</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.
-->
The present tool assume an implicit behavior that the header & the content (next slide page) should exist simultaneously.

E.g. if we have such slide file:
```
# Go present tool
Present tool reproducer
Tags: go, tool

Tzu-Chiao Yeh
5 Jul 2020
su3g4284zo6y7@gmail.com
```
instead of
```
# Go present tool
Present tool reproducer
Tags: go, tool

Tzu-Chiao Yeh
5 Jul 2020
su3g4284zo6y7@gmail.com

## Slide page
```

We'll get an 'unexpected eof' error.

### What did you expect to see?

This error message can lead user confusing:
* Actually legacy syntax will have the same issue as well.
* Ideally the "header-only" behavior is acceptable due to usually we start to write the first slide.
* Document somewhere (sorry if I missed it) and provide better error message would be helpful if this behavior is not acceptable.

### What did you see instead?

'unexpected eof' error

Actually this issue can be divided into two scenarios:

* Provided header but no author and no sections.
* Provided header and author but no sections.

I think a simple improvement is just skip sections when we reach eof on header or author?
Repository: go
Issue: net/smtp: add Client.TLSConfig field and Client.SendMail method
Labels: Proposal,Proposal-Accepted

`smtp.SendMail` actually does a great job, but the fact that it always uses `smtp.Dial` make it less flexible both for testing and for certain cases like ours, where we wanted to customize the `Client.localName`

In fact, in certain operations, `Client.localName` must correspond to the FQDN hostname sending the email (always `localhost` in the current implementation), this lack of flexibility led us to duplicate the entire SendMail (and tests) code just to address this issue.

I propose that we add a new public method `smtp.SendMailWithDialer` or `smtp.SendMailWithDialerFunc` and a new type `Dialer`/`DialerFunc`

```go
type Dialer func() (*Client, error) // or DialerFunc ?

func SendMailWithDialer(dial Dialer, a Auth, from string, to []string, msg []byte) error
```

The change set required is very minimal and backward compatible, `smtp.SendMail` could use `smtp.SendMailWithDialer` just by passing `smtp.Dial` as the dialer:

```go
func makeDialer(addr string) func() (*Client, error) {
	return func() (*Client, error) {
		return Dial(addr)
	}
}
func SendMail(addr string, a Auth, from string, to []string, msg []byte) error {
	return SendMailWithDialer(makeDialer(addr), a, from, to, msg)
}
```

This would allow for much more control both for testing and real uses cases with minimum code, for example:

```go
func myDialer() (*smtp.Client, error) {
	cl, err := Dial("remoteSmtp:25")
	if err != nil { return nil, err }
	if err := cl.Hello("my_FQDN") {
 		return nil, err
	}
	return cl, nil
}

smtp.SendMailWithDialer(myDialer, auth, from, to, msg)
```

I am willing to make a CL if it is accepted

Edit:
- At first the proposal was about adding `SendMailWithClient`, but it turned out that [line validation](https://github.com/golang/go/blob/master/src/net/smtp/smtp.go#L320) would be duplicate both in `SendMailWithClient` and `SendMail` as the validation must occur before the dial 

- The proposal included a proposal to make `config.localName` public, but since `Client.Hello` exists and SendMail uses `Client.hello` internally which does nothing if a Hello was called before this change is no longer required as the Dialer function could call `Hello` before passing to `SendMailWithDialer`
Repository: pytorch
Issue: [FR] NCCL and bool type
Labels: triaged,module: nccl,small,module: data parallel

NCCL should support `bool`. Currently if you use a `bool` buffer in your module then DataParallel complains since
https://github.com/pytorch/pytorch/blob/5b194b0fb21e4cb1ef0357b3315e311db4432338/torch/csrc/cuda/nccl.cpp#L95
gets triggered in replicate.

We should just map `bool` to `ncclChar` too.
Repository: javascript
Issue: Configuration of react/jsx-no-bind allows to use arrow functions, while the style guide prohibits it
Labels: question,react

The current configuration of `react/jsx-no-bind` allows to use arrow functions as event handlers (and ignores the use of bind in DOM components too): https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/rules/react.js#L104

![image](https://user-images.githubusercontent.com/443346/86509126-6609b600-bdee-11ea-8d7c-6a4106987078.png)

However, here's what the style guide has to say bout this:

---

![image](https://user-images.githubusercontent.com/443346/86508964-e16a6800-bdec-11ea-8979-44eb5ef15ddd.png)

---

1. I agree with the guide's argument and belive that it would be best to update the rule configuration to match it. Using arrow function to initialize an event handler creates a brand new function on each render same as `bind()` does, which can lead to unnecessary re-renders.

2. To be honest, I'd even turn `ignoreDOMComponents` to `false` too — it is unclear why DOM components deserve a different treatment. I'd say the reasoning from the style guide fully applies to them too.

3. If, however, there is some reasoning behind these exceptions — then the style guide should probably reflect it.
Repository: java-design-patterns
Issue: Functional core, imperative shell pattern
Labels: info: help wanted,epic: pattern,type: feature

## Description
The Functional Core Imperative Shell (FCIS) design pattern aims to segregate the purely functional part of the code (Functional Core) from the side-effect-laden part (Imperative Shell). This separation enhances testability, maintainability, and robustness by isolating side effects and minimizing their scope.

### Main Elements of the Pattern:
1. **Functional Core**:
   - Pure functions without side effects.
   - Deterministic outputs based on inputs.
   - Contains the business logic of the application.
   - Facilitates easy unit testing.

2. **Imperative Shell**:
   - Encapsulates side effects such as I/O operations, database access, and API calls.
   - Interfaces with the outside world.
   - Manages state changes and interactions.
   - Bridges the Functional Core with the real-world environment.

### Implementation Steps:
1. Identify and extract the business logic into pure functions.
2. Encapsulate side-effect operations within dedicated modules.
3. Define clear interfaces between the Functional Core and Imperative Shell.
4. Write unit tests for the Functional Core functions.
5. Ensure integration tests cover interactions within the Imperative Shell.

## References
- [Functional Core, Imperative Shell - Gary Bernhardt](https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell)
- [Building Modern Architectures: Functional Core, Imperative Shell - Albert Llousas](https://medium.com/@albert.llousas/building-modern-architectures-functional-core-imperative-shell-revamp-0bb5ae62b589)
- [Functional Core Imperative Shell - Kenneth Lange](https://kennethlange.com/functional-core-imperative-shell/)
- [A Look at the Functional Core and Imperative Shell Pattern - SSENSE Tech](https://medium.com/ssense-tech/a-look-at-the-functional-core-and-imperative-shell-pattern-be2498da153a)

## Acceptance Criteria
1. The project codebase should have a clear separation between the Functional Core and the Imperative Shell.
2. All business logic should reside in pure functions within the Functional Core, with appropriate unit tests.
3. All side-effect operations should be encapsulated in the Imperative Shell, with integration tests to ensure correct interactions.
Repository: rust
Issue: Missing warning about `target_feature` when using for `core::arch::x86_64` functions
Labels: A-lints,T-compiler,C-feature-request

I tried this code: https://rust.godbolt.org/z/b9A7oP
```rust
extern crate core;

use core::arch::x86_64::__m128;
use core::arch::x86_64::_mm_extract_ps;
use core::arch::x86_64::_mm_hadd_ps;

pub unsafe fn add_reduce(a: __m128, b: __m128) -> f32 {
    let c = _mm_hadd_ps(a, b);
    f32::from_bits(_mm_extract_ps(c, 0) as u32)
}
```

I expect to see this happens: rustc lint about missing `target_feature` in `add_reduce` when using `_mm_extract_ps`.

Instead this happen: There is no warning and functions are not inlined.

### Meta

* rustc 1.46.0-nightly (3503f565e 2020-07-02) x86_64-unknown-linux-gnu
Repository: tensorflow
Issue: Zero AUROC when validation set is only comprised of positive labels
Labels: stat:awaiting tensorflower,type:bug,comp:keras,TF 2.11

**System information**
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Tested on Ubuntu 18.04 and MacOS Catalina 10.15.5
- TensorFlow installed from (source or binary): installed from Conda (tensorflow-gpu) on Ubuntu and from pip on MacOS
- TensorFlow version (use command below): v2.2.0-rc4-8-g2b96f3662b 2.2.0
- Python version: 3.7.6 (on both machines)
- CUDA/cuDNN version: 11.0 (on Ubuntu machine)
- GPU model and memory: 4 NVIDIA V100 GPUs

**Describe the current behavior**
The AUROC is zero when there are no negatives in the validation set. This may lead users to believe that the model is not performing correctly, while it is just an error related to a misuse of the AUROC metric.

**Describe the expected behavior**
The AUROC should be NaN when no negatives are present in the validation set. This way the user is aware that there is something wrong with the metric that is being used, with the possibility to add a warning since there is a 0/0 somewhere in the computation of the AUROC.

**Standalone code to reproduce the issue**
```python
from tensorflow.keras.metrics import AUC
metric = AUC()
metric.update_state([1, 1, 1], [1, 0.5, 0.3])
metric.result()
```

I believe that similar issues also happen for other metrics, as uncanny values were displayed also for Recall and Precision, but I have not identified a simple reproducible example.
Repository: rust
Issue: Better error for import of associated items
Labels: C-enhancement,A-diagnostics,A-associated-items,T-compiler

Hi.  I was using a crate which had a struct with a number of associated items and I was trying to save typing in an error handling function.  But:

```rust
12 |     use rocket::http::Status::*;
   |                       ^^^^^^ `Status` is a struct, not a module
```

I looked in the Reference and I wasn't able to find any discussion of this.  In particular, I would expect it to be documented in the explanation of _Use declarations_ under _Items_.

After considerably more digging, I found:
 * #24915, a closed issue where the resolution was that this is not expected to work
 * https://internals.rust-lang.org/t/importing-associated-constants/6610/5, a discussion about how to maybe implement this (although it seems unlikely that that approach could work for the glob import I was trying...)

It seems that this situation is likely to persist.  Maybe the error message could be improved?  Something like

> hint: importing associated items is not supported; you must use a path from to the parent type each time

could help the user by letting them know they can't avoid the extra typing.

I will also file an issue against the Reference.  Thanks for your attention.
Repository: go
Issue: cmd/compile: reclaim binary size increase from CL 35554 constant to interface allocation optimizations
Labels: Performance,NeedsInvestigation,compiler/runtime

In [CL 35554](https://go-review.googlesource.com/c/go/+/35554/) for #18704, @josharian added some very nice allocation optimizations, as part of his efforts to claw back some of the allocation penalty of #8405, but a result was a modest increase in binary size.

In CL 35554, @josharian mentioned that the ~0.5% binary size increase could likely be recovered in the future, and there was some discussion of adding a tracking issue for that.

I did a quick look for that follow-up tracking issue a couple years ago, and again searched just now, but both times haven't found it.

Posting this new issue now in case it is helpful to either:
1. serve as the tracking issue for that possible future work, or 
2. if that is already tracked (or even completed!), help a future gopher more easily follow the issue trail through cross linking ;-)

Here is a snippet from CL 35554:

> This CL adds ~0.5% to binary size, despite
> decreasing the size of many functions,
> because it also adds many static symbols.
> 
> This binary size regression could be recovered in
> future (but currently unplanned) work.
> 
> There is a lot of content-duplication in these
> symbols; this statement generates six new symbols,
> three containing an int 1 and three containing
> a pointer to the string "a":
> 
> fmt.Println(1, 1, 1, "a", "a", "a")
> 
> These symbols could be made content-addressable.
> 
> Furthermore, these symbols are small, so the
> alignment and naming overhead is large.
> As with the go.strings section, these symbols
> could be hidden and have their alignment reduced.

Another reason for posting now is that there is some recent renewed energy around binary size (#6853).

Sorry if I missed something obvious. @josharian or anyone else, feel free to close if this is already addressed or tracked elsewhere.
Repository: vscode
Issue: "Add Selection To Previous Find Match" interferes with "Add Selection To Next Find Match"
Labels: feature-request,editor-commands

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version:1.46.1
- OS Version:2004 Build 19041.329

Steps to Reproduce:

1. Add Selection To Next Find Match [Ctrl+D]
2. Now say you also want to expand the selection upwards --> Add Selection To Previous Find Match
3. Nothing happens. 

Expected Behavior:

The two commands should complement each other, so for example when you start in the middle of a function and quickly want to edit a specific word you can quickly expand the selection towards both the top and the bottom. Currently the two commands in conjunction are absolutely useless, and instead will only be useful if you solely want to expand the selection upwards OR downwards. Fixing this issue would make these commands in either case useful.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: rust
Issue: std::line macro can be wrong in 1.44.1 stable under proc-macros
Labels: E-needs-test,A-macros,T-compiler,C-bug,E-needs-mcve,A-proc-macros

Hi,
This issue seems to be solved on nightly but I couldn't find an explicit change in that code, so if this issue isn't helpful feel free to close.

I have a proc-macro that generates loggings, and on one occurrence it gets the line number wrong on stable but right on nightly: 
 The test: https://github.com/elichai/log-derive/blob/2020-test-logger/tests/first.rs#L121
Fails on stable: https://travis-ci.com/github/elichai/log-derive/jobs/357565126#L305
Passes on nightly: https://travis-ci.com/github/elichai/log-derive/jobs/357565129#L314

Using `cargo-bisect-rustc`I found that the bug was fixed in https://github.com/rust-lang/rust/commit/a9ca1ec9280ca1e5020edd699917c3367a30a798 (https://pastebin.com/raw/0rwkWwZU) but I don't see anything related there

If this is helpful I can try and create a minimal reproducible code, but because it's fixed in nightly I'm not sure if it's worth the time
Repository: node
Issue: stream: Readable batched iteration
Labels: stream

This is a continuation of https://github.com/nodejs/node/pull/34035 and the promises session we had on OpenJS about async iteration performance of streams. One alternative discussed was to batch reading.

I was thinking we could do something along the lines of:

```js
async function* createBatchedAsyncIterator(stream, batchLen) {
  let callback = nop;

  function next(resolve) {
    if (this === stream) {
      callback();
      callback = nop;
    } else {
      callback = resolve;
    }
  }

  stream
    .on('readable', next)
    .on('error', next)
    .on('end', next)
    .on('close', next);

  try {
    const state = stream._readableState;
    while (true) {
      let buffer;
      while (true) {
        const chunk = stream.read();
        if (chunk === null) break;
        if (!buffer) buffer = [];
        buffer.push(chunk);
        if (batchLen && buffer.length >= batchLen) break;
      }
      if (buffer) {
        yield buffer;
      } else if (state.errored) {
        throw state.errored;
      } else if (state.ended) {
        break;
      } else if (state.closed) {
        // TODO(ronag): ERR_PREMATURE_CLOSE?
        break;
      } else {
        await new Promise(next);
      }
    }
  } catch (err) {
    destroyImpl.destroyer(stream, err);
    throw err;
  } finally {
    destroyImpl.destroyer(stream, null);
  }
}

Readable.batched = function (stream, batchLen) {
  return createBatchedAsyncIterator(stream, batchLen);
}
```

Which would make the following possible:

```js
// Concurrency
for await (const requests of Readable.batched(stream, 128)) {
  // Process in parallel with concurrency limit of 128.
  await Promise.all(requests.map(dispatch))
}

// Speed
for await (const requests of Readable.batched(stream, 128)) {
  for (const request of requests) {
    // All in the same tick
  }
}
```

It's still not perfect since if one element takes very long it would reduce concurrency. However, it would still be a step forward. Also reducing the async iteration overhead.
Repository: godot
Issue: GDScript: get_property_default_value always returns Null
Labels: bug,topic:gdscript,confirmed

<!-- 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.2 stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows

**Issue description:**
<!-- What happened, and what was expected. -->
return the property default value, getting `Null` instead

**Steps to reproduce:**
```gdscript
var a = 1
func _ready():
    print (get_script().get_property_default_value("a"))
```

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
not required
Repository: go
Issue: cmd/cgo: add #cgo CFLAGS and #CGO CXXFLAGS directives that only apply to files in the current package
Labels: NeedsInvestigation,FeatureRequest,compiler/runtime

My situation is that instead of distributing static libraries, I have the C++ and C sources of the C package I'm wrapping stored in the same directory as my Go files, so that the package can in theory can be compiled on any C compiler.
In order to improve performance, I added a build tag which added the -flto flag, in order to enable link-time-optimization between all the C++ files.
However, I got an error when I added this line:
#CGO CFLAGS: -flto
to the file which implements LTO.
cannot load DWARF output from $WORK\b002\\_cgo_.o: decoding dwarf section info a
t offset 0x0: too short
So I'd like a way to apply CFLAGS and CXXFLAGS to only the C and C++ files that are actually part of the package, and not CGO generated C files.
Repository: rust
Issue: Bad suggestion `dyn pub` on proc macro (#61963 regressed)
Labels: A-diagnostics,P-medium,A-macros,T-compiler,regression-from-stable-to-stable,C-bug,A-suggestion-diagnostics,D-invalid-suggestion,A-proc-macros

#72306 causes the compiler to emit (and blessed) this bad suggestion in the [test](https://github.com/rust-lang/rust/blob/0cd7ff7ddfb75a38dca81ad3e76b1e984129e939/src/test/ui/suggestions/issue-61963.rs) for #61963 ([output](https://github.com/rust-lang/rust/blob/0cd7ff7ddfb75a38dca81ad3e76b1e984129e939/src/test/ui/suggestions/issue-61963.stderr)):

```
error: trait objects without an explicit `dyn` are deprecated
  --> $DIR/issue-61963.rs:18:1
   |
LL | pub struct Foo {
   | ^^^ help: use `dyn`: `dyn pub`
```

This is the behaviour the test is supposed to guard against (almost - the original bad suggestion was to insert `dyn` before the proc macro attribute), so the issue is regressed.

The issue was originally fixed nearly a year ago, so this is a regression from stable.