sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: In JS, module.exports assignment doesn't make types available
Labels: Bug,Domain: JavaScript

**Code**

```js
// in a javascript file mod1.js:
class C {
    prop = 0;
}

module.exports = { C }
```

```ts
// in a typescript file test.ts
declare var yyy: import("./mod1").C
```

**Expected behavior:**
No error, and `yyy: C`

**Actual behavior:**
Error, namespace '"src/test/mod1".export=' has no exported member 'C'.

module.exports-assigned object literals should be marked with SymbolFlags.Namespace, or perhaps getTypeFromImportTypeNode needs to know about non-namespace containers. It probably also needs to check members instead of exports, since that's where object literals store their members.
Repository: node
Issue: Add testcases for all documented safeguards
Labels: help wanted,test,security

_To clarify: I am not blaming anyone. I view this as a problem of the process that we used, the aim of this issue is to seek how we can actually improve things. I myself LGTMd the change that introduced the initial safeguard without a testcase._

This is a post-mortem of https://github.com/nodejs-private/security/issues/202 (see 40a7beeddac9b9ec9ef5b49157daaf8470648b08).

That itself was a minor issue which is very unlikely to be exploitable (more unlikely than the second one fixed in the same release), but it revealed what I think is a process problem.

That issue was introduced in #18790 which removed the corresponding safeguard from the code while optimizing performance. The safeguard was initially introduced in #4682, and was documented in the code — that didn't save it from being removed:

> This prevents accidentally sending in a number that would be interpretted as a start offset.

My opinion is that a testcase should have been introduced at the same time when the comment was. Or, perhaps, even _instead_ of the comment — the comment turned out to be not effective.

So, the proposal is to:
1. Collect a list of similar comments in the codebase that warn against changing some code or explain why is it needed — that hints that the common usecase might work with that code removed, but doing so is expected to break some rare usecase or cause a potential security issue.
2. Try removing/modifying the safegaurds and see if any tests break, make a list of safeguards that do not break tests when are tampered with.
3. Add missing tests.
4. Update to try spotting such things (i.e. untested expectations) in the future while reviewing PRs. Should be fairly easy to spot things that were worth a comment in the code and to question _if those are tested_?

There might be none — but I would prefer if we re-checked that.

Side note: code coverage is not an effective measure to collect the data here or prevent the issue.

/cc @nodejs/security-wg
Repository: go
Issue: cmd/compile: understand Go vs assembly rc4 results
Labels: Performance,NeedsInvestigation,compiler/runtime

Tracking bug so somebody (@randall77?) looks into why we got totally opposite performance numbers on different Intel CPUs when we deleted the crypto/rc4 code's assembly in "favor" of the Go version in 30eda6715c6578de2086f03df36c4a8def838ec2 (https://golang.org/cl/130397):

```
name       old time/op   new time/op   delta
RC4_128-4    256ns ± 0%    196ns ± 0%  -23.78%  (p=0.029 n=4+4)
RC4_1K-4    2.38µs ± 0%   1.54µs ± 0%  -35.22%  (p=0.029 n=4+4)
RC4_8K-4    19.4µs ± 1%   12.0µs ± 0%  -38.35%  (p=0.029 n=4+4)

name       old speed     new speed     delta
RC4_128-4  498MB/s ± 0%  654MB/s ± 0%  +31.12%  (p=0.029 n=4+4)
RC4_1K-4   431MB/s ± 0%  665MB/s ± 0%  +54.34%  (p=0.029 n=4+4)
RC4_8K-4   418MB/s ± 1%  677MB/s ± 0%  +62.18%  (p=0.029 n=4+4)

vendor_id	: GenuineIntel
cpu family	: 6
model		: 142
model name	: Intel(R) Core(TM) i5-7Y54 CPU @ 1.20GHz
stepping	: 9
microcode	: 0x84
cpu MHz		: 800.036
cache size	: 4096 KB

name       old time/op   new time/op   delta
RC4_128-4    235ns ± 1%    431ns ± 0%  +83.00%  (p=0.000 n=10+10)
RC4_1K-4    1.74µs ± 0%   3.41µs ± 0%  +96.74%  (p=0.000 n=10+10)
RC4_8K-4    13.6µs ± 1%   26.8µs ± 0%  +97.58%   (p=0.000 n=10+9)

name       old speed     new speed     delta
RC4_128-4  543MB/s ± 0%  297MB/s ± 1%  -45.29%  (p=0.000 n=10+10)
RC4_1K-4   590MB/s ± 0%  300MB/s ± 0%  -49.16%  (p=0.000 n=10+10)
RC4_8K-4   596MB/s ± 1%  302MB/s ± 0%  -49.39%   (p=0.000 n=10+9)

vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping        : 0
microcode       : 0x1
cpu MHz         : 2300.000
cache size      : 46080 KB
```

Super mysterious, so we might want to understand it enough to decide whether we care and whether there's something the compiler might do better for more CPUs.

Maybe the benchmarks or benchstat are wrong? But then that'd be its own interesting bug.

/cc @josharian @aead @FiloSottile
Repository: go
Issue: cmd/go: using go test, goroutine stack dump sometimes not emitted on SIGQUIT
Labels: NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?

Tried `go version go1.10.3 darwin/amd64`, `go version go1.11rc1 darwin/amd64`, and `go version devel +6e76aeba0b Thu Aug 23 20:27:47 2018 +0000 darwin/amd64`. 

### What did you do?

I had a test that appeared to be stuck in a blocking operation, and I pressed `^\` to send SIGQUIT, but I didn't receive any output. Then when I ran the test again using `go test -v`, sending SIGQUIT produced the goroutine stacks I expected to see.

Here's a sample test I'm using in the following output:

```go
package main

import (
	"testing"
	"time"
)

func TestSleep(t *testing.T) {
	time.Sleep(time.Minute)
}
```

Running just `go test .` doesn't produce output on SIGQUIT, but I do see output with `go test -v .`.

```
$ /usr/local/Cellar/go/1.10.3/bin/go test .
^\
$ /usr/local/Cellar/go/1.10.3/bin/go test -v .
=== RUN   TestSleep
^\SIGQUIT: quit
PC=0x105508b m=0 sigcode=0

goroutine 0 [idle]:
...
FAIL	_/tmp/b	2.084s

$ gotip test .
^\
$  gotip test -v .
=== RUN   TestSleep
^\SIGQUIT: quit
PC=0x7fff706a6a1e m=0 sigcode=0

goroutine 0 [idle]:
...
FAIL	_/tmp/b	1.859s
```

If I change the file to include a test that calls t.Log, then I seem to be able to get a stack dump with tip, but not with 1.10 or 1.11rc1:

```
$ cat sleep_test.go
package main

import (
	"testing"
	"time"
)

func TestPass(t *testing.T) {
	t.Logf("ok")
}

func TestSleep(t *testing.T) {
	time.Sleep(time.Minute)
}

$ /usr/local/Cellar/go/1.10.3/bin/go test  .
^\
$ go test  .
^\
$ gotip test  .
^\SIGQUIT: quit
PC=0x7fff706a6a1e m=0 sigcode=0

goroutine 0 [idle]:
...
FAIL	_/tmp/b	6.311s
```

If I comment out the t.Logf call, but keep `TestPass`, then gotip no longer produces a stack dump on SIGQUIT.
Repository: opencv
Issue: cvLoadImage on iOS
Labels: platform: ios/osx,incomplete


##### System information (version)
- OpenCV => 3.4.1
- Operating System / Platform =>Mac 10.13.4
- Compiler => Xcode


##### Detailed description

I would like to load a png image with `cvLoadImage`, it return nil unfortunately,  but a 'jpg' type is ok.

##### Steps to reproduce

```
NSString *phonePath =  [[NSBundle mainBundle] pathForResource:@"phone" ofType:@"png"];
IplImage *src = cvLoadImage([phonePath UTF8String]);//nil
```
Repository: rust
Issue: #[repr(u16)] enum doesn't pack fields as expected
Labels: A-type-system,A-codegen,T-compiler,C-bug,T-types,A-repr,A-enum

The following code:
```rust
#[repr(u16)] enum Foo { A, B(u32, u16) }
println!("{}", std::mem::size_of::<Foo>());
```
currently outputs 12, but `Foo` really only needs to take 8 bytes.

There are several alternatives which can correctly be packed into 8 bytes:
```rust
#[repr(u8)] enum Foo { A, B(u32, u16) }
```
```rust
#[repr(u16)] enum Foo { A, B(u16, u32) }
```

I see no reason why the first enum couldn't be packed into 8 bytes.
Repository: rust
Issue: Remove all definition names from the HIR.
Labels: C-cleanup,T-compiler

If it's in `tcx.def_key(def_id)` that's a better source of truth and available cross-crate.
Only reason I could see for keeping names is to point at their span
  * we could also keep that separately, even cross-crate
  * we might want something that captures the "name introduction form" span
    * e.g. the span of `fn name` or `const NAME`, not just the name
    * sometimes we use the span of an entire item and it looks pretty bad
    * we could also refer to things that way in human-facing printing
      * e.g. "`fn fmt` in `impl fmt::Debug for Foo`" instead of `<Foo as fmt::Debug>::foo`
      * or `(impl fmt::Debug for Foo)::fn foo`

cc @petrochenkov @michaelwoerister @nikomatsakis
Repository: material-ui
Issue: [Checkbox] Add checked animation
Labels: new feature,component: checkbox

The [Checkbox](https://material-ui.com/api/checkbox/) component is missing the animation for the icon when toggling it. This makes checking the checkbox look bit cluncky, especially when toggling it from the label.

In material design demo you can clearly see the icon animated when you toggle it: https://material-components.github.io/material-components-web-catalog/#/component/checkbox

Compare it to the current implementation in material-ui. See especially how it looks when toggling it by clicking the label. 
https://material-ui.com/components/checkboxes/

Even in v0 has some kind of animation, which in my opinion makes it look better than the current version https://v0.material-ui.com/#/components/checkbox

<!-- Checked checkbox should look like this: [x] -->
- [x] This is a v1.x issue. <!-- (v0.x is no longer maintained) -->
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

Edit: Updated outdated link
Repository: flutter
Issue: Animation lag when navigating to screen with `TextField` with `autoFocus` set to `true` on iOS
Labels: a: text input,framework,a: animation,c: performance,f: focus,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-framework,triaged-framework

This effects only `iOS`. tested on `iPhone 6` and `iPad (3rd gen)`

##Demo

[https://drive.google.com/file/d/1LPMdNMf6z6yYBCYM3JMegMx-SQw0vGUs/view?usp=sharing](https://drive.google.com/file/d/1LPMdNMf6z6yYBCYM3JMegMx-SQw0vGUs/view?usp=sharing)

## Steps to Reproduce

1. set `autoFocus = true` on first `TextField` in `text_form_field_demo.dart` of Flutter Gallery.
2. Run the gallery in release mode and navigate to Material -> Text Fields
3. observe the lag. 

if `autoFocus = true` is not set, then navigation animation is smooth. this seems to happen when the keyboard pops up.

```
[✓] Flutter (Channel dev, v0.5.8, on Mac OS X 10.13.2 17C88, locale en-IN)
    • Flutter version 0.5.8 at /Users/hari/development/flutter
    • Framework revision e4b989bf3d (2 weeks ago), 2018-08-09 09:45:44 -0700
    • Engine revision 3777931801
    • Dart version 2.0.0-dev.69.5.flutter-eab492385c

[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
    • Android SDK at /Users/hari/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-27, build-tools 27.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 9.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.4.1, Build version 9F2000
    • ios-deploy 1.9.2
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 27.1.1
    • Dart plugin version 173.4700
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

[✓] VS Code (version 1.26.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.17.1

[✓] Connected devices (1 available)
    • iPad • 4517c71cd57462f4d77e237e4ead89f44ce99fa1 • ios • iOS 10.3.3

• No issues found!
```
Repository: flutter
Issue: VideoPlayer plugin should make sure that resources are released when FlutterView is destroyed
Labels: c: performance,p: video_player,package,team-ecosystem,P3,triaged-ecosystem

This is related to https://github.com/flutter/flutter/issues/19206 and https://github.com/flutter/flutter/issues/19358.

`VideoPlayer` plugin on Android allocates a platform `MediaPlayer` object for each `VideoPlayer` plugin in the widget tree. `MediaPlayer` objects [are destroyed](https://github.com/flutter/plugins/blob/master/packages/video_player/android/src/main/java/io/flutter/plugins/videoplayer/VideoPlayerPlugin.java#L225) when corresponding Flutter widgets go away. But if a whole `FlutterView` is destroyed, `dispose` methods don't run, so `MediaPlayer` instances are not released. This leads to leaks and also crashes (since the player continues to provide frames for non-existent surfaces; internal bug: b/112692333).

IMO, `VideoPlayer` should rely on normal disposing for the final cleanup and just assert that by the time the view is destroyed all resources are released. This would rely on widgets disposal methods to be called, which is tracked in https://github.com/flutter/flutter/issues/19358.

As a workaround, `VideoPlayer` should subscribe with a `onViewDestroyListener` and explicitly release all resources when the owner `FlutterView` goes away.
Repository: TypeScript
Issue: Intellisense for generic parameterized string literal function arguments not working
Labels: Suggestion,Domain: Completion Lists,VS Code Tracked,Experience Enhancement

_From @njgraf512 on July 31, 2018 22:5_

<!-- 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.26.0-insider
- OS Version: MacOS 10.12.6

Steps to Reproduce:

1. Enter the following into a TS file:
```ts
const myObj =  {
  foo: 'Foo',
  bar: 'Bar',
}

function myFunc<T>(obj: T, key: keyof T) {
  return obj[key];
}

myFunc(myObj, 'f')
```
2. Observe that once you begin typing the `f` of string literal `foo` for the function's second argument, the tooltip switches from suggesting `"foo" | "bar"` to `never`:

**Good:**

![screen shot 2018-07-31 at 2 52 01 pm](https://user-images.githubusercontent.com/22208823/43489606-69b31acc-94d2-11e8-987c-98fe2ae25e46.png)

**Bad:**

![screen shot 2018-07-31 at 2 52 48 pm](https://user-images.githubusercontent.com/22208823/43489563-45f27470-94d2-11e8-932b-54736575d944.png)

3. Also, triggering intellisense with <kbd>control</kbd>+<kbd>space</kbd> does not suggest `foo` or `bar`:

![screen shot 2018-07-31 at 2 52 26 pm](https://user-images.githubusercontent.com/22208823/43489977-ac3d31ce-94d3-11e8-90e5-21c5e1c96aa2.png)



<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No
No

_Copied from original issue: Microsoft/vscode#55530_
Repository: rust
Issue: Fabricate hangs while building rust for raspbian on arm64 host.
Labels: O-Arm,O-AArch64

We do a lot of package builds for raspbian in a raspbian chroot in a debian armhf container on an arm64 host, we use this host because it's fast.

Unfortunately recent versions of rustc can no longer be built in this environment, a program called "fabricate" hangs with 200% CPU usage. IIRC this has been happening since 1.25, currently I am building 1.27 with 1.26 (I will try again with 1.28 once I have 1.27 built).

running: "/<<BUILDDIR>>/rustc-1.27.2+dfsg1/build/arm-unknown-linux-gnueabihf/stage0-tools-bin/fabricate" "generate" "--product-name=Rust-Documentation" "--rel-manifest-dir=rustlib" "--success-message=Rust-documentation-is-installed." "--image-dir" "/<<BUILDDIR>>/rustc-1.27.2+dfsg1/build/tmp/dist/rust-docs-1.27.2-arm-unknown-linux-gnueabihf-image" "--work-dir" "/<<BUILDDIR>>/rustc-1.27.2+dfsg1/build/tmp/dist" "--output-dir" "/<<BUILDDIR>>/rustc-1.27.2+dfsg1/build/dist" "--package-name=rust-docs-1.27.2-arm-unknown-linux-gnueabihf" "--component-name=rust-docs" "--legacy-manifest-dirs=rustlib,cargo" "--bulk-dirs=share/doc/rust/html"

(the <<BUILDDIR>> shown in the log is a substitution made by a build log filter, the actual command has the real paths in it).

Attempts to debug/workaround this issue on the box in question have failed, my only soloution so-far has been to do the rust builds on a different box (which works but is a pain with my workflow).

To help me debug I would appreciate answers to the following questions.

1. What is fabricate and where can I find documentation for it? googling for "rust fabricate" or even "rust language fabricate" has proved futile.
2. How can I run commands from the rust build process outside the build process (e.g. in a debugger),  in my experiance trying to re-run the commands shown by the build process inevitablly results in unrelated errors. Are there special environment variables in-play? if so how do I find out what those environment variables should be.
3. Is there a way to disable paralellism in fabricate?
Repository: go
Issue: net: clarify net.Conn concurrency requirement
Labels: Testing,Documentation,help wanted,NeedsInvestigation

From the net.Conn docs:

> Multiple goroutines may invoke methods on a Conn simultaneously.

I'm not sure if this should be interpreted as *different* methods can be called concurrently, or as the same method can be called concurrently.

I suspect, judging from x/net/nettest's ConcurrentMethods and from most implementations, that it's the former. If so, should we change the docs to include "may invoke *distinct* methods"?
Repository: svelte
Issue: Slotted content for Web Component nested inside of a Svelte component is not applied to the Web Component
Labels: awaiting submitter,custom element

Given a Web Component which expects slotted children, which itself is nested inside of a Svelte component, as in the following:

```
<SvelteComponent>
  <my-custom-element>
    <div slot="slot1">my-custom-element content</div>
    <div slot="slot2">more my-custom-element content</div>
  </my-custom-element>
</SvelteComponent>
```

...the slotted children are not applied to the Web Component.

I have reproduced the issue here (just run ```npm install``` and ```npm run build``` and then open ```dist/index.html``` in your browser):
https://github.com/therealnicksaunders/svelte/tree/issue/slotted-content

In a more complicated example, this actually produces an error which suggests that a slotted child is being applied to the Svelte component instead of the Web Component in which it is nested. We have this Svelte-generated code:

```
(0, _shared.append)(pagecontent._slotted.header, div);
```

The referenced div is nested inside of a Web Component; its "slot" attribute of "header" corresponds to a slot inside of that Web Component rather than the PageContent Svelte component (which has no named slots).

Hopefully I have provided enough info here... Please let me know if I can clarify anything.

Thanks in advance for your help looking into it!
Repository: go
Issue: cmd/go: -exec prevents test caching 
Labels: NeedsDecision

### What version of Go are you using (`go version`)?
go version go1.10.3 freebsd/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
freebsd/amd64

### What did you do?
go test -exec wrap1.sh ./...
go test -exec wrap1.sh ./..

### What did you expect to see?
tests should be cached on the second attempt

### What did you see instead?
full tests ran

The reason for this is the following line: https://github.com/golang/go/blob/master/src/cmd/go/internal/test/test.go#L1106
```golang
        execCmd := work.FindExecCmd()
	if !c.disableCache && len(execCmd) == 0 {
		testlogArg = []string{"-test.testlogfile=" + a.Objdir + "testlog.txt"}
	}
```

While the documented set of 'cacheable' test flags don't include -exec it seems like this should be supported.

While looking into this issue I also noticed this specific criteria is not mentioned when ```GODEBUG``` includes ```gocachetest=1``` so at the least is should be output e.g.
```golang
        execCmd := work.FindExecCmd()
        if len(execCmd) != 0 {
                fmt.Fprintf(os.Stderr, "testcache: caching disabled for cmd: %q\n", execCmd)
        } else if !c.disableCache {
                testlogArg = []string{"-test.testlogfile=" + a.Objdir + "testlog.txt"}
        }
```
With more investigation I also identified that tryCacheWithID actually includes work.ExecCmd in the calculation of the cache.ActionID.

I tried removing the execCmd check in builderRunTest and everything worked as expected, cached results are cached returned if the -exec parameter matches.
Repository: godot
Issue: Script "PRELOAD" allocated memory are not freed until editor restart... and sometimes not even with that.
Labels: bug,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->
Related issues at bottom....

**Godot version:**
<!-- Specify commit hash if non-official. -->
All

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
All

**Issue description:**
<!-- What happened, and what was expected. -->

If you do some "preloads" of packed scenes in the script editor, memory is inmediately allocated. If you delete them, memory is still allocated, no mathers if you save the script after deleting the preloads, or if you close all scenes and scripts... memory is not freed until editor restart....

But real problem here is: If you don´t delete that preloads and maintain that in any script, in any part of the project, no mathers if the script is singleton or not, opened or not......, in every session the memory is allways allocated, and it shouldn´t.


**Steps to reproduce:**
Preload any packed scene in any script and look at windows-task administrator. Open godot, close godot, maintain preloads and close-open, close-open scripts with and without, put preloads in autoloads, in other scripts, open editor with all script closed.... etc... etc... etc... not project related. Always look at task manager and see what happend with godot memory...

Related : 
https://github.com/godotengine/godot/issues/20529
https://github.com/godotengine/godot/issues/9815
Repository: godot
Issue: Node.set_display_folded(bool) has no effect
Labels: bug,confirmed,topic:plugin

**Godot version:**
3.0.5-stable_x11.64, Xubuntu

**Issue description:**
_Node.set_display_folded(bool)_ has no effect whatsoever.


**Example project:**
[Example project.zip](https://github.com/godotengine/godot/files/2320724/Example.project.zip)