sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: use `evaluate_obligation` to decide when to do unsized coercions
Labels: C-enhancement,A-trait-system,T-compiler,A-coercions,T-types,S-types-tracked

As part of the coercion logic, we sometimes invoke `coerce_unsized`:

https://github.com/rust-lang/rust/blob/cb1ce7ddf8e791faddc9760ca505d513ce1c00c9/src/librustc_typeck/check/coercion.rs#L457

This would e.g. coerce from `&[T; 32]` to `&[T]` or from `Arc<T>` to `Arc<dyn Trait>` where `T: Trait`. To decide whether or not we are going to do this, we want to check if `Arc<T>: CoerceUnsized<Arc<dyn Trait>>` is implemented (or something like that). We do this in this funky little loop here:

https://github.com/rust-lang/rust/blob/cb1ce7ddf8e791faddc9760ca505d513ce1c00c9/src/librustc_typeck/check/coercion.rs#L538-L552

This kind of pulls out all the (transitive) requires to prove `CoerceUnsized` and ignores the rest. However, if we ever hope to define coercions in terms of the trait system, what we really *ought* to be doing is using an `evaluate_obligation` check.

Hopefully we can get away with this backwards compatibly.

@eddyb told me at some point -- iirc -- that the reason this loop exists is for diagnostics. So making this change may require some work on that point.

cc @leodasvacas @mikeyhew
Repository: godot
Issue: Audio with compress mode set to RAM always plays from the beginning
Labels: bug,confirmed,topic:audio

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
47d4a01


**Issue description:**
I don't know if this is just a limitation or not, but if a audio file has its compress mode set to RAM (Ima-ADPCM), it will ignore the `from_position` argument in the `play` method.
Repository: electron
Issue: Disallow permission requests by default
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**

Electron is known for being insecure. It should come with better security defaults.

**Describe the solution you'd like**

The Electron [security checklist](https://github.com/electron/electron/blob/master/docs/tutorial/security.md#4-handle-session-permission-requests-from-remote-content) recommends disallowing permission requests for features the app doesn't need. It's a big security gap that this is opt-out rather than opt-in.

I recommend making all permission requests denied by default and let the user instead explicitly opt into what they need. That's also how Chrome works.

So the default would become something like this:

```js
const {session} = require('electron');

session.defaultSession.setPermissionRequestHandler((webContents, permission, callback) => {
	callback(false);
});
```
Repository: react
Issue: Provide ways to do post-mortem analysis of “Maximum update depth exceeded” error in production.
Labels: Type: Feature Request

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
Feature

**What is the current behavior?**
Our error logging systems has been reporting this error in production: “Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.”

However, we can’t reliably reproduce this error and it only affects a small percentage of our users. Moreover, we have more than 1,000 in-house components and several third-party components. So, it’s impractical to audit every single component to find out what caused it.

**What is the expected behavior?**
It would be much easier for us to debug if, when the nested update count exceeds 1,000 (current NESTED_UPDATE_LIMIT), we could see what components are involved in this nested update chain.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
We are using React 16.3.1.
Repository: TypeScript
Issue: [Regression] TS2562 - mixins cannot accept generic types
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  2.6.0 and more

**Search Terms:** mixin, 2.6.

**Code**

```ts
export interface Constructor<T = any> extends Function {
  new(...args: any[]): T;
}

class A<T> {
  public a: T;
}

class B<T> {
  public b: T;
}

function Mixin<T>(...classes: any[]): Constructor<T> {
  return function() {
    // whatever, not the purpose of the demonstration
  } as any;
}

interface IAB<T, U> extends A<T>, B<U> {}
// on typescript 2.6.0 and more, its no more possible to use generic types into mixins....
class AB<T, U> extends Mixin<IAB<T, U>>(A, B) {
}

// on typescript 2.6.0 we're forced to write
// class AB<T, U> extends Mixin<IAB<any, any>>(A, B) {}
//  so we loose type checking...

// intentional type error
class testClass extends AB<boolean, string> {
  public a: number; // before 2.6.0 => type of 'a' properly detected as wrong, boolean expected
}
```

**Expected behavior:**
Like before typescript 2.6.0, extending a class with a mixin which takes generic types should be allowed.
Using mixin is a really common usage in js/ts to build classes which implement/inherit properties from more than one classe (sometimes named 'factories'). Before 2.6.0, typescript properly detected the union of class having generic types, but currently this generates TS2562 errors, so its no more possible to construct typed generic mixins.

In a more generic way:
```ts
function A<T>() {
  return class {};
}

// should be allowed
class B<T> extends A<T>() {}
```

**Actual behavior:**
TS2562, Base class expression cannot reference class type parameters (on T and U)


**Playground Link:** [here](https://www.typescriptlang.org/play/#src=export%20interface%20Constructor%3CT%20%3D%20any%3E%20extends%20Function%20%7B%0D%0A%20%20new(...args%3A%20any%5B%5D)%3A%20T%3B%0D%0A%7D%0D%0A%0D%0Aclass%20A%3CT%3E%20%7B%0D%0A%20%20public%20a%3A%20T%3B%0D%0A%7D%0D%0A%0D%0Aclass%20B%3CT%3E%20%7B%0D%0A%20%20public%20b%3A%20T%3B%0D%0A%7D%0D%0A%0D%0Afunction%20Mixin%3CT%3E(...%20_classes%3A%20any%5B%5D)%3A%20Constructor%3CT%3E%20%7B%0D%0A%20%20return%20function()%20%7B%0D%0A%20%20%20%20%2F%2F%20whatever%0D%0A%20%20%7D%20as%20any%3B%0D%0A%7D%0D%0A%0D%0A%0D%0Ainterface%20IAB%3CT%2C%20U%3E%20extends%20A%3CT%3E%2C%20B%3CU%3E%20%7B%7D%0D%0Aclass%20AB%3CT%2C%20U%3E%20extends%20Mixin%3CIAB%3CT%2C%20U%3E%3E(A%2C%20B)%20%7B%0D%0A%20%20%0D%0A%7D)

**Related Issues:** Partially related https://github.com/Microsoft/TypeScript/issues/19668
Repository: pytorch
Issue: [Caffe2]How to set lr_mult and decay_mult in Conv layer?
Labels: caffe2

In facebookresearch/detectron, I see a conv layer is add by:

conv_rpn_fpn = model.Conv(
         bl_in,
         'conv_rpn_fpn' + slvl,
         dim_in,
         dim_out,
         kernel=3,
         pad=1,
         stride=1,
         weight_init=gauss_fill(0.01),
         bias_init=const_fill(0.0)
 )

However, I don't find any parameter statement about lr_mult and decay_mult like that in a caffe conv layer. Could you please give me an example? Thanks a lot!







If you have a question or would like help and support, please ask at our
[forums](https://discuss.pytorch.org/).

If you are submitting a feature request, please preface the title with [feature request].
If you are submitting a bug report, please fill in the following details.

## Issue description

Provide a short description.

## Code example

Please try to provide a minimal example to repro the bug.
Error messages and stack traces are also helpful.

## System Info
Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

- PyTorch or Caffe2:
- How you installed PyTorch (conda, pip, source):
- Build command you used (if compiling from source):
- OS:
- PyTorch version:
- Python version:
- CUDA/cuDNN version:
- GPU models and configuration:
- GCC version (if compiling from source):
- CMake version:
- Versions of any other relevant libraries:
Repository: pytorch
Issue: the latest version of caffe2,  Which file is  the function loadToNCHW() 
Labels: caffe2

I installed caffe2 with https://github.com/pytorch/pytorch.git.  the function loadToNCHW() didn't find.
Repository: go
Issue: reflect: permit unexported fields in StructOf
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.10.2 linux/amd64

### Does this issue reproduce with the latest release?

yes

### What did you do?

```
package main

import "fmt"
import "reflect"

func main() {
	type T = struct {
		x int
	}
	fmt.Println(reflect.TypeOf(T{})) // struct { x int }
	
	var n int
	tn := reflect.TypeOf(n)
	// panic: reflect.StructOf: field "x" is unexported but missing PkgPath
	tt := reflect.StructOf([]reflect.StructField{
		{Name: "x", Type: tn, Anonymous: false},
	})
	fmt.Println(tt)
}
```

### What did you expect to see?

not panic.

### What did you see instead?

panic.

If it really should panic, it should be documented.
Repository: go
Issue: reflect: the string representation of the type with anonymous fields and created by StructOf looks the fields are not anonymous
Labels: NeedsInvestigation,compiler/runtime

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.10.2 linux/amd64

### Does this issue reproduce with the latest release?

yes

### What did you do?

```
package main

import "fmt"
import "reflect"

type MyInt int

func main() {
	type T = struct {
		MyInt
	}
	fmt.Println(reflect.TypeOf(T{})) // struct { main.MyInt }
	
	var n MyInt
	tn := reflect.TypeOf(n)
	// panic: reflect.StructOf: too many methods
	tt := reflect.StructOf([]reflect.StructField{
		{Name: "MyInt", Type: tn, Anonymous: true},
	})
	fmt.Println(tt) // struct { MyInt main.MyInt }
}
```

### What did you expect to see?

```
struct { main.MyInt }
struct { main.MyInt }
```

### What did you see instead?

```
struct { main.MyInt }
struct { MyInt main.MyInt }
```
Repository: vscode
Issue: Add commands to outline elements
Labels: feature-request,outline

The outline view should offer commands that can be run straight from an element. E.g. rename but also triggering things like find references et al. Similar to the editor-context-menu this could be made open for contributions
Repository: go
Issue: x/build/cmd/relui: collect open source NOTICES into top-level NOTICES file?
Labels: help wanted,Builders,NeedsFix

We should probably make x/build/cmd/release collecting all the misc LICENSE/NOTICE files from the packages we depend on and concatenate them all together into one top-level NOTICES file next to our LICENSE file in Go's release.

We'd also need to make such NOTICE files for each directory where the notice is currently in the source code at the top.

Look at Debian's packaging of Go to find the list.

/cc @rsc @FiloSottile @ianlancetaylor @andybons @bcmills
Repository: go
Issue: proposal: io: add OnceCloser helper
Labels: Proposal,Proposal-Hold

Proposal, to add to the `io` package:

```go
// OnceCloser returns a Closer wrapping c that guarantees it only calls c.Close
// once and is safe for use by multiple goroutines. Each call to the returned Closer
// will return the same value, as returned by c.Close.
func OnceCloser(c Closer) Closer {
	return &onceCloser{c: c}
}
```

With implementation like:

```go
type onceCloser struct {
	c    Closer
	once sync.Once
	err  error
}

func (c *onceCloser) Close() error {
	c.once.Do(c.close)
	return c.err
}

func (c *onceCloser) close() { c.err = c.c.Close() }
```

This would let people safely write code like:

```go
       oc := io.OnceCloser(file)
       defer oc.Close()

       ....
       if err != nil {
             return nil, err
       }
       if err := oc.Close(); err != nil {
             return nil, err
      }
```

... without worrying about double calls to `file.Close`, which is undefined since https://golang.org/cl/8575043

https://golang.org/pkg/io/#Closer

> // The behavior of Close after the first call is undefined.
> // Specific implementations may document their own behavior.

/cc @bcmills @mpvl @ianlancetaylor
Repository: flutter
Issue: FlutterDriver.scrollUntilVisible scrolls when the item to find is onscreen
Labels: tool,t: flutter driver,P2,team-tool,triaged-tool

`scrollUntilVisible` should not attempt to scroll when the item to find is onscreen, but we often see one extra scroll. This is particularly problematic when the item to find is at the top of the screen, in which case we may scroll it offscreen, resulting in a failure in the [`scrollIntoView` call](https://github.com/flutter/flutter/blob/ae8586cfa1cdbfda89048ecf6f148e401a15d4a1/packages/flutter_driver/lib/src/driver/driver.dart#L493) returns from that function.
Repository: rust
Issue: Doctests don't work in bin targets, non-public items
Labels: T-rustdoc,C-enhancement,A-doctests

It's surprising that doctests sometimes don't run at all, and there's no warning about this.

```sh
cargo new foo --bin
```

```rust
/// ```rust
/// assert!(false);
/// ```
fn main() {
    println!("Hello, world!");
}
```

```sh
cargo test --all
```

I'd expect the above to fail, but it looks like the doc-comment code is never ran. Even if I explicitly enable doctests for the binary:

```toml
[[bin]]
name = "foo"
path = "src/main.rs"
doctest = true
```

they still aren't run.

(moved from https://github.com/rust-lang/cargo/issues/5477)
Repository: TypeScript
Issue: Simplify error messages against intersections of weak types
Labels: Suggestion,Domain: Error Messages,Experience Enhancement

I spoke a bit with @sandersn about ways we can tackle the type madness issue (#14662). I noted that JSX scenarios are much more broadly applicable right now and are pretty prevalent given the sorts of type arithmetic we see a lot of in the React community. :smiley: 

# Problem: JSX optional attributes make errors too hard to read

```tsx
interface FooProps {
    name: string;
    age: number;
}

class Foo extends React.Component<FooProps> {
    constructor(props: FooProps) {
        super(props)
    }
    render() {
        const {name, age} = this.props;
        return <div>I'm {name} and am {age} years old</div>;
    }
}

// Type '{ blah: number; }' is not assignable to type 'IntrinsicAttributes & IntrinsicClassAttributes<Foo> & Readonly<{ children?: ReactNode; }> & Reado...'.
//   Type '{ blah: number; }' is not assignable to type 'Readonly<FooProps>'.
//     Property 'name' is missing in type '{ blah: number; }'.
<Foo blah={10} />;
```

# Proposal

When doing relation checks against an intersection target, if a check fails, see if relating against the same type with weak types removed would result in the same outcome. If so, use *that* comparison when elaborating types.

The great part is that this actually solves a broader set of problems than just JSX.
Repository: pytorch
Issue: Inconsistent interactions of PyTorch tensors and NumPy ops
Labels: triaged,module: numpy

```python
import numpy
import torch
type(numpy.sum([torch.tensor(0, requires_grad=True)]))  # returns torch.Tensor
type(numpy.sum([torch.tensor(0)]))                      # returns numpy.int64
```

cc @mruberry @rgommers @heitorschueroff
Repository: go
Issue: os: ambiguous documentation of type FileMode
Labels: Documentation,help wanted,NeedsFix

### What version of Go are you using (`go version`)?
N/A

### Does this issue reproduce with the latest release?
Yes ( [latest document online](https://golang.org/pkg/os/#FileMode) )

### What operating system and processor architecture are you using (`go env`)?
N/A

### What did you do?
Read [documentation of the FileMode bitfields](https://golang.org/pkg/os/#FileMode)

### What did you expect to see?
Either
- *...The values of **the lowest 9 bits** should be considered part of the public API...*
OR
- *...The values of **any of the 32 bits already defined in the `const` listing below** should be considered part of the public API...*

### What did you see instead?
- *...The values of **these** bits should be considered part of the public API...*


The documentation as currently written is clearly open to interpretation. Further discussion: https://botbot.me/freenode/go-nuts/2018-05-16/?msg=100120706&page=5
Repository: TypeScript
Issue: Support `export { x as default }` in namespace declarations
Labels: Suggestion,In Discussion

<!-- 🚨 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

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

<!-- A summary of what you'd like to see added or changed -->
options for allow use import { xxx } from 'yyy'; when TS2497 resolves to a non-module entity

without warn or use `// @ts-ignore`

```ts
Error:(11, 19) TS2305: Module has no exported member 'isGitRoot'.
Error:(11, 36) TS2497: Module resolves to a non-module entity and cannot be imported using this construct.
```

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

<!-- Show how this would be used and what the behavior would be -->

demo.ts
```ts
import gitRoot, { isGitRoot } from 'git-root2';
```

[git-root2](https://github.com/bluelovers/git-root2/blob/9e80cb80547d1aab01b19235f161852e198a8fe4/index.ts#L25-L52)

```ts
declare function gitRoot(cwd?: string): string;
declare namespace gitRoot {
    function isGitRoot(target: string): boolean;
    function async(cwd?: string): Promise<string>;
}
declare const _default: typeof gitRoot & {
    gitRoot(cwd?: string): string;
    default(cwd?: string): string;
    async(cwd?: string): Promise<string>;
};
export = _default;
```

## 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
 [ ] This could be implemented without emitting different JS based on the types of the expressions
 [ ] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: pytorch
Issue: [Caffe2] modify op in the net from init and predict files
Labels: caffe2

I have a trained model stored as init.pb and predict.pb files.
I load them successfully and print predict. 
one of the operations appears to be:
```
op {  
  input: "300" 
  input: "298"
  output: "301"
  name: ""
  type: "Add"
  arg {
    name: "broadcast" 
    i: 1
  }
}
```
I would like to change the model so that the broadcast will be disabled, since it isn't supported by snpe and my tensors have the same shape anyway.
Can you please advice how do I do this?

Thanks!
Repository: pytorch
Issue: checkpoint(function, *args) should have the same requires_grad as function(*args)
Labels: module: checkpoint,module: autograd,triaged

## Issue description

In principle, to my understanding, checkpoint(function, *args) should behave exactly the same during forwarding as function(*args).

However, now, if the all the inputs have requires_grad to be False, the output will also checkpoint(...) will also have requires_grad to be False. While function may involve other trainable parameters, function(*args) will have requires_grad True output even all the inputs are requires_grad False.

should be fixed if replacing the no_grad with `detach_variable(run_function(*args))` (although detach_variable doesn't accept non tuple right now)

## Code example

```
import torch
from torch.utils.checkpoint import checkpoint

m = torch.nn.Linear(4,3)
x = torch.randn(10,4)

z1 = checkpoint(lambda _:m(_), x)
print(z1.requires_grad)

z2 = m(x)
print(z2.requires_grad)
```

## System Info

PyTorch version: 0.5.0a0+a61d4a3
Is debug build: No
CUDA used to build PyTorch: None

OS: Mac OSX 10.13.1
GCC version: Could not collect
CMake version: version 3.9.4

Python version: 2.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip] numpy (1.14.2)
[pip] torch (0.5.0a0+a61d4a3, /Users/ruotianluo/anaconda/lib/python2.7/site-packages)
[pip] torchvision (0.2.0)
[conda] torch                     0.5.0a0+242f6c3           <pip>
[conda] torch                     0.5.0a0+a61d4a3           <pip>
[conda] torch                     0.4.0a0+dd91d57           <pip>
[conda] torch                     0.4.0a0+4a9e02f           <pip>
[conda] torch                     0.4.0a0+460e8cd           <pip>
[conda] torch                     0.4.0a0+4dd29ac           <pip>
[conda] torchvision               0.2.0                     <pip>

cc @ezyang @SsnL @albanD @zou3519 @gqchen
Repository: go
Issue: cmd/gofmt: better error message when gofmt is out of date
Labels: NeedsInvestigation

It's not uncommon to run an old gofmt that may not be up-to-date with the latest syntactic changes (most recently, alias type declarations). There may be future (Go 2) changes where this becomes more acute.

When gofmt reports a syntax error, we may want to compare the gofmt (build time) version with the current "go version" and possibly report significant version discrepancies with the error ("please update gofmt").

Reminder issue to look into this.