sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: <details> open attribute not synchronised
Labels: Type: Needs Investigation

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**What is the current behavior?**
`open` attribute does not synchronise with the virtual dom on the `details` element, when using the `details` element as a controlled component. 

I have a codesandbox [here](https://codesandbox.io/s/xl756mk82w) that demonstrates the current behaviour. 

**What is the expected behavior?**
The `open` attribute stays synchronised with the virtual dom and is added/removed.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

React: **`16.8.6`**
Browser: **Chrome**
Did this work in previous versions of React? **No**
Repository: pytorch
Issue: torch.set_flush_denormal not working on some (old) OSX machines
Labels: triaged,module: macos

## 🐛 Bug

`torch.set_flush_denormal` not working on some OSX machines

## To Reproduce

1. Find an old Macbook, for example MBP A1398 as listed in https://github.com/pytorch/pytorch/issues/19651#issuecomment-486176859
2. Run the following script on it: https://github.com/pytorch/pytorch/issues/19651#issuecomment-486170718

## Expected behavior

FTZ is set and the script runs fast
Repository: TypeScript
Issue: Invalid Semantic Links for Inferred Type Arguments
Labels: Bug

Tested in `3.5.0-dev.20190424`.

Given this code [(playground)](https://www.typescriptlang.org/play/#src=class%20Main%3CTData%3E%20%7B%0D%0A%09test1(obj%3A%20TData)%3A%20void%20%7B%7D%0D%0A%09test2(obj%3A%20Partial%3CTData%3E)%3A%20void%20%7B%7D%0D%0A%09test3%3CT%20extends%20TData%3E(obj%3A%20T)%3A%20void%20%7B%7D%0D%0A%09test4%3CT%20extends%20Partial%3CTData%3E%3E(obj%3A%20T)%3A%20void%20%7B%7D%0D%0A%7D%0D%0A%0D%0Ainterface%20Bla%20%7B%0D%0A%09foo%3A%20number%3B%0D%0A%09bar%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Aconst%20m%20%3D%20new%20Main%3CBla%3E()%3B%0D%0Am.test1(%7B%20bar%3A%201%2C%20foo%3A%201%20%7D)%3B%0D%0Am.test1(%7B%20bar%3A%20true%2C%20foo%3A%201%20%7D)%3B%0D%0A%0D%0Am.test2(%7B%20bar%3A%201%20%7D)%3B%0D%0Am.test2(%7B%20bar%3A%20true%20%7D)%3B%0D%0A%0D%0Am.test3(%7B%20bar%3A%201%2C%20foo%3A%201%20%7D)%3B%0D%0Am.test3(%7B%20bar%3A%20true%2C%20foo%3A%201%20%7D)%3B%0D%0A%0D%0Am.test4(%7B%20bar%3A%201%20%7D)%3B%0D%0Am.test4(%7B%20bar%3A%20true%20%7D)%3B):
```ts
class Main<TData> {
	test1(obj: TData): void {}
	test2(obj: Partial<TData>): void {}
	test3<T extends TData>(obj: T): void {}
	test4<T extends Partial<TData>>(obj: T): void {}
}

interface Bla {
	foo: number;
	bar: number;
}

const m = new Main<Bla>();
m.test1({ bar: 1, foo: 1 });
m.test1({ bar: true, foo: 1 });

m.test2({ bar: 1 });
m.test2({ bar: true });

m.test3({ bar: 1, foo: 1 });
m.test3({ bar: true, foo: 1 });

m.test4({ bar: 1 });
m.test4({ bar: true });
```

The references are not resolved correctly:

![image](https://user-images.githubusercontent.com/2931520/56671142-67046b00-66b4-11e9-96e0-91351209b1f4.png)

`bar` in line `20` and `23` is not linked to `Bla.bar`. It however is in line `21` and `24` where the types don't match.
This affects rename, go to definition and all other semantic actions.

This might be linked to #30507.
Repository: rust
Issue: add a disclaimer to the net::ip methods that are susceptible to change
Labels: C-enhancement,T-libs-api,A-docs

This issue has come up in https://github.com/rust-lang/rust/pull/60145
See in particular [@the8472's comment](https://github.com/rust-lang/rust/pull/60145#issuecomment-485977968).

The IP specifications are constantly changing as new [RFCs](https://www.ietf.org/standards/rfcs/) get written and accepted, and the bits of the specification that are implemented in the standard library may need to be updated accordingly. That means that in the future, we may have to change the behavior of methods that are stable (I _think_ that this is allowed by Rust's rules regarding stability as long as we don't modify the API, but someone more knowledgeable should confirm).

For this reason, it would be nice to add a disclaimer in the documentation of the methods which behavior is susceptible to change in the future, a little bit like the [Platform Specific Behavior disclaimer](https://doc.rust-lang.org/std/fs/fn.read_dir.html#platform-specific-behavior) in the doc of some IO methods.

cc @the8472
Repository: flutter
Issue: Feature request: Improve customizability of built-in widget styles
Labels: c: new feature,framework,f: material design,f: cupertino,a: quality,customer: crowd,P2,team-design,triaged-design

Some built-in widgets hard-code styles like padding, colors, and sizes. We have `material/constants.dart`, plus a mixture of `const k` values, default values in constructors, and hard-coded values inside private (and therefore not overridable) methods. This feature request is for a comprehensive and principled sweep through to find hard-coded values and make the majority customizable.

I'm in the middle of porting one of my apps to the framework, and when a widget did not offer sufficient customization, I either had to:

1. Copy the code for the built-in widget into my project and make local changes. This works, and seems relatively common practice in the community, but it's not very maintainable since my copies will not automatically benefit from bug fixes and improvements as Flutter evolves.

2. Find a third-party widget on pub that does what I want. Sometimes these widgets are mostly copies of built-in widgets with a few changes, e.g. compare https://github.com/joostlek/GradientAppBar/blob/master/lib/gradient_app_bar.dart with https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/app_bar.dart. This is slightly better but now I'm relying on package maintainers to keep the widget code in sync with Flutter.

I think doing this is important for the long-term viability of Flutter, otherwise there will be lots of Flutter apps like mine containing partial copies of the widget code in various stages of out-datedness, missing the latest bug fixes and style updates.

Here are some more examples I've found so far where I ended up pseudo-forking widget code:

* CupertinoSegmentedControl: _kHorizontalItemPadding and customize the background and text colors separately for selected and unselected widgets.
* ListTile: tile height (_RenderListTile._defaultTileHeight) and font sizes (ListTile._titleTextStyle).
* BottomNavigationBar: active and inactive label text sizes, styles, and icon sizes.
* AppBar and BottomNavigationBar: gradient backgrounds.

It would be nice to be able to make these customizations either globally using a ThemeData-like class, per-widget using constructor arguments, or by inheritance using method or getter overrides.
Repository: terminal
Issue: Ctr+Wheel behavior unpredictable using Surface Precision Mouse 
Labels: Work-Item,Product-Conhost,Area-Input,Issue-Bug

* Windows build number: 10.0.18362.53

* I am using the new Ctrl+Mouse wheel to resize the console

* What's wrong / what should be happening instead: I am using a Surface Precision mouse, which has the option to disable detent  scrolling. 

When detent scrolling is on, the console resizes as expected. With Detent scrolling off, even if I don't scroll rapidly the window is either not responsive to resizing, or responds in rare instances with a very significant resize, making the window unusable.

In MOST cases, it is simply not responsive, which only occurs infrequntly or with rapid scrolling with detent on.
Repository: godot
Issue: Lightmap Size Hint resets to 0 upon editor restart for imported meshes
Labels: bug,topic:editor,confirmed,topic:import,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
Latest commit on branch 3.1

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Lubuntu Linux, integrated Intel HD Graphics

**Issue description:**
<!-- What happened, and what was expected. -->

I'm attempting to use BakedLightmap on meshes with UV2 layers unwrapped in blender.    I can bake the lights as expected, but when I restart the editor, the light data is not displayed properly, and I cannot bake the lights again.  This is because the Lightmap Size Hint for all the imported meshes resets to zero, despite saving the project, and I have to change the size hints and bake again.  When I close a scene and reopen it, the size hint is preserved; it's only when I close the editor that the size is reset.

The documentation says the following regarding the lightmap size hint: ["If you use external meshes on import, the size will be kept."](https://docs.godotengine.org/en/3.1/tutorials/3d/baked_lightmaps.html?highlight=lightmap).  It's not clear to me what this is supposed to mean, but I assumed it was saying that this size hint is supposed to be preserved for imported meshes.

**Steps to reproduce:**

Create a mesh with 2 UV layers unwrapped in your modelling software of choice.

Import that mesh with "Light Baking" set to "Enable" in the import tab.

Create an inherited scene from your imported scene.

In that inherited scene, click to edit the mesh, and set "Lightmap Size Hint" to some positive numbers.  Save the scene

Create a scene with baked lighting, and it should bake properly with your lights visible.

Close the editor and restart it.

The mesh will now have "Lightmap Size Hint" values of zero, and the light data will not be properly aligned with the mesh.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->

[custom_uv2.zip](https://github.com/godotengine/godot/files/3113506/custom_uv2.zip)

If in the following project, the pipe model has a Lightmap Size Hint of 0 by 0, then you've encountered the bug, as I baked the lights with a lightmap of 16 by 16 pixels.
Repository: react
Issue: eslint-plugin-react-hooks suggests adding a dependency on a function that always changes
Labels: Type: Enhancement,Component: ESLint Rules,Partner

If you write:

```js
import React, {useEffect} from 'react';
const Foo = ({ orgId }) => {
  const fetchOrg = () => {
    alert(orgId);
  };
  useEffect(() => {
    fetchOrg();
  }, [orgId]);
  return <div />;
};
```

then you get the error:

> React Hook useEffect has a missing dependency: 'fetchOrg'. Either include it or remove the dependency array

But if you follow that advice and add `fetchOrg` to the dep array, you get:

> The 'fetchOrg' function makes the dependencies of useEffect Hook (at line 6) change on every render. Move it inside the useEffect callback. Alternatively, wrap the 'fetchOrg' definition into its own useCallback() Hook

Ideally it could suggest the second solution immediately, instead of suggesting a remediation that it will immediately warn about.
Repository: pytorch
Issue: View in Sequential - reasoned case for it
Labels: module: nn,triaged,enhancement

I know from googling previous issues that the PyTorch team are not keen on implementing a **View**/Reshape module to be used in **Sequential**.

What's missing from those issues / comments is reasoning for or against.

I have 20+ years in technology, including machine learning and data mining, and more recently have focussed on teaching students of all ages. I hope this experience gives some weight to my case below.

.

**1. Against**
There doesn't appear to be a good case presented by pytorch developers against a View() module that can be used inside Sequential. The best I can find is indications of a preference for users to build their own forward() functions but again this is not explained - not that I could find despite searching.

.

**2. For**
There are several arguments for.
- The Sequential approach is easy, simple, sufficient and requires little code for many tasks. Even of these tasks are relatively simple, that is not a reason against. The majority of uses of PyTorch are simple cases not the most extremely large networks. Make the 80% use case easy.
- Permitting View in Sequential doesn't prevent the developers preference for users to build their own forward functions. Both are possible, and meet the needs of different users, or users at different stages of expertise.
- Every user having to implement their own View module is wasted time, and potentially significant sources of error - which is a burden on them and also support here. If its a common task, do it once and do it well.
- There is no machine learning reason not to encourage use of View in Sequential.
- Supporting an easy path for newcomers to PyTorch is good strategy. It increases the user community and that is a positive. Barriers to adoption are not good. Python itself has become the leading numerical computing language, because of easy adoption, not because it was designed for fast computation.

Those are my thoughts. I welcome challenge based on reasoned arguments for or against - which previously appeared lacking.

Here's my own implementation which I now find doesn't handle channels... so illustrating the problem of amateur implementations like mine..

```

# from https://github.com/pytorch/vision/issues/720

class View(nn.Module):
    def __init__(self, shape):
        super().__init__()
        self.shape = shape

    def forward(self, x):
        return x.view(*self.shape)

```
Repository: pytorch
Issue: Bad overload order for zeros_like
Labels: triaged,module: pybind,module: tensor creation

In the `pytorch_torch_functions.cpp` generated code, the zeros_like binding looks like
```
static PyObject * THPVariable_zeros_like(PyObject* self_, PyObject* args, PyObject* kwargs)
{
  HANDLE_TH_ERRORS
  static PythonArgParser parser({
    "zeros_like(Tensor input, *, ScalarType dtype=None, Layout layout=torch.strided, Device device=None, bool pin_memory=False, bool requires_grad=False)",
    "zeros_like(Tensor input, *, bool requires_grad=False)",
  }, /*traceable=*/true);
...
```

In this case, the second overload will never get hit as all the arguments in the first overload have defaults. This is causing a bug where tracing will "constant-ify" device instead of correctly deriving the device at runtime from the input tensor (see #19637).

I tracked the overload sorting code to [here](https://github.com/pytorch/pytorch/blob/master/tools/autograd/gen_python_functions.py#L777) but I don't understand it. My desired behavior is to swap the order of the overloads in cases like the above.

Can anyone help me out? cc. @gchanan, @cpuhrsch, @ezyang
Repository: flutter
Issue: [google_maps_flutter] - Change MyLocation icon
Labels: c: new feature,d: api docs,p: maps,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

Hello,

I need to change the MyLocation icon. Today the plugin just change Marks icons.

I need to change the blue Circle icon to another, like Marks.

I believe I don't need to post my Doctor -v because it's not a bug, but a change.
Repository: godot
Issue: RemoteTransform resets position of nodes in the editor
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
master (edit: v3.2.4-beta4, v4.0.dev)


**OS/device including version:**
Antergos (Arch Linux), Gentoo Linux


**Issue description:**
When I move a camera which has a viewport in the editor, it moves but its position doesn't update after reload.
When I save and reopen the .tscn file, the camera has its previous position.


**Minimal reproduction project:**
[update-bug.zip](https://github.com/godotengine/godot/files/5683379/update-bug.zip)
File: car/1/car.tscn
Repository: go
Issue: cmd/go: consistently defer module path checks (including major-version matching) until import or build-list resolution
Labels: NeedsInvestigation,early-in-cycle,modules

At the moment, we validate that the major version through which a module was resolved matches the major-version suffix of the path declared in its `go.mod` file.

However, we perform that validation only sporadically (#31428), the resulting failure message (if any) can be difficult to understand in context (#30499, #30636), and a mismatch — even one involving mismatched major-version components — isn't even obviously correct if the module is involved in a `replace` directive (#26904, https://github.com/golang/go/issues/27171#issuecomment-486402787).

I suspect that we should simply not validate module paths at all when fetching a module, and instead do the validation consistently only at loading time (when we resolve explicit package imports).

At that point:
* If a module is used to replace the source code of another module, we should ensure that its path — including the major-version component — matches the module whose code it replaces.
   * Due to existing `replace` usage, we might need to relax this to allow the module path to _also_ match the path and version from which the source code was fetched, but ideally only if the `go.mod` file specifies `go 1.12` or earlier.
* If a module is used as an alias from another module path and version (#26904), then we should resolve it at the path to which the alias points during package loading, and thus the module path and major version should match that path (and the major version at which it is `require`d).
* If a module is downloaded using `go mod download`, we don't know how it is going to be used, and thus should not validate anything about its path.

CC @rsc @jayconrod @heschik @hyangah @katiehockman @leitzler @tbpg
Repository: flutter
Issue: The kernel transformer to track widget creations does not handle classes that implement instead of extend Widget.
Labels: team,framework,engine,dependency: dart,P2,team-engine,triaged-engine

The problem is `isSubclassOf`checks in the Kernel class hierarchy don't return true for classes that implement instead of extending widgets.
The kernel transformer has code like `_transformClassImplementingWidget` designed to handle classes that implement widget robustly but we are failing as the `isSubclassOf` check doesn't do what I naively thought it did based on Dart semantics.

Suggested test case to track this issue:
Add a class that implements widget and verify it is missing creation locations.
Repository: go
Issue: encoding/gob: panics encoding nil pointer - reopen
Labels: NeedsFix,FixPending

This isssue is related to https://github.com/golang/go/issues/3704# (cannot be reopened)

Currently encoding/gob panics if it is not able to do something. It's incorrect as this cannot be caught and supported on code level to provide "workaround" or failsafe activity to recover.

I'm not convinced by "that's the way it should react" in response of related message.

```
panic: gob: cannot encode nil pointer of type *makelibrary.MiddlewareRequest [recovered]
	panic: gob: cannot encode nil pointer of type *makelibrary.MiddlewareRequest
```

The code:

```
func SerializeObject(object interface{}) []byte {
	var serializationBuffer bytes.Buffer
	enc := gob.NewEncoder(&serializationBuffer)
	err := enc.Encode(object)
	if err != nil {
		log.Println("Cannot serialize object. Error is: " + err.Error())
		return []byte{}
	}
	return serializationBuffer.Bytes()
}
```
As you see I don't care about panic here. It can be empty in my case.

This error could be supported on code level if it's catchable - in my context for example I can skip object that has nil pointer because it will not be deserialized back.

Platform details:
Go version: 1.12
GOOS = linux
GOARCH = amd64

I would expect to have error returned so it will be caught and workaround could be done.
Repository: go
Issue: cmd/compile: utf8.DecodeRune should be fast/slow-path inlineable
Labels: Performance,NeedsFix,compiler/runtime

We manually partially inline utf8.DecodeRune in a few places in the tree. For example, in `bytes.EqualFold`, we have:

```go
		if s[0] < utf8.RuneSelf {
			sr, s = rune(s[0]), s[1:]
		} else {
			r, size := utf8.DecodeRune(s)
			sr, s = r, s[size:]
		}
```

It'd be nice to rewrite `utf8.DecodeRune` like this:

```go
func DecodeRune(p []byte) (r rune, size int) {
	if len(p) > 0 && p[0] < RuneSelf {
		return rune(p[0]), 1
	}
	return decodeRuneSlow(p)
}
```

and then let mid-stack inlining take it from there. (And delete all the manual partial inlining.)

Unfortunately, this has a cost of 89, over the budget of 80.

This is basically just another variant of https://github.com/golang/go/issues/17566, but I'm filing it separately since that issue is super noisy.

cc @bradfitz @mvdan @dr2chase
Repository: TypeScript
Issue: 'Omit' should alias a distinct mapped type (for display purposes)
Labels: Suggestion,Help Wanted,Effort: Moderate,Experience Enhancement,Fix Available

Today, `Omit` will expand to `Pick<Exclude<...>, ...>` in quick info, error messages, etc. which is gross.

By defining `Omit` as its own conditional type, we can get a slightly nicer display, though it will introduce duplication of code between the two helpers.
Repository: vscode
Issue: FileSystemWatcher fires events to extensions before text documents are updated
Labels: api,under-discussion,file-watcher

Version: 1.33.1 (user setup)
Commit: 51b0b28134d51361cf996d2f0a1c698247aeabd8
Date: 2019-04-11T08:27:14.102Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763


I can repro this debugging the C/C++ extension ( https://github.com/Microsoft/vscode-cpptools ).

In the handling of an onDidChange event from a FileSystemWatcher, we are loading the contents of that file (using vscode.workspace.openTextDocument), but the contents that are returned are outdated (prior to the change).

This repro's for me regardless of whether the file is currently open for edit.  If open, I see updated content in the UI.  Even if I wait to step over openTextDocument until after the change is apparent in the UI, I still get the old contents.
Repository: node
Issue: Discussion: private fields and util.inspect
Labels: util

Now that we have support for private class fields... we need to figure out how (and if) we want to support them with regards to `util.inspect()`...

Right now, those properties are hidden from the output even when `showHidden` is `true`...

```js
class F { #foo = 1; }
const f = new F()
util.inspect(f)  // returns 'F {}'
util.inspect(f, { showHidden: true }) // returns 'F {}'
```

How should we handle these with inspect?
Repository: go
Issue: proposal: net: export isDomainName
Labels: Proposal,Proposal-Hold

I'd like to essentially re-open https://github.com/golang/go/issues/2880 for consideration.

The motivating factor here is I have yet to find a good canonical piece of code which callers can leverage to validate an input name against [RFC 1035](https://tools.ietf.org/html/rfc1035). Searching around for such code yields a whole world of regexes people have come up with that don't fully implement the spec. `net.isDomainName` may not be perfect either (see: https://github.com/golang/go/issues/17659), but it would do a better job that what I'm finding out there otherwise (and be faster).

The original issue got kicked around a lot and eventually closed, so I'm hoping for some feedback one way or the other this time around.

Thanks!
Repository: rust
Issue: Consider shipping llvm-rc.exe on windows.
Labels: A-LLVM,O-windows,C-enhancement,T-compiler,T-dev-tools

I wonder if it's feasible to ship llvm-rc.exe for windows targets. This tool has limited capacity compared with windres.exe from MinGW and rc.exe from MSVC, but i think it can make steps towards solving https://github.com/rust-lang/rfcs/issues/721 or similar issues.