sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Fuzz or matrix test the API server
Labels: area/test,priority/important-soon,sig/api-machinery,kind/feature,sig/testing,priority/important-longterm,lifecycle/frozen

We have seen a variety of problems where misconfiguration causes the `{kube-apiserver,kube-controller-manager}` to  `{crashloop,otherwise prevent repair of the problem}`.

Examples:

- webhook that won't let you do anything (including delete it) #59124 #56761
- apiservice without an endpoint, but the service can never get healthy because k-c-m won't come up #55271

There is a huge space of these problems, and while we have some specific cases, we would do well to try some intelligent fuzz testing to root out more.

If fuzz testing is too much work at first, sharing a single matrix-based test around misconfigurations would be a very, very good start.

cc @lavalamp @jennybuckley @cheftako 
/kind feature-request
/area testing
/sig api-machinery
/priority important-soon
Repository: flutter
Issue: Smooth checkbox value animation segues
Labels: framework,a: animation,f: material design,a: quality,P3,team-design,triaged-design

It would nice to have smooth segues for cases where a tristate checkbox's value changes in the middle of its animation cycle.

For example: currently if the value changes from true to null at t=0.75 we just abruptly start rendering a dash. This happens in 50ms so users who haven't slowed the animation speed are unlikely to notice. Instead of the abrupt change we could use the 50ms to animate the check away, per the existing animation, and animate the dash in.

Or cross-fade from the check to the dash.

See https://github.com/flutter/flutter/pull/14611
Repository: pytorch
Issue: [feature request] Stratified splits in random_split function
Labels: module: dataloader,triaged

It's probably less of an issue on "biggish" datasets, but a param for specifying stratification in `random_split` (which was merged here: #4435) would be nice. If the targets are class labels this could be done based on the integer labels. For regression problems, there are some interesting ideas posted here: http://scottclowe.com/2016-03-19-stratified-regression-partitions/

If this is of interest, we could discuss how to implement that efficiently, I am happy to help.

cc @SsnL @VitalyFedyunin
Repository: godot
Issue: Multiple Godot instances conflict with each other
Labels: bug,topic:core

**Godot version:**
3.0 stable

**OS/device including version:**
Any

**Issue description:**
When running Godot as a part of CI on a build machine, multiple instances of Godot can be launched 
to work with different workspaces. However, at least one problem with this is that Godot may create temporary files (grep `get_cache_dir()`) with same paths for different runs, so you get a race condition between multiple instances. This has caused problems in our actual workflow - when two separate jobs run Godot on the same machine, we get corrupted packages as a result.
Repository: opencv
Issue: Latest doxygen (1.8.14) segfaults
Labels: category: documentation,incomplete

##### System information (version)
- OpenCV => 3.4.0
- Operating System / Platform => Linux 64 Bit
- Compiler => gcc-7.3
- doxygen => 1.8.14

##### Detailed description

Previously, using doxygen-1.8.9.1, generating documentation completed OK.
However using latest doxygen-1.8.14, ```make doxygen``` fails with segmentation fault:
```
[100%] Generate Doxygen documentation
make[3]: *** [doc/CMakeFiles/doxygen_cpp.dir/build.make:392: doc/CMakeFiles/doxygen_cpp] Segmentation fault
make[2]: *** [CMakeFiles/Makefile2:13022: doc/CMakeFiles/doxygen_cpp.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:12965: doc/CMakeFiles/doxygen.dir/rule] Error 2
make: *** [Makefile:3135: doxygen] Error 2
```

##### Steps to reproduce
Upgrade to lastest doxygen-1.8.14. After usual cmake configuration & make, run ```make doxygen```.
Running doxygen directly on generated Doxyfile gives no extra clue:
```
   root@sl64current:/var/tmp/SBo/opencv-3.4.0/build# doxygen doc/Doxyfile
   Segmentation fault
   root@sl64current:/var/tmp/SBo/opencv-3.4.0/build#
```
Again, reverting to doxygen-1.8.9.1 runs without any problem.
Repository: rust
Issue: Compiling crate serde-derive with "-Z sanitizer=leak" fails
Labels: T-compiler,A-sanitizers,A-macros-2.0,C-bug

Compiling my crate that uses `serde` with `RUSTFLAGS="-Z sanitizer=leak"` results in:
```
error: Only executables, staticlibs, cdylibs, dylibs and rlibs can be compiled with `-Z sanitizer`
```

Verbose output shows:
```
     Running `rustc --crate-name cubeb_core cubeb-core/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=61d1a8a7b2e564d0 -C extra-filename=-61d1a8a7b2e564d0 --out-dir /home/djg/Mozilla/cubeb-rs/target/debug/deps -C incremental=/home/djg/Mozilla/cubeb-rs/target/debug/incremental -L dependency=/home/djg/Mozilla/cubeb-rs/target/debug/deps --extern cubeb_sys=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libcubeb_sys-f4b7e696cf674255.rlib --extern foreign_types=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libforeign_types-9d464a343a654ec3.rlib --extern bitflags=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libbitflags-709a54b1053b84e9.rlib -Z sanitizer=leak -L native=/home/djg/Mozilla/cubeb-rs/target/debug/build/cubeb-sys-52b952c542113788/out/lib -L native=/usr/lib64 -L native=/usr/lib64 -L native=/usr/lib64`
error: aborting due to previous error

error: Could not compile `serde_derive`.

Caused by:
  process didn't exit successfully: `rustc --crate-name serde_derive /home/djg/.cargo/registry/src/github.com-1ecc6299db9ec823/serde_derive-1.0.27/src/lib.rs --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C debuginfo=2 --cfg feature="default" -C metadata=8e2449096591e6bb -C extra-filename=-8e2449096591e6bb --out-dir /home/djg/Mozilla/cubeb-rs/target/debug/deps -L dependency=/home/djg/Mozilla/cubeb-rs/target/debug/deps --extern syn=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libsyn-b487ac40d22b413a.rlib --extern quote=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libquote-2902a853682299e0.rlib --extern serde_derive_internals=/home/djg/Mozilla/cubeb-rs/target/debug/deps/libserde_derive_internals-dcd3ff49aa5d175c.rlib --cap-lints warn -Z sanitizer=leak` (exit code: 101)
```
Repository: TypeScript
Issue: Understand 'int', 'integer', 'float', 'double', etc. as 'number' in JSDoc
Labels: Suggestion,Awaiting More Feedback,Domain: JavaScript

All numeric-sounding names should probably resolve to `number` (maybe only if no other type is defined with such a given name).

Ideas:

* `[u]int[8|16|32|64]`
* `integer`
* `float`
* `double`
Repository: puppeteer
Issue: headerTemplate and footerTemplate only work with truthy values
Labels: feature,upstream,chromium

**Tell us about your environment:**

* Puppeteer version: 1.0.0
* Platform / OS version: Ubuntu 16.04
* URLs (if applicable):
* Node.js version: 6.12.3

**What steps will reproduce the problem?**

```
await page.pdf({
    headerTemplate: '',
    footerTemplate: '',
});
```

**What is the expected result?**

The header and footer should be blank.

**What happens instead?**

The default header and footer are still shown.

It seems that passing any falsey value results in the default template being used instead. I would suggest that only `undefined` should cause it to use the default template. Empty string, `null`, `false` and `0` should all override the default template.

Thanks.
Repository: go
Issue: x/build: sharded iOS builders
Labels: Builders,NeedsInvestigation,mobile,new-builder

Currently, the android/amd64 and android/386 builders run on an Android emulator with a amd64 system image. This is taxing the heavyly loaded mobile builder Mac Mini. It is also inefficient: the emulator builds competes with Android device builds and any concurrent iOS builds. Because builds are slow, android is not in the trybot set, leaving me to often pester CL authors with "this CL broke android".

Is it possible to add (and run) the Android emulator inside the existing docker images used for regular builders and then run android sharded tests as any other GOOS? If so, android/amd64 and android/386 builds would complete much faster, and take some pressure off the mobile device builder.

If the emulator builds are stable enough, android/amd64 (and perhaps android/386) could even join the trybot set, avoiding most (if not all) android specific followup work after a CL is submitted.
Repository: go
Issue: x/build/cmd/gerritbot: don't post CL updates if the PR author has a Gerrit account
Labels: Builders

For example: https://github.com/golang/go/pull/23809

If gerritbot successfully added the PR author as a reviewer or as CC to the Gerrit CL, it makes little sense to forward comment/review updates to the Github pull request in the form of comments.
Repository: vscode
Issue: "Download Now" button should respect the used installation method on Linux
Labels: help wanted,feature-request,install-update,linux

### Issue Type

Bug

### Description

> __Edit:__ Originally this issue was specifically about the `.deb` installation method, but since this problem is not specific to it, I edited the issue to be more general.

#### How to reproduce

1. Install (an outdated version of) VS Code using one of the installation methods.
2. Open VSCode and wait for the `(1)` to appear on the settings icon.
3. Click on the settings icon and then on **Download Now**.

#### Expected behavior

VSCode starts the download of the latest version's file (when the `.tar.gz` was used to install VS Code) or instructs the user to run an update through the relevant package manager.

#### Actual behavior

VS Code always starts the download of the latest version's `.tar.gz` file.

### Possible solution

VS Code could check what type of download was used to install and behave differently based on that.
Checking whether a `.deb` was used could look something like this:

```ts
import { spawn } from 'child_process';

export function isDebInstallation(): Promise<boolean> {
  return new Promise(resolve => {
    spawn('dpkg', ['--list', 'code']).on('close', code => {
      resolve(code === 0);
    });
  });
}
```

Another option would be to include the information about what installation method was used in the release.

### VS Code Info

VS Code version: Code 1.20.0 (c63189deaa8e620f650cc28792b8f5f3363f2c5b, 2018-02-07T17:10:15.949Z)
OS version: Linux x64 4.13.0-32-generic

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz (4 x 3300)|
|Load (avg)|1, 1, 1|
|Memory (System)|15.61GB (10.31GB free)|
|Process Argv|/usr/share/code/code .|
|Screen Reader|no|
|VM|0%|

</details>
Reproduces without extensions
Repository: rust
Issue: incr.comp.: Do per-MonoItem dependency tracking in order to collect data about granularity fallout.
Labels: C-enhancement,T-compiler,A-incr-comp

Currently the compiler only allocates a single `DepNode` per CGU. This is enough for implementing object file re-use but we are losing information about what items within an object file exactly caused it to be re-compiled. In order to gather more information about how CGU partitioning affects re-use, it would be good to know which `MonoItems` within a CGU were changed and which were not.

Before making this the default though, we should check how it affects the number of `DepNodes` and edges in the graph.
Repository: rust
Issue: incr.comp.: Allow for re-using object files that contain unused code.
Labels: C-enhancement,T-compiler,A-incr-comp

Right now, incremental compilation can only re-use an object file if it is an exact match of that code that we want. In theory it would be possible though to keep using an object file that contains a superset of the code we need.

An implementation would probably need https://github.com/rust-lang/rust/issues/48211 to be implemented first. CGU translation would also need to be de-querified since the re-use decision cannot be made by simply marking the CGU as green. 

However, before putting effort into implementing this we should make sure that it would actually pay off. For this we need to collect some data on `MonoItem` invalidation (which again is covered by https://github.com/rust-lang/rust/issues/48211).
Repository: rust
Issue: Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses 
Labels: B-RFC-approved,T-lang,B-unstable,B-RFC-implemented,C-tracking-issue,S-tracking-impl-incomplete,S-tracking-needs-summary,F-trivial_bounds

This is a tracking issue for the RFC "Allow trivial constraints to appear in where clauses " (rust-lang/rfcs#2056).

**Steps:**

- [x] Implement the RFC – https://github.com/rust-lang/rust/pull/48557
  - [ ] As noted in https://github.com/rust-lang/rust/issues/48214#issuecomment-396038764, the new trait solver might solve a few issues with this feature, so this is currently blocked on the new trait solver (`-Znext-solver`)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation

**Unresolved questions:**

- [ ] Should the lint error by default instead of warn?
Repository: TypeScript
Issue: Glob support for per pattern tsconfig configuration
Labels: Suggestion,In Discussion

It's common to have different configurations for files in the same directory with different name patterns. The most common is `file.ts` and `file.test.ts`. We usually have different configurations for test files. For instance the global `"jest"` type is needed in test files but not in source files. 

To separate configuration for test and source we can have two separate `tsconfig.json` files which `"include"` only test and source:

```js
// tsconfig.json

{
  "exclude": ["*.test.ts"]
} 
```
> Exclude glob is pending https://github.com/Microsoft/TypeScript/issues/10202

```js
// test.tsconfig.json

{
  "include": ["*.test.ts"],
  "compilerOptions": {
    "types": ["jest"]
  }
} 
```

But this is not optimal for IDEs and other tsc users. 


### Glob based `tsconfig.json`
I'm proposing a glob based tsconfig.json which has different config per glob pattern:

```js
[
        {
                // Shared config
                "compilerOptions": {}
        },
        {
                "include": ["*.test.ts"],
                "compilerOptions": {
                        "lib": ["jest"]
                }
        }
]
```

### Changes to `tsconfig.json` 

* It can be an array of configurations
* Each item in the array can specify `include` or `exclude` for fine grained compiler options 


### Resolving compiler option per file pattern
TODO

### Conflicting exclude and include pattern between compiler options
TODO

this way one tsconfig.json can serve for all files with different configs per pattern 

**TypeScript Version:**  2.7
**Search Terms:** 
* TSConfig
* Glob 
* Pattern
Repository: go
Issue: cmd/compile: avoid updating capacity if unused
Labels: Performance,NeedsFix,compiler/runtime

Using go1.10,

Consider the following code:
```go
func IsASCII(b []byte) bool {
	for len(b) >= 8 {
		x := binary.LittleEndian.Uint64(b)
		if x&0x8080808080808080 > 0 {
			return false
		}
		b = b[8:]
	}
	for _, x := range b {
		if x&0x80 > 0 {
			return false
		}
	}
	return true
}
```

The compiled assembly is as follows:
```
0x0000 00000 (main.go:11)	MOVQ	"".b+16(SP), AX
0x0005 00005 (main.go:11)	MOVQ	"".b+24(SP), CX
0x000a 00010 (main.go:11)	MOVQ	"".b+8(SP), DX
0x000f 00015 (main.go:12)	JMP	45
0x0011 00017 (main.go:17)	ADDQ	$-8, CX
0x0015 00021 (main.go:17)	MOVQ	CX, BX
0x0018 00024 (main.go:17)	NEGQ	CX
0x001b 00027 (main.go:17)	SARQ	$63, CX
0x001f 00031 (main.go:17)	ANDQ	$8, CX
0x0023 00035 (main.go:17)	ADDQ	CX, DX
0x0026 00038 (main.go:17)	ADDQ	$-8, AX
0x002a 00042 (main.go:17)	MOVQ	BX, CX
0x002d 00045 (main.go:12)	CMPQ	AX, $8
0x0031 00049 (main.go:12)	JLT	75
0x0033 00051 (main.go:13)	MOVQ	(DX), BX
0x0036 00054 (main.go:13)	MOVQ	$-9187201950435737472, SI
0x0040 00064 (main.go:14)	TESTQ	BX, SI
0x0043 00067 (main.go:14)	JLS	17
0x0045 00069 (main.go:15)	MOVB	$0, "".~r1+32(SP)
0x004a 00074 (main.go:15)	RET
0x004b 00075 (main.go:15)	MOVL	$0, CX
0x004d 00077 (main.go:19)	JMP	85
0x004f 00079 (main.go:19)	INCQ	DX
0x0052 00082 (main.go:19)	INCQ	CX
0x0055 00085 (main.go:19)	CMPQ	CX, AX
0x0058 00088 (main.go:19)	JGE	104
0x005a 00090 (main.go:19)	MOVBLZX	(DX), BX
0x005d 00093 (main.go:20)	TESTB	$-128, BL
0x0060 00096 (main.go:20)	JLS	79
0x0062 00098 (main.go:21)	MOVB	$0, "".~r1+32(SP)
0x0067 00103 (main.go:21)	RET
0x0068 00104 (main.go:24)	MOVB	$1, "".~r1+32(SP)
0x006d 00109 (main.go:24)	RET
```
You'll notice that the slice header {ptr, len, cap} are loaded into {DX, AX, CX}. Several times in the assembly, you see the CX register being used as it seems that `b = b[8:]` on line 17 causes the capacity to also be updated.

However, the go code actually does not care about the capacity at all. If the compiler is able to prove that the capacity will never be used, then it could avoid doing the math to ensure that the capacity is up-to-date.

\cc @randall77 @dr2chase
Repository: kubernetes
Issue: GCE Node Controller is very inefficient with multiple zones
Labels: kind/bug,area/platform/gce,area/nodecontroller,area/cloudprovider,lifecycle/frozen,sig/cloud-provider,needs-triage

Looking at getInstanceByName https://github.com/kubernetes/kubernetes/blob/release-1.8/pkg/cloudprovider/providers/gce/gce_instances.go#L461, we do a very inefficient search for instances by name.  This is free when there is only one zone, and cheap if the product `(number of zones) x (number of nodes)` is small, but it can get out of hand quickly with large, multi-zone clusters.

It not only wastes effort, but it generates a noisy signal on the cloud provider end, as kube-controller-manager starts racking up huge numbers of 404s.

Can we make this more efficient?  At the very least, can we please stop logging these as errors?  They are expected.
https://github.com/kubernetes/kubernetes/blob/release-1.8/pkg/cloudprovider/providers/gce/gce_instances.go#L483

cc @cheftako 
/kind bug
/sig node
/area nodecontroller
Repository: go
Issue: x/mobile/app: TestAndroidApp test is failing
Labels: mobile

Running go test golang.org/x/mobile/app:

````
--- FAIL: TestAndroidApp (1.01s)
	app_test.go:232: gomobile version
	app_test.go:232: gomobile install golang.org/x/mobile/app/internal/testapp
	app_test.go:235: gomobile install golang.org/x/mobile/app/internal/testapp exit status 1: gomobile: manual declaration of uses-sdk in AndroidManifest.xml not supported
FAIL
FAIL	golang.org/x/mobile/app	1.015s
````

Even after removing the explicit <uses-sdk> element from app/internal/testapp/AndroidManifest.xml, TestAndroidApp still fails:

````
--- FAIL: TestAndroidApp (2.78s)
	app_test.go:232: gomobile version
	app_test.go:232: gomobile install golang.org/x/mobile/app/internal/testapp
	app_test.go:77: local address: tcp:43823
	app_test.go:232: adb reverse tcp:12533 tcp:43823
	app_test.go:232: adb shell input keyevent 26
	app_test.go:232: adb shell input keyevent 82
	app_test.go:232: adb shell content insert --uri content://settings/system --bind name:s:accelerometer_rotation --bind value:i:0
	app_test.go:232: adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:0
	app_test.go:232: adb shell am start -n org.golang.testapp/org.golang.app.GoNativeActivity
	app_test.go:128: comm.recv: hello_from_testapp
	app_test.go:128: comm.send: hello_from_host
		
	app_test.go:128: comm.recv: lifecycle_visible
	app_test.go:128: comm.recv: size 2.2222223 1
	app_test.go:128: comm.recv: paint red
	app_test.go:232: adb shell content insert --uri content://settings/system --bind name:s:user_rotation --bind value:i:1
	app_test.go:128: comm.recv: size 2.2222223 1
	app_test.go:151: want orientation 2, got 1
	app_test.go:232: adb shell input tap 50 260
	app_test.go:128: comm.recv: size 2.2222223 1
	app_test.go:127: cannot scan recv command touch: "size 2.2222223 1": EOF
FAIL
FAIL	golang.org/x/mobile/app	2.789s
````
Repository: TypeScript
Issue: Divide by zero Typechecking
Labels: Suggestion,In Discussion

We have type literals for numbers already and a `strictNullCheck` compiler option -- wouldn't it be awesome if we had a type guard again divide-by-zero errors? I'm building a game that involved a lot of math, computing intersections of lines and such. But what if a line is parallel? It would be cool if the compiler would suggest this as a type error.

```
function f(): number | 0 {
    return 0
}

const y = 100 / f()
```
<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx
Repository: flutter
Issue: Flutter can receive touches even when hidden behind another native ViewController
Labels: platform-ios,engine,customer: posse (eap),has reproducible steps,P2,found in release: 3.7,found in release: 3.8,team-ios,triaged-ios

I have an example at https://github.com/xster/flutter-test/tree/master/t33_animation_with_native

Even after the second view controller was presentViewController'ed, the FlutterViewController still passes events to Flutter. 

cc @cbracken any ideas?
Repository: go
Issue: net: add support for Happy Eyeballs version 2 (RFC 8305)
Labels: Proposal,Proposal-Accepted

Since RFC 6555 published, research papers, for example, Measuring the Effects of Happy Eyeballs, depict improvement space for the RFC. In addition, network or service operators speak up that the race is not only for TCP connection setup but for DNS query handling. [RFC 8305](https://tools.ietf.org/html/rfc8305) Happy Eyeballs version 2 addresses such issues.

To summarize, version 2 clarifies the existing algorithm, modifies the configurable variable values for performance improvement and adds consideration for various circumstances such as IPv6-IPv4 transition and VPN. Luckily, there's no significant user-visible behavioral change.

I'd like to propose to replace the existing RFC 6555 implementation with RFC 8305 implementation after landing dns/dnsmessage package (#16218).
Repository: rust
Issue: llvm lint: "unreachable immediately preceded by instruction without side effects"
Labels: A-LLVM,C-enhancement,T-compiler

reduced from https://github.com/alexcrichton/rustc-demangle/
````rust
pub fn demangle(inner: &str) {
    inner.chars().peekable().by_ref().take(0).count();
}
````
````
$ RUSTFLAGS="-C passes=lint"  cargo build 

   Compiling rustc-demangle v0.1.5 (file:///tmp/rustc-demangle)
Unusual: unreachable immediately preceded by instruction without side effects
  unreachable, !dbg !33
    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
````
//cc #7463
Repository: flutter
Issue: Support creating projects without all the IntelliJ files
Labels: c: new feature,tool,P3,team-tool,triaged-tool

I'm looking at integrating `flutter create` into a command in VS Code. Currently when you run this it outputs a bunch of IntelliJ files that are not wanted if you're working in VS Code. For now I'm thinking of just deleting them, but it'd be nice if they could just be excluded (for example a flag to tell `flutter create` which IDE to create settings for, or a `--no-intellij-files` flag or something).

I think the things that are not required are:
- `.idea` folder
- several `.iml` files in the root