sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Unable to register custom JIT Operator with AliasAnalysisKind::CONSERVATIVE 
Labels: oncall: jit,triaged

## 🐛 Bug

Cannot register a custom JIT Operator with `AliasAnalysisKind::CONSERVATIVE`. This is useful to do create operators like 
```
RegisterOperators reg({
    Operator(
        Symbol::fromQualString("ops::PrintOp"),
        [](const Node* node) -> Operation {
          return [](Stack& stack) {
            auto input = pop(stack);
            std::cout << input;
            return 0;
          };
        }),
});
```
Currently, running this fails the assert at https://github.com/pytorch/pytorch/blob/2367e71f55c8547a674b90912ffc95ca60687844/torch/csrc/jit/operator.cpp#L146-L147 

## Expected behavior

This worked before https://github.com/pytorch/pytorch/commit/bbc53bffefa56ca4e296d388c9c69aeb41548870#diff-a3542ce2ffd2bb252f5502783fbe2910L135
Adding the `op.isC10Op()` condition back passes the assert and the op works as expected.

 - PyTorch Version (e.g., 1.0): 1.3.1
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): Source
 - Build command you used (if compiling from source): python setup.py develop
 - Python version: 3.6



cc @suo
Repository: svelte
Issue: Updating a keyed {#each} triggers lifecycles in reverse order
Labels: stale-bot,temp-stale,documentation

**Describe the bug**
Updating a key list causes onDestroy/onMount lifecycles in reverse order

**Logs**
```
mount {item: "item 1"}
mount {item: "item 2"}
mount {item: "item 3"}
mount {item: "item 4"}
mount {item: "item 5"}
mount {item: "item 1"}
mount {item: "item 2"}
mount {item: "item 3"}
mount {item: "item 4"}
mount {item: "item 5"}
swapping unkeyed list1
destroy {item: "item 4"}
destroy {item: "item 5"}
swapping keyed list2
destroy {item: "item 5"}
destroy {item: "item 4"}
destroy {item: "item 3"}
destroy {item: "item 2"}
destroy {item: "item 1"}
mount {item: "item 8"}
mount {item: "item 7"}
mount {item: "item 6"}
```

**To Reproduce**
https://svelte.dev/repl/e8f06d587e3343ba8b4d1c61d94e380f?version=3.15.0

**Expected Behavior**
Updating a keyed `{#each}` block calls lifecycles in natural DOM order

**Additional context**
I'm kind of relying on the initialization order to be "correct" because I have a set of components that (Parent/Child) and the child component registers itself with the parent. It would be nice if this registration happened in order so that I could use it for things like navigation, or other features.
Repository: flutter
Issue: Can't inherit a Theme and change the Text Color for a subtree at the same time
Labels: framework,f: material design,c: proposal,P2,team-design,triaged-design

I can't find a easy way  to use my current `Theme` on a subtree text, but also be able to change that text color.

For example, lets suppose I have this widget tree:

```dart
Column(  
  children: <Widget>[
    Text(
      'Text 1',
      style: Theme.of(context).textTheme.title,
    ),
    SizedBox(height: 16,),
    Text(
       'Text 2'
       style: Theme.of(context).textTheme.body2,
    ),
  ],
),
```

And I want to change all my texts colors to white, while maintaining their inherit typography styles. Of course I can edit each one of them and change their individual colors to white, but this is tedious, specially for sub-trees with lots of texts.

Using a `DefaultTextStyle` could be a solution, but then I would have to set each individual `Text` `style` as `style: Theme.of(context).textTheme.title.copyWith(color: DefaultTextStyle.of(context).style.color)`, which is A LOT of boilerplate code, and I think that's the opposite of what Flutter stands for.

Another solution is to wrap everything in a `Theme`, then a `DefaultTextStyle`, then a `Builder`, which again, is lots of boilerplate code.

I would expect from Flutter an easy way to accomplish this, a way to just intercept and change the colors from that point forward in the sub-tree, without losing any previously defined configurations, but so far I can't see a simple way to achieve this and I think the Framework should put some thought on how to streamline this.

PS: I firstly introduced this discussion [here](https://stackoverflow.com/questions/57455620/how-to-change-the-text-color-for-a-subtree-in-flutter) and forgot to follow it up in here.
Repository: vscode
Issue: LCD: greyscale rendering in editor hover
Labels: feature-request,editor-hover,lcd-text-rendering

I tested this on Linux:

![image](https://user-images.githubusercontent.com/900690/69236823-ab95ad80-0b94-11ea-91ae-ac7a071863c6.png)

I am not sure if a fix is possible, but wanted to report it anyway.
Repository: go
Issue: runtime: timeout with GDB tests on aix/ppc64
Labels: NeedsInvestigation,compiler/runtime

https://build.golang.org/log/98c7edecebf8de8d333d58a2286729cd6d821cef
https://build.golang.org/log/66fbb96c7aee8d5b6f191319ed3d8748f238255f
https://build.golang.org/log/8fba4a8ce0f6fb1cd3170013f51ff2fdbc35d269

Our GDB on AIX is a bit unstable and it doesn't seem to like the new page allocator for an unknown reason. Even an helloworld can't be run properly. It might be related to #35451 but I think it's more a GDB problem. The team working on it has been contacted. So until now, I would like to disable these tests in order to release our builder.
Repository: terminal
Issue: Allow for custom profiles when running as admin vs user
Labels: Issue-Feature,Area-Settings,Product-Terminal

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
Having the ability to create different profiles, can be a great visual clue as to what you are doing, or where you are doing it at, e.g dev vs production.  The same can be said about running as an administrator vs a regular user.  As an admin I can potentially make damaging changes to a system, while as a normal user, I would not have the permissions.  Having the ability to not only customize a profile, but have a separate profile that would load when it is detected that I launched the terminal as administrator would be a handy visual clue that I can do something potentially destructive.  A red background for admin, or a green background as a user for example. 
<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)
Add the ability to create a different profile section for running the terminal when I right click and select "Run As Administrator" vs just normally launching the Terminal as a normal user.  

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: godot
Issue: Changing radius of RigidBody2D's shape ignores Area2D gravity
Labels: bug,confirmed,documentation,topic:physics

**Godot version:**
v3.2.beta1.official

**OS/device including version:**
Ubuntu 18.04.3 LTS

**Issue description:**
When changing the radius of a `RigidBody2D`'s `CircleShape2D`, an `Area2D`'s gravity is ignored.
![](https://i.imgur.com/v0cqcaH.gif)
(Apologies for low frame rate recording)

The yellow circle is the `Area2D` in the minimal reproduction project, the red circle is the `RigidBody2D`. Issue might be related to #33369 and #19271 as I also ran into those while running into this issue.

Also doesn't work when trying to use with non-gravity point `Area2D`.
Also doesn't work when using non `CircleShape2D` shapes for the `Area2D`.

**Steps to reproduce:**
  1. Create a `RigidBody2D` node with a `CircleShape2D` for a shape that dynamically grows
  2. Create an `Area2D` node with `Gravity Point` enabled and `Space Override` set to `Replace`
  3. Let `RigidBody2D` grow inside of `Area2D` to observe effect

**Minimal reproduction project:**
[minimal-reproduction-project.zip](https://github.com/godotengine/godot/files/3869999/minimal-reproduction-project.zip)
Repository: godot
Issue: Unsigned integer underflow in image_loader_png.cpp 
Labels: bug,topic:core,confirmed

**Godot version:**
Godot 3.2 Beta 1
**OS/device including version:**
Ubuntu 19.10
**Issue description:**
Ubsan error
```
drivers/png/image_loader_png.cpp:67:51: runtime error: implicit conversion from type 'int' of value -1 (32-bit, signed) to type 'size_t' (aka 'unsigned long') changed the value to 18446744073709551615 (64-bit, unsigned)
```
sometimes to this function p_size parameter is set to -1  (in one of Image constructors) and overflow happens when this negative value is set to PNGDriverCommon::png_to_image function which allow only to get uint32_t or uint64_t values.
https://github.com/godotengine/godot/blob/73323a2838f4978b1f91d7a941ac40ee17df2d34/drivers/png/image_loader_png.cpp#L62-L71

Putting at begging of this function this `ERR_FAIL_COND_V_MSG(p_size < 0, Ref<Image>, "Cannot convert PNG to Image resource with a negative size.");` to prevent using underflowed value  cause crash like in above

![2](https://user-images.githubusercontent.com/41945903/69082402-4cbf1f80-0a40-11ea-8831-71f7e115b573.png)

Default value -1 is used in a lot of places in Godot code
![2](https://user-images.githubusercontent.com/41945903/69083195-edfaa580-0a41-11ea-8b1c-8ec4c7744a2c.png)
![2](https://user-images.githubusercontent.com/41945903/69083202-f18e2c80-0a41-11ea-9261-efa66d7d432f.png)
![2](https://user-images.githubusercontent.com/41945903/69083211-f521b380-0a41-11ea-9be7-bd92815693e8.png)

to show this errors compile Godot with ubsan support(GCC,  LLVM), but if you have more errors you can get when you compile Godot with this branch https://github.com/qarmin/godot/tree/bb

**Steps to reproduce:**
1. Run even empty project
Repository: pytorch
Issue: Support struct that is initializable / mutable in CPP
Labels: oncall: jit,triaged

## 🚀 Feature
```@torch.jit.script
class InferenceConfig(object)
   def __init__(self):
         self.inference_threshold = 0.3
         self.inference_mode = 'unimodal'
         self.should_associate = True
         ....
```

initialize in CPP (where it is the call site of the model) and pass into the model during inference


## Motivation

Currently, we can use jit classes to initialize structs. But the struct must be initialized during the export of the model. It would be good if the structs can be initialized at inference time in CPP as it will give a lot more flexibility to the production side without having to re-export everytime

cc @suo
Repository: TypeScript
Issue: getTypeAtLocation fails for import specifiers that resolve to a type alias
Labels: Bug,API

Baseline test:

```ts
// @Filename: /a.ts
class A {}
export type B = A;

// @Filename: /b.ts
import { B as C } from './a';
```

Types baseline:

```
=== /a.ts ===
class A {}
>A : A

export type B = A;
>B : A

=== /b.ts ===
import { B as C } from './a';
>B : any
>C : any
```

Note that during the normal course of checking, everything works fine, because we don’t ask for the type of the import specifier. If someone were to _use_ `C`, we’d ask for the type of the type reference, and we’d start by resolving the alias all the way to its origin. So only when the baseline writer _specifically_ asks for the type at `B` and `C` do we hit this bug. So, it’s fairly unimportant. I investigated this and an opening the issue to document that some `any` readouts in #35200 are exhibiting some _existing_ poor behavior, and fixing it there would be out of scope.
Repository: pytorch
Issue: [docs] Newline / whitespace / comma missing in formula for PoissonNLLLoss
Labels: module: docs,triaged

![image](https://user-images.githubusercontent.com/1041752/69262021-fcbc9600-0bc2-11ea-97af-236226678212.png)
Repository: go
Issue: cmd/go: generating C header files for transitive dependencies is awkward
Labels: NeedsInvestigation,GoCommand

As discovered in [CL 208117](https://golang.org/cl/208117) (#30316), `cmd/go` (as of Go 1.14) lacks a good way to generate C header files for Go libraries in order to use them from C.

`go install -buildmode=c-archive` and `go install -buildmode=c-shared` will, as a side-effect, generate header files for the requested package. However, `-buildmode=c-archive` and `-buildmode=c-shared` today require the named package to be a `package main`, and those commands do not generate headers for the (transitive) Go dependencies of the named package.

The `-i` flag _does_ generate headers for transitive dependencies, but it _also_ has a second, unwanted side effect: it builds (and attempts to install) libraries for the transitive dependencies of the named package, including transitive dependencies in the standard library. That fails if the user cannot write to `GOROOT/pkg`, such as when a non-root user is working with a `go` tool installed as root.

As a workaround, one can run `go tool cgo -exportheader`, but `go tool cgo` accepts a list of files rather than a list of packages, and generates a number of additional outputs (normally in an `_obj` subdirectory) that the C caller does not directly need. So we're still doing extra work, just in a different location.

We should see what we can do to make it easier to generate C headers without unnecessary or unwanted side-effects.

CC @ianlancetaylor @jayconrod
Repository: three.js
Issue: NodeMaterial documentation
Labels: Documentation

I'd be willing to write documentation for node-based materials in three.js, but need to get a couple questions answered before I feel comfortable doing so.

1. Is `StandardNodeMaterial` the material that should be documented, and not `MeshStandardNodeMateral`? I believe that's true, based on https://github.com/mrdoob/three.js/pull/14572#issuecomment-430067719 and the goal that `MeshStandardNodeMaterial` will just be a drop-in replacement for `MeshStandardMaterial` but the docs would be very different if this is wrong.
2. Which syntax (see https://github.com/mrdoob/three.js/pull/17105 and https://github.com/mrdoob/three.js/pull/17265) should be documented? 
 
I'd prefer to document only one recommended material class, and one recommended syntax style, at the beginning — even if multiple will be available. I'm a bit nervous about having many syntax permutations in use so early with this API.

/cc @sunag @bhouston
Repository: flutter
Issue: Make thread_checker print out thread names on assertion
Labels: engine,platform-fuchsia,platform-windows,P2,team-engine,triaged-engine

Issue https://github.com/flutter/engine/pull/13943 implements this for Apple platforms.  We should expand it to support Fuschsia and Windows.  Chinmay has notes in the PR conversation about how one might do that.
Repository: go
Issue: x/tools: fix staticcheck warnings
Labels: NeedsFix,Tools

`gopls` enabled running diagnostics on an entire workspace, which surfaced > 200 staticcheck warnings in x/tools. We are disabling this behavior in `gopls` since it caused a real slowdown, but we should still fix all of the staticcheck warnings that we saw.
Repository: svelte
Issue: Reorderable List example
Labels: stale-bot,temp-stale,documentation

I'd like to contribute this example.  It does not work on mobile which would require DOM Touch support but I think it's still very useful.

https://svelte.dev/repl/e5d53d675f444311a908121494f51aa6?version=3.15.0
Repository: rust
Issue: error: could not evaluate constant pattern
Labels: A-associated-items,T-compiler,C-bug,A-const-eval

In the Firefox style system we have this [enum type](https://searchfox.org/mozilla-central/rev/652014ca1183c56bc5f04daf01af180d4e50a91c/servo/components/style/values/generics/grid.rs#738-753) and in the impl I'm adding a const, like so:
`    pub const INITIAL_VALUE: Self = Self::None;
`
That compiles fine. Then I'd like to add this function:
```
    pub fn is_initial(&self) -> bool {
        matches!(*self, Self::INITIAL_VALUE)
    }

```
which results in:

```
error: could not evaluate constant pattern
   --> servo/components/style/values/generics/grid.rs:770:25
    |
770 |         matches!(*self, Self::INITIAL_VALUE)
    |                         ^^^^^^^^^^^^^^^^^^^

```

which makes no sense to me given that `matches!(*self, Self::None)` compiles just fine.

(This is in a local mozilla-central build, and I think the compiler it uses is: rustc 1.39.0-nightly (6e19f3f38 2019-09-06))

BTW, why is the type required in the const declaration? Why can't I just say:
`pub const INITIAL_VALUE = Self::None;
`
It seems like the compiler should be able to deduce the type I wanted there...
Repository: go
Issue: x/tools/gopls: improve support for authoring cgo packages
Labels: FeatureRequest,gopls,Tools

Forked from #31561. This issue is not for users of cgo packages; that issue is #35720.

**Beta instructions:** https://github.com/golang/go/issues/35721#issuecomment-631669061 contains instructions on how to build a version of Go and gopls that should work well for authoring cgo packages.

Files that import "C" are not really valid Go. They depend heavily on extra information that is produced by the go tool when it builds the package. They can be parsed, but not type checked, though there is some rudimentary support for working around the issues by setting the `go/types.Config.FakeImportC` flag.

Many people have suggested that gopls use the package's GoFiles rather than its CompiledGoFiles. The GoFiles are the original (invalid) files. Using those may give a slightly better experience for people editing the package, but it will completely break anything that depends on the type information, since the package will no longer type check. We would have to evaluate the effects very carefully before making that change in the current architecture.

We could consider type checking cgo packages twice, once with the real code and once with the user's code. That would be a significant architectural change.

Alternatively, we could run the cgo tool as the .go files change to produce the real code. This is a much more robust approach, but the cost of running cgo processing may be too high, especially on large packages.

No matter what, this is a large project that will need a lot of testing and thought. It's unlikely we'll make huge improvements here very soon.
Repository: pytorch
Issue: [quantization][graph mode] SubgraphRewriter discards SourceRanges
Labels: oncall: jit,triaged

Example from test_insert_prepack_unpack: https://github.com/pytorch/pytorch/blob/ae6af8d55faa6efa6018d20fec3a4909acd36a4e/test/test_jit.py#L1194

The diff of the module's forward before and after is:

```
  graph(%self : ClassType<L>,
        %x.1 : Tensor):
    %15 : Function = prim::Constant[name="linear"]()
    %8 : int = prim::Constant[value=12]() # test/test_jit.py:1159:68
    %5 : int = prim::Constant[value=13]() # test/test_jit.py:1158:58
    %3 : float = prim::Constant[value=0.2]() # test/test_jit.py:1158:50
    %4 : int = prim::Constant[value=1]() # test/test_jit.py:1158:55
    %xq.1 : Tensor = aten::quantize_per_tensor(%x.1, %3, %4, %5) # test/test_jit.py:1158:21
    %7 : Tensor = prim::GetAttr[name="weight"](%self)
    %wq.1 : Tensor = aten::quantize_per_tensor(%7, %3, %4, %8) # test/test_jit.py:1159:21
    %11 : Tensor = aten::dequantize(%xq.1) # test/test_jit.py:1160:47
-   %13 : Tensor = aten::dequantize(%wq.1) # test/test_jit.py:1160:64
    %14 : Tensor = prim::GetAttr[name="bias"](%self)
+   %30 : Tensor = quantized::linear_prepack(%wq.1, %14)
+   %31 : Tensor, %32 : Tensor? = quantized::linear_unpack(%30)
+   %33 : Tensor = aten::dequantize(%31)
-   %r.1 : Tensor = prim::CallFunction(%15, %11, %13, %14) # test/test_jit.py:1160:20
?    ^^^                                          ^       ---------------------------

+   %34 : Tensor = prim::CallFunction(%15, %11, %33, %14)
?    ^^                                          ^

-   %rq.1 : Tensor = aten::quantize_per_tensor(%r.1, %3, %4, %5) # test/test_jit.py:1161:21
?                                               ^^^

+   %rq.1 : Tensor = aten::quantize_per_tensor(%34, %3, %4, %5) # test/test_jit.py:1161:21
?                                               ^^

    return (%rq.1)

```

We've lost source range information on the CallFunction node, meaning we're losing valuable debug info and possibly making the stack traces less interpretable

cc @suo
Repository: rust
Issue: Tone down encouragement to make everything Copy
Labels: C-enhancement,T-libs-api,A-docs

The docs for `std::marker::Copy` currently say

> When should my type be Copy?
> Generally speaking, if your type can implement Copy, it should. [...]

This piece of advice seems counter-productive to me in it's current, absolute form. It encourages a newcomer to Rust to expect the opposite of what he will experience in the ecosystem and stdlib, where things being `Copy` is the exception, not the norm. As a rule of thumb, almost all "normal" types are _not_ `Copy` to preserve move semantics (detached copies being a mistake, unless explicit through `Clone`) and the performance penalties that come with it.
Maybe a more nuanced approach to `When should my type be Copy` is better suited.


I'm sorry if this has been bikeshedded previously, feel free to shoot it down.
Repository: flutter
Issue: [path_provider] Add support for web
Labels: c: new feature,platform-web,p: path_provider,package,P3,team-web,triaged-web

We should add web support for `path_provider`
Repository: TypeScript
Issue: Avoid mentioning source types of object literals in error messages
Labels: Domain: Error Messages,Experience Enhancement

Whenever a type that originates from an object literal is encountered, we should avoid writing out the whole type. It's rarely useful, and can get painful in a lot of contexts (think React Native styles objects).

```diff
- Type '{ goobledeyGock: string, tickTock: number, wakkaFlocka: { stuff: string } }' is not assignable to 'OneType | AnotherType'.
+ This object is not assignable to 'OneType | AnotherType'.
```
Repository: godot
Issue: GraphNode does not organize children properly when child node is hidden
Labels: bug,discussion,topic:gui

**Godot version:**
3.1.1 stable
**OS/device including version:**
arch linux
**Issue description:**
The `GraphNode` type of node doesn't become smaller after a child of its is hidden
**Steps to reproduce:**
1. Create a graphnode
2. Add as many label nodes that say "test" as needed to make the graph node expand due to nodes under it needing more space than exists
3. Hide any one of the label nodes

**Minimal reproduction project:**