sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [CMake] Linking against Intel OpenMP
Labels: module: build,triaged,module: mkldnn,module: openmp

Checking the current CMAKE files, it seems like PyTorch will always use the compile OpenMP libraries due to `-fopenmp` in:

https://github.com/pytorch/pytorch/blob/033e95765c19e208a0ac04376ae7cacb62940e9a/torch/CMakeLists.txt#L314-L321

MKL-DNN readme advises to not mix the OpenMP libraries, and to not use `-fopenmp` when using Intel-OpenMP as it would link against both intel and the compiler OpenMP: https://github.com/intel/mkl-dnn/blob/17c33b596670123f8cf74afbdcc722b7ec1e01a2/README.md#intel-mkl-dnn-with-openmp

> Intel MKL-DNN library built with binary dependency will link against Intel OpenMP runtime included with Intel MKL small libraries package. Intel OpenMP runtime is binary compatible with GNU OpenMP and CLANG OpenMP runtimes and is recommended for the best performance results. Here are example linklines for GNU C++ compiler and Intel C++ compiler.
>
>	`g++ -std=c++11 -I${MKLDNNROOT}/include -L${MKLDNNROOT}/lib simple_net.cpp -lmkldnn -lmklml_intel -liomp5`
>	`icpc -std=c++11 -qopenmp -I${MKLDNNROOT}/include -L${MKLDNNROOT}/lib simple_net.cpp -lmkldnn -lmklml_intel`
>
> Using GNU compiler with -fopenmp and -liomp5 options will link the application with both Intel and GNU OpenMP runtime libraries. This will lead to undefined behavior of the application.


Also the MKL cmake seems to link against both gnu and intel threads?

https://github.com/pytorch/pytorch/blob/033e95765c19e208a0ac04376ae7cacb62940e9a/cmake/Modules/FindMKL.cmake#L55-L66

cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh
Repository: go
Issue: proposal: encoding/xml: update character ranges for names to fifth edition (2008) specification
Labels: Proposal,FeatureRequest

Currently the validation of XML names is based on the original 1998 specification which defines a large set of codepoint ranges that are to be accepted. These ranges were widened and simplified in the [fifth edition of the spec](http://www.w3.org/TR/2008/REC-xml-20081126/), published in 2008 and now the current version. 

The name production rules are now:

```
NameStartChar  ::=       ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | 
                           [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | 
                           [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | 
                           [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | 
                           [#x10000-#xEFFFF]
NameChar       ::=       NameStartChar | "-" | "." | [0-9] | #xB7 | 
                           [#x0300-#x036F] | [#x203F-#x2040]
Name           ::=       NameStartChar (NameChar)*
Names          ::=       Name (#x20 Name)*
Nmtoken        ::=       (NameChar)+
Nmtokens       ::=       Nmtoken (#x20 Nmtoken)*
```

This may also address the majority of the requirements for xml1.1 support (#25755) since the [changes between 1.0 and 1.1](https://www.w3.org/TR/xml11/#sec-xml11) were the expansion of the name character ranges, the addition of two line ending characters (U+0085, U+2028) and specification of additional normalisation rules

The current ranges span 300 lines of code in the xml package so changing this will also contribute to #26775 

If there is interest then I can submit a CL.
Repository: flutter
Issue: ThemeData.copyWith() doesn't update dependent themes
Labels: framework,f: material design,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-design,triaged-design

Summary: Adding colors to ButtonThemeData (https://github.com/flutter/flutter/pull/22013) highlighted a general problem with `ThemeData.copyWith`: subordinate themes (like ThemeData.buttonTheme) aren't updated when a ThemeData property they depend on is changed.

ThemeData.copyWith has simple semantics: it updates the specified fields, but not dependent fields. For example there are 10 subordinate themes, each with its own set of ThemeData dependencies:
```
  colorScheme
  buttonTheme
  sliderTheme
  tabBarTheme
  chipTheme
  inputDecorationTheme
  pageTransitionsTheme
  textTheme
  primaryTextTheme
  accentTextTheme
```

None of the subordinate themes are changed if (say) a color they depend on is changed with ThemeData.copyWith(). For example:
`myThemeData.copyWith(buttonColor: myButtonColor)` doesn't change `myThemeData.buttonTheme`.


We could add a `ThemeData.apply` method, like `TextTheme.apply` but more complicated. The basic idea would be to update all of the subordinate themes that depend on ThemeData properties like primaryColor and accentColor.

To implement ThemeData.apply, we'd have to implement colorScheme.apply, buttonTheme.apply etc.

Documenting ThemeData.apply would be complicated itself because each subordinate theme has its own set of ThemeData dependencies.

That said, in the applications I've looked at - usually - where developers use ThemeData.copyWith they're usually careful to rebuild the subordinate theme they're trying to effect. The ButtonTheme is an exception because it's new, and see https://github.com/flutter/flutter/issues/22711.

For the moment I'm inclined to leave things as they are. Some improvements in the docs (including some examples) would help.
Repository: go
Issue: gccgo: confusing error message when encountering invalid .. (dot dot) token
Labels: NeedsInvestigation

For
```Go
$ cat y.go
package p

func f(x ..int) {}
```
current gccgo reports the errors:
```
$ gccgo -c y.go
y.go:3:10: error: expected package
3 | func f(x ..int) {}
  |          ^
y.go:3:8: error: invalid named/anonymous mix
3 | func f(x ..int) {}
  |        ^
```
I would have expected an error at the `..` as it is not a valid token.

For the reference, cmd/compile reports for the same file:
```
$ go tool compile y.go
y.go:3:11: syntax error: unexpected ., expecting name
```
which seems more sensible.
Repository: TypeScript
Issue: User-defined type guard method can be overridden with any non-type-guard return type
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  master (07966dcb124ee379a4f062c1032fec0a6c4eaf19)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** user-defined type guard predicate method override overridden return

**Code**
```ts
interface A {
    isB(): this is B;
}
interface B extends A {
    isB(): "this is nonsense";
}
```

**Expected behavior:** Error on `"this is nonsense"`.

**Actual behavior:** No error.

**Playground Link:** [link](https://www.typescriptlang.org/play/#src=interface%20A%20%7B%0D%0A%20%20%20%20isB()%3A%20this%20is%20B%3B%0D%0A%7D%0D%0Ainterface%20B%20%7B%0D%0A%20%20%20%20isB()%3A%20%22this%20is%20nonsense%22%3B%0D%0A%7D%0D%0A)

**Related Issues:** none found
Repository: go
Issue: proposal: spec: make fewer types nillable
Labels: LanguageChange,Proposal,LanguageChangeReview

Apologies if this has been suggested before; I've been unable to find an issue.

Currently go has many basic types where the zero value is `nil`. `nil` is a huge source of bugs, and a potential Go 2, where backwards-incompatible changes are on the table, offers an opportunity to make the language more robust by reducing its scope.

Specifically, in some cases there is an obvious zero-value that makes more sense than nil. Off the top of my head:

* The zero value for slices could be a slice with length and capacity of zero.
* The zero value for maps could be an empty map.
* The zero value for channels could be an unbuffered channel.

This is more in keeping with the design principle of making the zero value useful.

There isn't an obvious good zero value that I can think of for pointers and interfaces, but even this partial reduction would make it easier to build reliable software.
Repository: rust
Issue: Improve error message for reserved ambiguation
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

Compiling this code:
```rust
trait Foo {
    type not_really_ambiguous_i_promise;
}

impl Foo for isize {
    type not_really_ambiguous_i_promise = usize;
}

fn main() {
    let x: isize::not_really_ambiguous_i_promise = 17;
    println!("{}", x);
}
```

Produces this error:
```
error[E0223]: ambiguous associated type
  --> src/main.rs:10:12
   |
10 |     let x: isize::not_really_ambiguous_i_promise = 17;
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ambiguous associated type
   |
   = note: specify the type using the syntax `<isize as Trait>::not_really_ambiguous_i_promise`
```

Presuming that this is because such code might become ambiguous in the future, we need a better error message.
Repository: TypeScript
Issue: Cannot override method in subclass when superclass instance type is a mapped type
Labels: Suggestion,In Discussion

**TypeScript Version:**  3.1.1

**Search Terms:**
defines instance member property

**Code**

```ts
class A {
    foo(): void {};
    bar: number;
}

class B extends (A as { new(): Pick<A, Exclude<keyof A, "foo">> & Pick<A, "foo"> }) {
    // (1)
    foo(): void {
        super.foo();
    }
    baz: number;
}
```

**Expected behavior:**
Compiles successfully

**Actual behavior:**

Error at (1): `[ts] Class 'Pick<A, "bar"> & Pick<A, "foo">' defines instance member property 'foo', 
but extended class 'B' defines it as instance member function.`

**Playground Link:** http://www.typescriptlang.org/play/index.html#src=class%20A%20%7B%0D%0A%20%20%20%20foo()%3A%20void%20%7B%7D%3B%0D%0A%20%20%20%20bar%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Aclass%20B%20extends%20(A%20as%20%7B%20new()%3A%20Pick%3CA%2C%20Exclude%3Ckeyof%20A%2C%20%22foo%22%3E%3E%20%26%20Pick%3CA%2C%20%22foo%22%3E%20%7D)%20%7B%0D%0A%20%20%20%20foo()%3A%20void%20%7B%0D%0A%20%20%20%20%20%20%20%20super.foo()%3B%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20baz%3A%20number%3B%0D%0A%7D

A more realistic example of this is when using https://github.com/bterlson/strict-event-emitter-types along with subclassing a [superclass with overridable methods](https://github.com/bterlson/strict-event-emitter-types#usage-with-subclasses):

```ts
import StrictEventEmitter from "strict-event-emitter-types";
import * as inspector from "inspector";

interface SessionEvents {
  "Runtime.executionContextCreated": (message: inspector.InspectorNotification<Runtime.ExecutionContextCreatedEventDataType>) => void
}
type StrictSession = StrictEventEmitter<inspector.Session, SessionEvents>;
class CustomSession extends (inspector.Session as { new (): StrictSession }) {
  connect() { // error here
    super.connect();
  }
}
```
Repository: kubernetes
Issue: Update default storageclasses to use delayed binding
Labels: sig/storage,kind/feature,lifecycle/frozen

<!-- This form is for bug reports and feature requests ONLY!

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).

If the matter is security related, please disclose it privately via https://kubernetes.io/security/.
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:
@kubernetes/sig-storage-feature-requests 

**What happened**:
Once topology goes GA, let's update the default storageclasses to set "WaitForFirstConsumer" volume binding mode.  The addon is set to "EnsureExists", which means that if the object is already created, then we do not modify it.  So users upgrading will not be affected.  Only new clusters created will get the new default storageclass.  This will need an "ACTION REQUIRED" release note that users need to update their workflow if they were dependent on the PVC being provisioned first before creating Pods.
Repository: TypeScript
Issue: "An argument for 'param' was not provided." should use types to guess most likely missing parameter
Labels: Suggestion,In Discussion,Domain: Error Messages

**TypeScript Version:**  3.2.0-dev.20181009

**Code**

```ts
function f(n: number, s: string) {}
f("");
```

**Expected behavior:**

`An argument for 'n' was not provided.`

**Actual behavior:**

```
src/a.ts:2:1 - error TS2554: Expected 2 arguments, but got 1.

2 f("");
  ~~~~~

  src/a.ts:1:23
    1 function f(n: number, s: string) {}
                            ~~~~~~~~~
    An argument for 's' was not provided.
```
Repository: ant-design
Issue: Calendar Events View
Labels: 🗣 Discussion,💡 Feature Request,Inactive,IssueHuntFest

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
1、一个通知可以跨日期显示。
2、通知可以显示为色带。

### What does the proposed API look like?
**这个样子的：**
![image](https://user-images.githubusercontent.com/27573161/46777848-a801e700-cd43-11e8-94a8-5760f14fca8f.png)



<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: flutter
Issue: Flutter plugin Kotlin version mismatch
Labels: platform-android,tool,P2,a: plugins,team-android,triaged-android

Allowing to write plugins in kotlin is cool, but it occurs that there some problem once a plugin use an old version of kotlin compare to the current project. 
We'll get something like 

```
* What went wrong:
The Android Gradle plugin supports only Kotlin Gradle plugin version 1.2.51 and higher. Project 'plugin_with_old_kotlin' is using version 1.2.30.
```

Is there a fix for this except waiting for the plugin maintainer to update his plugin with last kotlin version ? If not then all plugins written in kotlin should be avoided in order to be safe for the future. And in this case it will be better if flutter force plugins to be in Java only. 

Being blocked until all kotlin plugins are using last kotlin version is very scary
Repository: rust
Issue: Goal: Accept partial initialization + use of records created via such
Labels: P-low,T-lang,A-NLL,NLL-complete

Spawned off of #21232

In the long-term, we want to accept code like this:

```rust
struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; s.y = 30; a_use_of(&s); another_use_of(s); }
fn a_use_of(_s: &S) { /* ... */ }
fn another_use_of(_s: S) { /* ... */ }
```

We probably *also* want to start accepting this too:

```rust
struct S { x: u32, y: u32 }
fn main() { let mut s: S; s.x = 10; a_use_of_field(s.x); }
fn a_use_of_field(_x: u32) { /* ... */ }
```

(But that second example is more debatable. I don't think there's any debate about the first example.)

----

See #54986 for the short-term goal of rejecting all partial initializations until we can actually *use* the results you get from partial initialization.
Repository: create-react-app
Issue: Inconsistent "Relative imports outside of src/" restriction ?
Labels: issue: needs investigation

### Is this a bug report?

Maybe not

### Which terms did you search for in User Guide?

This is related to my previous answer : https://github.com/facebook/create-react-app/issues/1333#issuecomment-428200810

### Steps to Reproduce

I have a projet which imports an other "private" package. I am using sass in both packages. The private package is passed to babel only (not node-sass).

I have something like the following in the private module : 

```js
// src/component/module.js

import '../styles/module.scss';
```

```scss
// src/styles/module.scss

.module {
    background: url('../images/module.jpg');
}
```

Then in the main project, if i do this :  

```js
// src/index.js

import '@my/module/dist/component/module.js';
```

everything works fine, but if i do "the same thing" from my sass file :  

```scss
// src/main.scss

@import '@my/module/dist/styles/module.scss';
```

i obtain the following error : 

```
Module not found: You attempted to import ../images/module.jpg which falls outside of the project src/ directory. Relative imports outside of src/ are not supported.
```

### Expected Behavior

Both import should fail or success ?

To be able to split my project, i would like to be able to import other packages components and sass files.

### Actual Behavior

Importing from sass from sass fails but importing sass from js works.
Repository: TypeScript
Issue: Type inference/narrowing lost after assignment
Labels: Suggestion,In Discussion

**TypeScript Version:**  3.1

**Search Terms:** type inference, type guard, narrowing, lost, assignment

**Code**

```ts
let a: unknown = 'x';

if (typeof a === 'string') {
  // a inferred as `string`
  a = a.substr(0, 5);  // (method) String.substr(from: number, length?: number): string
  // a inferred as `unknown`
  a.length;            // Failure: Object is of type 'unknown'.
}
```

**Expected behavior:** This should compile without an error.

**Actual behavior:** Line 7 fails with: `Object is of type 'unknown'.`

**Playground Link:** https://www.typescriptlang.org/play/index.html#src=let%20a%3A%20unknown%20%3D%20'x'%3B%0D%0A%0D%0Aif%20(typeof%20a%20%3D%3D%3D%20'string')%20%7B%0D%0A%20%20%2F%2F%20a%20inferred%20as%20%60string%60%0D%0A%20%20a%20%3D%20a.substr(0%2C%205)%3B%0D%0A%20%20%2F%2F%20a%20inferred%20as%20%60unknown%60%0D%0A%20%20a.length%3B%0D%0A%7D%0D%0A

**Related Issues:** #18840, #19955, #26673
Repository: kubernetes
Issue: Log something about OOMKilled containers
Labels: sig/node,kind/feature

**Is this a BUG REPORT or FEATURE REQUEST?**:

/kind feature

**What happened**:

Container gets killed because it tries to use more memory than allowed.

**What you expected to happen**:

Have an `OOMKilled` **event** tied to the pod and logs about this

/sig node
Repository: TypeScript
Issue: Nested lookuptypes do not inference correctly
Labels: Bug

While trying to scope certain keys that would point to different types, I stumbled upon a problem when I needed to nest lookup types to lookup what `type` the `key` would correspond to. During decleration, this did not seem to be possible to get the compiler to understand. Applying the type does actually give out the correct type inferencing though. A simple example can be observed below.

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.201xxxxx
Tested with both 3.1.1 and typescript@next

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
Lookuptypes, type inference, keyof

**Code**
```
interface Y {
  x: {
    x1: "x1";
    x2: "x2";
  }
}

interface Z {
  x1: number;
  x2: string;
  x3: number;
}

type H<K extends keyof Y, J extends keyof Y[K]> = (k: K, j: J) => Z[Y[K][J]]; // <----- Error Incorrectly?!
type T6 = H<"x", "x1">;
type T7 = H<"x", "x2">;
type T8 = H<"x", "x3">; // Errors Correctly!

// @ts-ignore
type L<K extends keyof Y, J extends keyof Y[K]> = (k: K, j: J) => Z[Y[K][J]];
type T3 = L<"x", "x1">;
type T4 = L<"x", "x2">;
type T5 = L<"x", "x3">; // Errors Correctly!
```

**Expected behavior:**
For the `Z[Y[K][J]]` in the example to not give error. Applying the type seems to work correctly.

**Actual behavior:**
Decleration of the type shows error when it should not.

**Playground Link:** https://www.typescriptlang.org/play/#src=interface%20Y%20%7B%0D%0A%20%20x%3A%20%7B%0D%0A%20%20%20%20x1%3A%20%22x1%22%3B%0D%0A%20%20%20%20x2%3A%20%22x2%22%3B%0D%0A%20%20%7D%0D%0A%7D%0D%0A%0D%0Ainterface%20Z%20%7B%0D%0A%20%20x1%3A%20number%3B%0D%0A%20%20x2%3A%20string%3B%0D%0A%20%20x3%3A%20number%3B%0D%0A%7D%0D%0A%0D%0A%0D%0Atype%20H%3CK%20extends%20keyof%20Y%2C%20J%20extends%20keyof%20Y%5BK%5D%3E%20%3D%20(k%3A%20K%2C%20j%3A%20J)%20%3D%3E%20Z%5BY%5BK%5D%5BJ%5D%5D%3B%0D%0A%0D%0Atype%20T6%20%3D%20H%3C%22x%22%2C%20%22x1%22%3E%3B%0D%0Atype%20T7%20%3D%20H%3C%22x%22%2C%20%22x2%22%3E%3B%0D%0Atype%20T8%20%3D%20H%3C%22x%22%2C%20%22x3%22%3E%3B%0D%0A%0D%0A%2F%2F%20%40ts-ignore%0D%0Atype%20L%3CK%20extends%20keyof%20Y%2C%20J%20extends%20keyof%20Y%5BK%5D%3E%20%3D%20(k%3A%20K%2C%20j%3A%20J)%20%3D%3E%20Z%5BY%5BK%5D%5BJ%5D%5D%3B%0D%0A%0D%0Atype%20T3%20%3D%20L%3C%22x%22%2C%20%22x1%22%3E%3B%0D%0Atype%20T4%20%3D%20L%3C%22x%22%2C%20%22x2%22%3E%3B%0D%0Atype%20T5%20%3D%20L%3C%22x%22%2C%20%22x3%22%3E%3B%0D%0A
Repository: go
Issue: x/crypto/sha3: add SHA3 assembly implementation for ARMv7
Labels: Performance,NeedsInvestigation

Currently, there's no assembly implementation for SHA3 hashing for ARM platforms (specifically ARMv7). On ARMv7+ there are vector assembly instructions (known as NEON) available which greatly speed up the speed of SHA3 hashing. There is an upstream reference implementation (here: https://github.com/KeccakTeam/KeccakCodePackage/blob/master/lib/low/KeccakP-1600-times2/OptimizedAsmARM/KeccakP-1600-inplace-pl2-armv7a-neon-le-gcc.s) available that implements SHA3 hashing using these vector instructions and so I have ported this to Go. 

Unfortunately, there is no support in the Go assembler/dissassembler for ARMv7 vector instructions, and so I wrote a small tool (available: https://github.com/anonymouse64/asm2go) which translates native assembly code for ARM into Go's plan9 based assembly unsupported opcode syntax in order to integrate the upstream implementation in Go.

I see approximately 3-4 time speedup in SHA3 hashing on a reference Raspberry Pi 3 Model B Revision 1.2 board:

```
benchmark                          old ns/op     new ns/op     delta
BenchmarkPermutationFunction-4     19033         6054          -68.19%
BenchmarkSha3_512_MTU-4            388484        137001        -64.73%
BenchmarkSha3_384_MTU-4            279054        100177        -64.10%
BenchmarkSha3_256_MTU-4            224595        81443         -63.74%
BenchmarkSha3_224_MTU-4            210459        79196         -62.37%
BenchmarkShake128_MTU-4            181445        66482         -63.36%
BenchmarkShake256_MTU-4            199495        71572         -64.12%
BenchmarkShake256_16x-4            2704755       1094933       -59.52%
BenchmarkShake256_1MiB-4           151870003     53953383      -64.47%
BenchmarkSha3_512_1MiB-4           283838790     97048578      -65.81%

benchmark                          old MB/s     new MB/s     speedup
BenchmarkPermutationFunction-4     10.51        33.03        3.14x
BenchmarkSha3_512_MTU-4            3.48         9.85         2.83x
BenchmarkSha3_384_MTU-4            4.84         13.48        2.79x
BenchmarkSha3_256_MTU-4            6.01         16.58        2.76x
BenchmarkSha3_224_MTU-4            6.41         17.05        2.66x
BenchmarkShake128_MTU-4            7.44         20.31        2.73x
BenchmarkShake256_MTU-4            6.77         18.86        2.79x
BenchmarkShake256_16x-4            6.06         14.96        2.47x
BenchmarkShake256_1MiB-4           6.90         19.43        2.82x
```

I opened a CL providing this implementation here: https://go-review.googlesource.com/c/crypto/+/119255 however I have not received any feedback on the CL, so here I am opening this issue to hopefully get more visibility on this.