sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [Tabs] Update to match the specification
Labels: design: material,breaking change,component: tabs

Hi, I have to disagree with this change.
We are using scrollable and fullWidth together just fine, it only requires adding a minWidth to the Tab button components but otherwise it works just fine.
This is a breaking change for our layout - could this be reverted / are there other solutions to keep fullWidth and scrollable available at the same time?

_Originally posted by @olee in https://github.com/mui-org/material-ui/pull/13980#issuecomment-482465309_

 https://material.io/design/components/tabs.html
Repository: create-react-app
Issue: Check for port conflict before compilation in npm start
Labels: issue: proposal,contributions: claimed

I'd like to suggest that CRA attempts to pre-bind the port it is configured to run on when doing `npm start` before compilation starts. The compilation is slow and I often forget I have a different CRA running on 3000 (I use the default) already, so it costs some time to find out only after the server attempts to start and have to kill the hog and restart the compilation.

Obviously doing this check would still leave a window where if it passes pre-compilation, the process can be bound _during_ the compilation, but I believe the current behavior is find in that case. Checking pre-emptively before compilation should catch approximately 100.0% of cases where you forgot to kill a different process on the desired port.
Repository: go
Issue: crypto/x509: unexpected name mismatch error
Labels: Unfortunate,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?
Sorry, I'm not actually using Go itself, but I'm using etcd (https://github.com/etcd-io/etcd; apparently written in go) and got an error about subject and issuer names not matching in my certificate chain, which I believe can be tracked down to go's crypto/x509 implementation. 

### What did you do?
I tried to verify a certificate chain, where the Issuer DN of sub-CA certificate was specified using the ASN.1 type UTF8String, while the subject DN of the (renewed) CA certificate used PRINTABLESTRING. 

### What did you expect to see?
RFC 5280 (dated May 2008), section 7.1 says:
``RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however,  this specification requires a more comprehensive handling of comparison.``
And then it goes on to give details on how to compare DN's and then refers to RFC 4518 on how to compare strings of different ASN.1 types. To me, this sounds like at least comparing the exact same ASCII string when encoded as PRINTABLESTRING in one instance and as UTF8STRING in the other still should result in recognizing the two string as equal and thus the certificate chain should be validated successfully (as is the case e.g. for OpenSSL).

### What did you see instead?
I got a name mismatch, just as if the ASN.1 encoding of the DN's would be "blindly" compared byte by byte  as described by the outdated RFC 3280 (crypto/x509/verify.go:570 seems to indicate that this actually is the case). Of course, for now, there's the obvious workaround of ensuring the ASN.1 encodings of DN's are identical, but in the long run, that shouldn't be necessary (and if you're switching to a different software (version) for generating certificates, ensuring continuing compatibility might not be trivial).
Repository: three.js
Issue: Light Probe interpolation using Tetrahedral Tesselations
Labels: Enhancement

##### Description of the problem

Now that we have a LightProbe class (https://github.com/mrdoob/three.js/pull/16191), the Spherical harmonic class (https://github.com/mrdoob/three.js/pull/16187) merged as well as some shader support(https://github.com/mrdoob/three.js/pull/16152), we should explore adding a Tetrahedral tesselation method for interpolating between light probes to the renderer so that it can set the 4 SH + weights per object.

The best reference is this presentation from Unity itself:

https://gdcvault.com/play/1015312/Light-Probe-Interpolation-Using-Tetrahedral

(Referenced from here: https://docs.unity3d.com/Manual/LightProbes-TechnicalInformation.html)

It seems that given a set of light probes you just do a 3D delaunay tetrahedralization and use 3D barycentric coordinates for interpolation and you cache which tetrahedral each object is in to speed up lookups.  Pretty simple, just need a standard delaunay algorithm implemented along with a searchable tetrahedral data structure.

/ping @WestLangley @donmccurdy @richardmonette
Repository: pytorch
Issue: index_put_ take min when there are repeated indices
Labels: low priority,triaged,enhancement,module: advanced indexing

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

Assume we want to get this:
image[x,y]=p, where x, y, p are lists. For example,

x=[1, 1, 2]

y=[3, 3, 4]

p=[1, 2, 3]

It should be mentioned that image[x][y] may be updated twice, since x[0]=x[1]=1, y[0]=y[1]=3, but p[0]=1, p[1]=2. In this case, image[1][3] should be the minimum, 1.

But it seems that ~~torch.where~~ does not consider that one element in list can be updated twice or more. 

Is there an efficient way to do this? Better use OP of Pytorch. I can update image in a for loop, but it’s too slow, since the len(x) is big.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch

<!-- A clear and concise description of what you want to happen. -->

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
Repository: TypeScript
Issue: Request: Infer generics
Labels: Suggestion,Awaiting More Feedback

The request is to let `infer` support generics. 

Background:

I recently published a recursive `Pipe` and `Compose`. It offers some key advantages, including the preservation of variable names.

https://github.com/babakness/pipe-and-compose-types

Its shortcoming is in the case of generics. This is because `infer` does not work well with generics. Example


```ts
/**
 * Extracts function arguments
 */
export type ExtractFunctionArguments < Fn > = Fn extends  ( ...args: infer P ) => any  ? P : never

/**
 * Extracts function return values
 */
export type ExtractFunctionReturnValue<Fn> = Fn extends  ( ...args: any[] ) => infer P  ? P : never

type Foo = ExtractFunctionArguments< <A>(a:A, b:number) => A >
// Foo has type [ {} , number ]
```

TypeScript 3.4 improved how `pipe` and `compose` functions work with generics with higher order type inference from generic functions.

Common implementations of `pipe` and `compose` rely on parameter overloading. However, even here, there is an issue with variadic functions. See example in this issue:

#30727

The broader issue with the parameter overloading version of `pipe` and `compose` is that parameter names are lost, decreasing code clarity. The recursive version, relying on `infer` does maintain parameter names. 

Providing support generics with `infer` will present a major productivity bump and will nearly complete the community's need for the common place `pipe` and `compose` in FP patterns without compromise.

The only outlier is a small situation with parameter names on variadic functions of a minimum arity of zero as opposed to at least one. Can provide examples if needed since it is a separate issue.
Repository: godot
Issue: Weird behavior of 3x3 vs 3x3 minimal autotiling
Labels: discussion,topic:core,documentation

**Godot version:** v3.1.stable.official (installed via steam)

**OS/device including version:** Ubuntu 18.04, GTX 1080ti

**Issue description:**

The same tiling works well with "3x3 (minimal)" but breaks with "3x3", even though all the needed tiles are seemingly present.

This is what it looks like with "3x3 (minimal)"

![image](https://user-images.githubusercontent.com/123374/56052839-bd87b600-5d52-11e9-9caf-d4ef26988f20.png)

and the exact same setup only switching the tilemap from "3x3 (minimal)" to "3x3"

![image](https://user-images.githubusercontent.com/123374/56052905-e60fb000-5d52-11e9-9d19-52a11cc695bc.png)

**Steps to reproduce:**

1. Create a tilemap with the following tileset
![buggy-tilemap](https://user-images.githubusercontent.com/123374/56053014-2cfda580-5d53-11e9-84b0-8b23c4ef804a.png)
2. Create an autotile region and set the bitmasks as shown in the screenshots above
3. Set the Autotile bitmask to either "3x3" or "3x3 (minimal)"
4. Draw the pattern as shown with the tilemap

**Minimal reproduction project:**

If this is a bug and not just my misunderstanding I can provide it.
Repository: pytorch
Issue: Deprecate torch.add(tensor, value, other)
Labels: module: bc-breaking,triaged,module: numpy,module: deprecation,module: ux

## 🚀 Feature
It's confusing that add has the scale argument. Could we create a new `torch.axpy` function that does this?

## Motivation

Numpy also makes this separation: they have numpy.add, and scipy.blas.axpy.
This could also make things nicer: add can be treated as an example of a binary pointwise operation like mul, sub, div and not require any special casing for its `value` argument.

cc @ezyang @gchanan @mruberry @rgommers @heitorschueroff @cpuhrsch
Repository: flutter
Issue: Support High Contrast Text/Fonts
Labels: customer: fuchsia,platform-android,framework,engine,a: accessibility,platform-fuchsia,a: typography,P3,team-android,triaged-android

Android has an A11y setting for high contrast text/fonts.  Fuchsia would like this as well.

The framework and engine don't currently respect this flag.  We should implement it.

On Android, this is documented as forcing all fonts to black or white: https://support.google.com/accessibility/android/answer/6151855?hl=en (on my personal phone, this setting is actually labeled as `High contrast fonts`).

I do see that in some cases, where you would have white text on a white background, the setting forces a black stroke around the font:

![image](https://user-images.githubusercontent.com/8620741/56056617-92c93d80-5d11-11e9-8bbc-f9ef55383acd.png)
Repository: TypeScript
Issue: IntelliSense Parses JSDoc Namepath Part "module" as a Actual Module File Path
Labels: Needs Investigation

_- VSCode Version: 1.34.0-insider_
_- OS Version: 10.14.3 (18D109)_
_- Does this issue occur when all extensions are disabled?: Yes_

## Background
JSDoc uses [namepaths](http://usejsdoc.org/about-namepaths.html) to link variables in documentation. If you use the [@module](http://usejsdoc.org/tags-module.html) block to contain variables, then referencing those variables requires using the `module:` part in your namepaths.

## Problem
When using JSDoc namepaths involving the 'module' part, VSCode displays the module's file path within IntelliSense. I think as a result the signature's return value is also wrong, instead displaying the module's exported functions.

Screenshot of issue:

<img width="721" alt="Screen Shot 2019-04-12 at 12 44 19 PM" src="https://user-images.githubusercontent.com/8714251/56054022-ad0c1700-5d23-11e9-8bfb-10231f9ed294.png">

Is there a way to escape that module keyword? Or some way to write it so it works with VSCode? Using the full module namepath in JSDoc is required to reference types defined within module blocks, as described here https://github.com/jsdoc3/jsdoc/issues/969 and here https://github.com/jsdoc3/jsdoc/issues/1533.
Repository: rust
Issue: Add /SOURCELINK debug support on Windows 
Labels: A-debuginfo,T-compiler,O-windows-msvc,C-feature-request

It would be useful to add support for the VC++ linker option /SOURCELINK. This option embeds a json file mapping local source file paths to URLs to enable debugging on machines that might not have source. Documentation is [here](https://docs.microsoft.com/en-us/cpp/build/reference/sourcelink?view=vs-2019).

/SOURCELINK requires asomewhat recent versions of MSVC, so Rust support probably requires a version test for MSVC or some opt-in mechanism.
Repository: create-react-app
Issue: GENERATE_SERVICEWORKER environment variable
Labels: issue: proposal

Suggested new feature

**Goal**
- Be able to prevent the generation of service worker related files during a build.

**Justification**
- For the simplest applications (i.e. not using a service worker):
  - Avoid loading unnecessary resources (see #6684).
  - Remove a bit of clutter / have a more streamlined build result.
  - Simplify deployment.
- Allow a more progressive understanding for beginners.

**Proposed approach**
- Add a `GENERATE_SERVICEWORKER` environment variable (following the pattern of `GENERATE_SOURCEMAP`) that may be set via the shell or the `.env` file.
- If this variable is set to `false` then the `service-worker.js` and `precache-manifest.[hash].js` files wouldn't be generated in the `build` directory.
- Comment out by default the following lines in `index.js`:
  - `import * as serviceWorker from './serviceWorker';`
  - `serviceWorker.unregister();`
- Actually, the second line could be instead:
  - `// serviceWorker.register();`
- The explanatory comments in the `index.js` file could tell to uncomment the two lines to allow the use of a service worker (instead of renaming .unregister to .register).

**Note**
- As the service worker is presented as an _opt-in_ feature, it would be more logical that the default behavior was to _not_ generate the service worker files. In this case, the `GENERATE_SERVICEWORKER` environment would have to explicitly be set to `true` to generate service worker files.
- That said, this would cause a somewhat less "backward-compatible" behavior, so choosing what may be the best alternative remains open.

Thanks!
Repository: go
Issue: cmd/go: implicit go install of std in $GOROOT/src has weird error
Labels: NeedsInvestigation,modules

I did this by mistake (hit enter too early) and then noted the kinda weird error message:

```
bradfitz@go:~/go/src$ go install
can't load package: package std: unknown import path "std": cannot find module providing package std
bradfitz@go:~/go/src$ go install std
bradfitz@go:~/go/src$ echo $?
0
```

I guess it's correct, as "std" is some alias rather than a package, but maybe it can be made to just work, or have a more helpful error.

Low priority.

/cc @bcmills
Repository: TypeScript
Issue: Export an interface for JSON `CompilerOptions`
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

- CompilerOptions
- convertCompilerOptionsFromJson

## Suggestion

Currently TypeScript exports the [`CompilerOptions`](https://github.com/Microsoft/TypeScript/blob/97fbc87e9834b9bf12fe01bf442e16749da02d1d/lib/typescript.d.ts#L2489) interface, which represents the compiler options that can be passed in. However, since this interface uses enums, it doesn't match with the format of `compilerOptions` in the `tsconfig.json` file. I'd like to be able to use a `JsonCompilerOptions` (or some better name) interface to strictly type options in libraries that wrap TypeScript without rewriting the interface.

## Use Cases

- Libraries that wrap TypeScript like [rollup-plugin-typescript](https://github.com/rollup/rollup-plugin-typescript) can strictly type overrides for values in `tsconfig` without either requiring the user to import TypeScript enums or rewriting the interface.
- The [`convertCompilerOptionsFromJson`](https://github.com/Microsoft/TypeScript/blob/025d82633915b67003ea38ba40b9239a19721c13/src/compiler/commandLineParser.ts#L2371) function takes in `any` currently, and could instead use this hypothetical interface. 

## Examples

#### TypeScript wrapping libraries can let consumers override tsconfig options
```ts
import { Plugin } from 'rollup';
import { JsonCompilerOptions } from 'typescript';

interface Options extends JsonCompilerOptions {
    customOptions?: string;
}

export default function rollupPluginTypescript(options?: Options): Plugin;
```

#### Strict typing for `convertCompilerOptionsFromJson`
```ts
import { convertCompilerOptionsFromJson } from 'typescript';

// Type error
const opts = convertCompilerOptionsFromJson({ allowJs: 'true' }, process.cwd());
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: flutter
Issue: flutter create, app_name, AndroidManfest.xml, strings.xml
Labels: platform-android,tool,c: proposal,P2,team-android,triaged-android

When I use Android Studio to generate a new Android project, the project contains a generated file `app/src/main/res/values/string.xml` with the following content

    <resources>
        <string name="app_name">cheetah</string>
    </resources>

and the file `app/src/main/AndroidManifest.xml` contains the line

    android:label="@string/app_name"

When I create a new Flutter app, there is no `strings.xml` file generated and `android/app/src/main/AndroidManifest.xml` contains the line

    android:label="cheetah"

I suggest it would be better if the `flutter create` command generates Android-specific files that match what Android Studio generates as closely as possible. It makes working with Flutter more familiar and an easier transition for Android developers.
Repository: angular
Issue: DatePipe date issue 0001-01-01T00:00:00Z
Labels: type: bug/fix,area: common,area: i18n,freq1: low,state: confirmed,P4

# 🐞 bug report

### Affected Package
DatePipe

### Is this a regression?

### Description
When passing 0001-01-01T00:00:00Z into DatePipe it is being formatted as "12/31/0001 BC"

{{ledgerEntry.date | date: 'MM/dd/yyyy GGG':'UTC'}}

## 🔬 Minimal Reproduction
https://stackblitz.com/edit/angular-sz4zdy?embed=1&file=src/app/app.component.html

## 🔥 Exception or Error
## 🌍  Your Environment
Windows 10

**Angular Version:**
<pre><code>
@angular-devkit/architect         0.13.6
@angular-devkit/build-angular     0.13.6
@angular-devkit/build-optimizer   0.13.6
@angular-devkit/build-webpack     0.13.6
@angular-devkit/core              7.3.6
@angular-devkit/schematics        0.8.4
@angular/cdk                      6.4.7
@angular/cli                      6.2.4
@angular/flex-layout              6.0.0-beta.15
@angular/material                 6.4.7
@ngtools/webpack                  7.3.6
@schematics/angular               0.8.4
@schematics/update                0.8.4
rxjs                              6.1.0
typescript                        2.7.2
webpack                           4.29.0
</code></pre>

**Anything else relevant?**
<!-- ✍️Is this a browser specific issue? If so, please specify the browser and version. -->
Tested in FireFox and Chrome
<!-- ✍️Do any of these matter: operating system, IDE, package manager, HTTP server, ...? If so, please mention it below. -->
Nope
Repository: TypeScript
Issue: Intersection type intellisense duplicates jsdoc, rather than overriding
Labels: Suggestion,Experience Enhancement

<!-- 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.33.1
- OS Version: macOS 10.12.6

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

---

Sorry if the title isn't clear, it's tricky to put into words but obvious with code. The gist is when a `type` is extended and has the same key, the intellisense combines the documentation, rather than the "child" overriding it, like they do with `interface`. It's easier to explain with an example.

When intersecting types with the same property, the intellisense documentation shows all of the comments instead of just the latest:  

```typescript
type Duck {
  /** This is a really great duck */
  id: string
}

type Mallard = Duck & {
  /** I love this duck */
  id: string
}

const duckMan: Mallard = {
  id   // intellisense here shows "This is a really great duck I love this duck"
}
```

<img width="346" alt="Pasted_Image_4_12_19__4_05_PM" src="https://user-images.githubusercontent.com/438465/56066268-e00ed480-5d3c-11e9-9653-cf463aef5a60.png">


However, with an interface, the intellisense shows only the direct type comment, which is expected.

```typescript
interface Duck {
  /** This is a really great banana */
  id: string
}

interface Mallard extends Duck {
  /** I love this duck */
  id: string
}

const duckMan: Mallard = {
  id // Intellisense says "I love this duck"
}
```

<img width="356" alt="Pasted_Image_4_12_19__4_05_PM" src="https://user-images.githubusercontent.com/438465/56066238-c53c6000-5d3c-11e9-85df-e9900f921351.png">

I found this out because I'm using `graphql-codegen` to generate types for my GraphQL schema. It generates types, and the intellisense in some cases repeats many times.

**Expectation**

I would expect the "closest" comment doc of a `type` to override all of the others, like it does with an `interface`. If there's a reason that can't work, then at least having a uniqueness check would be good, maybe `new Set(typedocs)`)
Repository: TypeScript
Issue: "require" is not an autocomplete option for blank js file
Labels: Suggestion,Experience Enhancement

<!-- 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/ -->

Steps to Reproduce:

1. Open a blank JavaScript file
2. type `var x = r`

`require` should be the first value that pops up in the autocomplete options.

At the moment you can type out the entire word `require` and it _still_ wont appear in the autocomplete list.

This is really annoying for node developers that need to use the `require` function all the time and don't have access to an es6 environment.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<details>

<summary>Version details</summary>

Version: 1.28.0 (user setup)
Commit: 431ef9da3cf88a7e164f9d33bf62695e07c6c2a9
Date: 2018-10-05T14:58:53.203Z
Electron: 2.0.9
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64
Windows 10

</details>