sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: type alias incorrectly flagged as unused when solely used in impl header
Labels: A-lints,E-needs-test,T-compiler

Consider the following code ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e36a771655d356700b8fcf9330292edd)):

```rust
type T = ();

struct S<X>(X); 

impl Clone for S<T> { fn clone(&self) -> Self { S(()) } }

fn main() {
    let s = S(());
    drop(s.clone());
}
```

Today this emits the following warning diagnostic:

```
warning: type alias is never used: `T`
 --> src/main.rs:1:1
  |
1 | type T = ();
  | ^^^^^^^^^^^^
  |
  = note: #[warn(dead_code)] on by default
```

But that type alias is not dead code. It is used in the `impl Clone for S<T> { ... }`, as one can see by trying to recompile the code after commenting out the type alias.
Repository: flutter
Issue: CustomPainter.hitTest missing size argument
Labels: framework,f: gestures,customer: solaris,c: proposal,P2,team-framework,triaged-framework

`CustomPainter.hitTest` is missing the size of the widget, making it impossible to specify custom hit test behaviour when `paint` uses its `size` argument.

Simplistic example:

```dart
class CirclePainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final center = size.center(Offset.zero);
    final borderPaint = Paint()
      ..color = const Color(0xffffffff)
      ..style = PaintingStyle.stroke
      ..strokeWidth = 2;
    canvas.drawCircle(center, size.width/2, borderPaint);
  }

  @override
  bool hitTest(Offset position) {
    final size = ???;
    final center = size.center(Offset.zero);
    return (position - center).distance < 0.5;
  }

  @override
  bool shouldRepaint(CustomPainter oldDelegate) => false;
}
```

A workaround would be to have `paint` save the size in a field, but that only works if the painter is used for a single widget only.

Is it acceptable to add a size argument to `hitTest`?

```
[✓] Flutter (Channel unknown, v1.2.2-pre.22, on Mac OS X 10.14 18A391, locale en-NL)
    • Flutter version 1.2.2-pre.22 at /Users/sander/Development/flutter
    • Framework revision dd23be3936 (9 hours ago), 2019-02-19 21:35:31 -0800
    • Engine revision f45572e95f
    • Dart version 2.1.2 (build 2.1.2-dev.0.0 c92d5ca288)
```
Repository: go
Issue: cmd/gofmt: inconsistent indentation for comments inside switch-case
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/local/ZOHOCORP/mani-pt2396/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/local/ZOHOCORP/mani-pt2396/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build688297931=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
Commented out the last case of switch with line or block comment(s).
<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
[https://play.golang.org/p/fkseigRrxYV](https://play.golang.org/p/fkseigRrxYV)

### What did you expect to see?
The last case(s) to be in their place and not go inside the scope of the previous case.
```
	switch val {
	case foo1:
		foo()
	case foo2:
		foo()
	// case bar:
		// bar()
	}

	switch val {
	case foo1:
		foo()
	case foo2:
		foo()
	/* case bar:
		// bar()*/
	}

```

### What did you see instead?
The last case(s) is aligned as if it is inside the scope of the previous case.
```
	switch val {
	case foo1:
		foo()
	case foo2:
		foo()
		// case bar:
		// bar()
	}

	switch val {
	case foo1:
		foo()
	case foo2:
		foo()
		/* case bar:
		// bar()*/
	}

```
Repository: rust
Issue: Add LLVM atomic memcpy intrinsics, expose in core/std
Labels: A-LLVM,T-lang,T-libs-api,C-feature-request,A-atomic

Expose LLVM's ["element wise atomic memory intrinsics"](https://llvm.org/docs/LangRef.html#element-wise-atomic-memory-intrinsics). In particular:
- Expose `llvm.memcpy.element.unordered.atomic` as `atomic_element_unordered_copy_memory_nonoverlapping`
- Expose `llvm.memmove.element.unordered.atomic` as `
atomic_element_unordered_copy_memory`
- Expose `llvm.memset.element.unordered.atomic` as `atomic_element_unordered_set_memory`

Expose these through functions in the `std::ptr` module. Each function is implemented by the equivalent intrinsic or by a loop of relaxed atomic operations if the intrinsic is not available on the target platform (TODO: Given this platform-specific behavior, can this also be exposed in `core::ptr`?)
- `copy_nonoverlapping_atomic_unordered`, backed by `atomic_element_unordered_copy_memory_nonoverlapping`
- `copy_atomic_unordered`, backed by `atomic_element_unordered_copy_memory`
- `write_atomic_unordered`, backed by `atomic_element_unordered_set_memory`

Previously discussed on the internals forum [here](https://internals.rust-lang.org/t/expose-llvm-atomic-memcpy-in-intrinsics/9466).

Folks with the authority to approve this: Let me know if this is OK to move forward; I'd like to post it to This Week in Rust's CFP.
Repository: create-react-app
Issue: Feature Request: Fine-tuning Terser
Labels: issue: proposal

<!--
  PLEASE READ THE FIRST SECTION :-)
-->

### Is this a bug report?

No


**Proposal:**
Support a new environment variable `TERSER_CONFIG`. A dev could set it to a JSON with [config values supported by Terser](https://github.com/webpack-contrib/terser-webpack-plugin#terseroptions) and CRA would merge default this JSON with its default Terser config.

**Example:**
1. Set `TERSER_CONFIG` to `{ "keep_classnames": true }`
1. `keep_classnames` set to `true` added to [Terser options](https://github.com/facebook/create-react-app/blob/6a5b3cdaaa7e9ee2cae358a50cf005af9d1408bd/packages/react-scripts/config/webpack.config.js#L187)

**Reasoning:**
Certain libraries rely on class names which are minified by default by Terser. It would be nice to change that without maintaining a fork of CRA for one line of code only.
I'm pretty sure there're other cases as well. Anyway it's pretty simple to add this, it would give developers more freedom, so what's the harm, right? :)

**Implementation considerations:**
If `TERSER_CONFIG` environment variable is present, do `JSON.parse` of its value and add it to Terser options [here](https://github.com/facebook/create-react-app/blob/6a5b3cdaaa7e9ee2cae358a50cf005af9d1408bd/packages/react-scripts/config/webpack.config.js#L187). Add `TERSER_CONFIG` to [this list](https://facebook.github.io/create-react-app/docs/advanced-configuration).

*Would you be willing to accept a PR for this functionality?*
Repository: pytorch
Issue: Implement Adaptive Input Representations for Neural Language Modeling
Labels: feature,module: nn,triaged

## 🚀 Feature

It would be great if you could implement [Adaptive Input Representations for Neural Language Modeling](https://arxiv.org/abs/1809.10853). This is, essentially, the same trick that PyTorch currently uses for adaptive softmax outputs, but applied to the input embeddings as well. In addition, it would be helpful to provide optional support for adaptive input and output weight tying.

## Motivation

PyTorch has already implemented adaptive representations for output. The paper shows that these representations are also useful for input. They allow faster training, and provide better accuracy. In addition, in some situations the paper shows it can be helpful to use weight-tying, which would allow this feature to be integrated nicely with the existing adaptive output functionality.

At the time the paper was written, adaptive input representations were the state of the art in language modeling.

## Alternatives

An alternative would be for this functionality to be moved in to higher level libs like fastai, but that would mean to get weight tying to work, either the existing pytorch adaptive output would have to be recreated in that library, or else that library would have to rely on using the internal data structures of the pytorch module - neither of these would be ideal.

cc @albanD @mruberry
Repository: go
Issue: x/tools/astutil: use goimports import path to import name heuristic in UsesImport
Labels: NeedsInvestigation,Tools

goimports has a sophisticated heuristic to guess a package import name from its import path. We might even eventually enshrine that heuristic in the language (https://github.com/golang/go/issues/29036).

astutil.UsesImport uses a much less sophisticated heuristic. We should move the goimports heuristic to somewhere exported (maybe in astutil?) and use it in astutil.UsesImport.

(astutil.UsesImport could also use some expanded docs, but that is another matter.)

cc @heschik
Repository: vue
Issue: make serverPrefetch() rejection trappable
Labels: improvement

### What problem does this feature solve?
Currently, rejections in `serverPrefetch` cannot be handled
eg.
```
serverPrefetch() {

   return Promise.reject('myError')
}
```


### What does the proposed API look like?
Maybe send `serverPrefetch` rejections as `renderStream` error event ?

eg.

```
const renderStream = renderer.renderToStream(context)
renderStream.on('error', err => { ... })
```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: create-react-app
Issue: Prototype warning when webpack config is modified by another package
Labels: issue: proposal
Repository: puppeteer
Issue: Requests are not intercepted when cached by Service Worker
Labels: bug,upstream,chromium,confirmed,P3

Not sure if this is by design but requests that were previously cached by service worker are not intercepted after `page.setRequestInterception(true)`.

Simplified code to reproduce:
```js
const hostname = 'http://localhost:';
const {port, proc} = await startServer(); // local implementation
const browser = await puppeteer.launch({
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox',
    '--enable-features=NetworkService',
  ],
  ignoreHTTPSErrors: true,
});

const page = await browser.newPage();

await page.goto(`${hostname}${port}`);
await page.evaluate('navigator.serviceWorker.ready');

await page.setRequestInterception(true); //toggle this
page.on('request', req => {
   console.log('requesting', req.url());
   req.continue().catch(e => e /* not intercepting */);
});

await page.reload({waitUntil: 'domcontentloaded'});

await browser.close();
```

1. Set `await page.setRequestInterception(true)`
2. Run test, only URLs not previously cached by service worker are logged
3. Set `await page.setRequestInterception(false)` (or remove Service Worker registration)
4. Run test, all URLs are logged

Are requests intercepted only when requests are sent through to the network, or is this a bug?
Repository: godot
Issue: Automatic conversion from C# array to GDScript array
Labels: enhancement,topic:dotnet

**Godot version:**
Godot 3.1 Beta 5

**Issue description:**
You can't pass arrays with types to GDScript, but you can pass object arrays. Wouldn't there be a way to automatically convert C# array to objects and pass them to GDScript, instead of doing it by hand?
Repository: electron
Issue: Add Support of Windows 10 + 'WinRT MIDI API' via commandLine.appendSwitch
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**
Prior to Windows 10, it wasn't possible to use more than one piece of software simultaneously connected to a MIDI device, for example a DAW and a MIDI device editor program. Windows 10 has a new MIDI API that developers can use which allows multiple pieces of software to simultaneously connect to a MIDI device, macOS has always allowed this...The only snag in this new Windows API is that all software needs to be using the new API for it to work, so both DAW and Editor need to use it.
This can be enabled in a browser, which supports the Web MIDI API, via chrome:flags

**Describe the solution you'd like**
Since this has been supported in Chrome for a few years now, it would be great to add support for this flag as well in Electron.

**Describe alternatives you've considered**
There doesn't appear to be an alternative solution using Electron

**Additional context**
The flag is: `use-winrt-midi-api`
set to enabled:
`app.commandLine.appendSwitch('use-winrt-midi-api', 'enabled')`
Repository: TypeScript
Issue: Give 'this' keyword suggestion the same `sortText` as class properties if inside a class
Labels: Suggestion,Experience Enhancement

From https://github.com/Microsoft/vscode/issues/66868

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.4.0-dev.20190220

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- suggestions
- completions
- sortText

**Code**
For the javascript:

```js
class Foo {
    constructor() {
        this.prop = 1;
    }

    render() {
        th
    }
}
```

* Trigger intellisense after `th` in `render`

**Expected behavior:**
`this` should be the first suggestion in VS Code

**Actual behavior:**
`render` and then `prop` are the first suggestions

The root cause of this is that the suggestion for `this` has a `sortText` of `"0"` while the one for `prop` and `render` have a `sortText` of `"1"`. This causes VS Code to sort `prop` and `render` before `this`

@amcasey @minestarks I'm not sure if the current sorting issue would also effect VS

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: opencv
Issue: Add AVX512 support
Labels: optimization,evolution

The discussion thread about https://github.com/opencv/opencv/wiki/OE-29.-Adding-AVX512-Support
Repository: godot
Issue: Highlight group titles in inspector if there any not default value
Labels: enhancement,topic:editor,usability

## Case
If there are any changed fields in inspector and group is collapsed - you can't see it quickly, without careful inspection, opening collapsed groups, etc.

## Proposal:
Highlight with color titles of groups that have changed values, like on this draft:

![inspector](https://user-images.githubusercontent.com/13387159/53185355-837a1d80-3607-11e9-8241-3feda3ce90d9.png)

For example, how it's done in Defold:

![defold_inspector](https://user-images.githubusercontent.com/13387159/53185361-883ed180-3607-11e9-91b6-f97132010d7a.png)

And I think Unity now has something similar also for prefabs.
Repository: flutter
Issue: Engine license script should work on Mac/Windows
Labels: team,engine,P3,team-engine,triaged-engine

Currently the engine licence script produces different output on Linux, Mac, and Windows, but we treat the Linux output as canonical.

The reason for the differences has to do with the differing paths of third-party dependencies depending on host OS (e.g. on Linux, we install the Android NDK, on Mac, we install a Mac NDK, with platform-specific differences in contents).

Downloading the Linux contents on Mac/Windows would work, but isn't a reasonable solution. It would be useful to catalogue the differences to see how extensive they are and whether they could be abstracted out without risking correctness.
Repository: TypeScript
Issue: DOM lib: Add support for Trusted Types API
Labels: Suggestion,Revisit

## Search Terms

Trusted Types, DOM 

## Suggestion

[Trusted Types](https://github.com/WICG/trusted-types) ([spec](https://wicg.github.io/trusted-types/dist/spec/), [introductory article](https://developers.google.com/web/updates/2019/02/trusted-types)) is a new experimental DOM API implemented within the WICG , with a working [Chrome implementation](https://www.chromestatus.com/feature/5650088592408576). 

The API creates a few new objects available on the global object in the browser, like most other web APIs ([impl in TS](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/trusted-types/index.d.ts) and [in Closure compiler](https://github.com/WICG/trusted-types/blob/master/externs/externs.js)).

Under certain conditions, controlled by a HTTP header (analogous to Content-Security-Policy behavior), the API can enable the *enforcement* - then it changes the signature of several DOM API functions and property setters, such that they accept specific object types, and reject strings. Colloquially, DOM API becomes strongly typed. 

For example, with Trusted Types `Element.innerHTML` property setter accepts a `TrustedHTML` object.

Trusted Type objects stringify to their inner value. This API shape is a deliberate choice that enables existing web applications and libraries to gradually migrate from strings to Trusted Types without breaking functionality. In our example, it makes it possible to write the following:

```js
const policy = TrustedTypes.createPolicy('foo', { 
  createHTML: (s) => { /* some validation*/; return s} 
});

const trustedHTML = policy.createHTML('bar');
anElement.innerHTML = trustedHTML

anElement.innerHTML === 'bar'
```
The above code works regardless if the Trusted Types *enforcement* is enabled or not. 

Reading from the DOM is unaffected, so `Element.innerHTML` getter returns a string. That's for practical reasons -- web applications read from DOM more often than they write to it, and only writing exposes the application to DOM XSS risks. Typing only the setters allows us to secure web applications with minimal code changes.

It's difficult to map that API using TS types (due to #2521). The only way is to change the DOM sink functions to have the `any` type, which is obviously suboptimal. 

## Use Cases

Writing a TS application that uses the Trusted Types API.

## 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: react-native
Issue: Can't modify text in TextInput onChangeText callback on Android
Labels: Component: TextInput,Platform: Android,Priority: Mid,Bug

## 🐛 Bug Report
On Android, modifying the text within the onChange (or onChangeText) callback causes corruption of the text in the TextInput. (Not tested on iOS.)

For example, I'm trying to force all caps in my TextInput field. (This is to work around the react native autoCapitalize issue described here: https://github.com/facebook/react-native/issues/8932). So if a lowercase letter is entered, I change it to uppercase in the callback. Unfortunately, *alternate* keystrokes cause the entire previous text to be duplicated, but only if the entered keystroke was lowercase.

So, when forcing all caps, entering `1234` results in `1234` showing up; entering `ABCD` results in `ABCD` showing up; but entering `abcd` results in `AABCAABCD`.

This issue disappears if assigning a Math.random() key to the TextInput; but then of course so does the keyboard focus, making this an unacceptable workaround.

## To Reproduce
See "Bug Report" and "Code Example" sections.

## Expected Behavior
One should be able to modify the value inside TextInput's change callbacks, without the text becoming corrupted on the subsequent redisplay.


## Code Example
    export default class TestScr extends Component
    {
	  constructor(props)
	  {
		super(props);
		this.state = { s6: '' };
	  }
	  textchg(event)
	  {
		const {eventCount, target, text} = event.nativeEvent;
                // one would expect the contents of s6 to display after the redraw
		this.setState({ s6: text.toUpperCase() }); 
  	  }
	  render()
	  {
                // [same behavior if using onChangeText instead of onChange]
		let jsx0 = <View style={{ flexDirection: 'row' }} key={ 'hi' }>
			<TextInput placeholder={ 'hello' } value={ this.state.s6 }
				onChange={ (evt) => this.textchg(evt) }
				keyboardType={ 'default' } />
			</View>;
			
		return (<View style={{ backgroundColor: '#ffffff', padding: 10, }}>
			<ScrollView style={{ backgroundColor: '#ffffff', }}>
				{ jsx0 }
			</ScrollView>
		</View>);
	  }
    }

## Environment
  React Native Environment Info:
    System:
      OS: Linux 3.19 Ubuntu 14.04.3 LTS, Trusty Tahr
      CPU: (4) x64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
      Memory: 626.14 MB / 15.38 GB
      Shell: 6.18.01 - /bin/tcsh
    Binaries:
      Node: 8.11.3 - /usr/bin/node
      npm: 5.6.0 - /usr/bin/npm
    SDKs:
      Android SDK:
        API Levels: 10, 16, 23, 26, 27, 28
        Build Tools: 19.1.0, 20.0.0, 21.1.2, 22.0.1, 23.0.1, 23.0.2, 26.0.3, 27.0.3, 28.0.2, 28.0.3
        System Images: android-16 | ARM EABI v7a, android-23 | Intel x86 Atom_64, android-23 | Google APIs Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom
    npmPackages:
      react: 16.6.3 => 16.6.3 
      react-native: 0.58.6 => 0.58.6 
    npmGlobalPackages:
      create-react-native-app: 1.0.0
      react-native-cli: 2.0.1
Repository: godot
Issue: Unhandled division / modulo quotient overflow causes crash.
Labels: bug,topic:gdscript,confirmed

**Godot version:**
3.1 (master), and probably any other

**OS/device including version:**
Any

**Issue description:**
As mentioned in https://github.com/godotengine/godot/pull/26113#issuecomment-465965854 executing GDScript with division / modulo operation on `LLONG_MIN` and `-1`, or simply entering it into script editor (line is executed by autocomplete) causes quotient overflow and crash with `SIGFPE` (Floating point exception: divide by zero). Division by 0 case is handled correctly.

```gdscript
 -9223372036854775808 / -1
 -9223372036854775808 % -1
```

[IDIV instruction reference](https://www.felixcloutier.com/x86/idiv)
> Overflow is indicated with the #DE (divide error) exception rather than with the CF flag.
Repository: rust
Issue: Reference interferes with optimization
Labels: I-slow,T-compiler

(This comes from a [Reddit thread](https://www.reddit.com/r/rust/comments/at6793/why_is_the_iter_version_performance_so_much/).)

In the code below, `slow` takes double the time `fast` takes. If `print` is changed to take a value rather than reference, the difference goes away.

```rust
fn print(s: &u64) {
    println!("{}", s);
}
fn fast() {
    let mut s: u64 = 0;
    for x in 0..10000000000 {
        if x % 16 < 4 {
            s += x;
        }
    }
    let s = s;
    print(&s);
}
fn slow() {
    let mut s: u64 = 0;
    for x in 0..10000000000 {
        if x % 16 < 4 {
            s += x;
        }
    }
    print(&s);
}
fn main() {
    if std::env::var("FAST").is_ok() {
        fast();
    } else {
        slow();
    }
}
```

Timings:
```
$ rustc -O main.rs
$ time FAST=1 ./main
12499999983750000000

real	0m4.334s
user	0m4.328s
sys	0m0.001s
$ time ./main
12499999983750000000

real	0m8.788s
user	0m8.776s
sys	0m0.002s
```