sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: support @tip as an alias to "the latest development version"
Labels: NeedsDecision,FeatureRequest,GoCommand,modules

### Problem statement

Historically, one would use `go get -d github.com/foo/bar` and the repository would be checked out inside `GOPATH`. What was nice about it is that the default branch would be used, usually meaning `master` on git, for example.

Now that we're in the world of modules, we can use `go get -d github.com/foo/bar@latest` to grab that module's latest released version, regardless of the VCS usptream is using.

However, note that "the latest released version" is not quite the same. If one wants to use the latest available code ignoring releases, the general advice is to use `@master`. This is equivalent to using the version at the commit pointed to by the branch `master`.

While git is massively popular and `master` is also a very popular default branch name for it, this method has significant downsides. For example:

* It likely won't work with other VCS systems, since they often don't have a `master` branch/tag/ref
* A git repository could easily have a `master` branch but have a different default branch, leading to confusing behavior
* Since many git repositories are replacing `master` with `main` (as will `git`, eventually!), it will be hard to remember what modules should be used with `@master` versus `@main`

In other words, we have no way to say "the latest development version", usually meaning the latest commit from the default branch.

### Proposed solution

Just like `@latest` is a special version, I think we should add another to have the meaning above: the latest development version.

Naming this special version might be hard. I can see arguments in favor of a number of options:

1) `@master`, since it already has this meaning for many people, and many users and scripts already use it. However, it goes against the effort to replace `master` with `main` in git.
2) `@main`, as an alternative to `@master` following git.
3) `@HEAD`, which means "default branch" in git. Very weird to have it be all-caps though, so maybe `@head` instead.
4) `@tip`, borrowing from the hg/mercurial terminology
5) `@dev`, `@devel`, `@unstable`, or some other English word meaning "latest version ignoring stable releases"

I personally am in favor of `@tip` because it's short to type, and because it's very unlikely to cause problems with existing branch/tag names in git, given how such a name would be very confusing to anyone familiar with hg. I'm not sure if it would cause any problems with people currently using `@tip` with hg repositories.

### Related issues

* https://github.com/golang/go/issues/36811 - pkgsite's support for "the latest development version" would likely improve with this change, from the user's perspective and for VCS portability

cc @myitcv @rogpeppe @ianthehat @bcmills @jayconrod
Repository: create-react-app
Issue: Proposal: always show network info, even when there are errors/warnings
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Run `npm start` on a project. Observe that the network info is displayed that lets you know the URL you can visit the project on other devices on the same network.

Now, introduce a linting warning to your project. Run `npm start`. Observe that no network info is displayed; it has been replaced with the warning.

### Describe the solution you'd like

The network info should be displayed always. If there are warnings, those should appear below the network info.

### Describe alternatives you've considered

Not doing this is another option.

### Additional context

Although it would be nice if every project had no linting warnings, it is not always possible in practice to ensure this. Even projects with linting warnings sometimes need to be tested on other devices, and the current behavior makes this more difficult to do.
Repository: react-native
Issue: [Android] textAlignVertical doesn't work on nested text
Labels: Platform: Android,Platform: Linux,Needs: Triage :mag:,Never gets stale

This issue has already been reported (#18790), but closed for "stalling". As of React Native 0.63.3, the bug still exists.

## Description

`textAlignVertical` works fine when set on the top-most Text component. However, if you have any nested texts (a common use case), you can not override the alignVertical in the child Text component.

## React Native version:

System:
    OS: Linux 5.4 Manjaro Linux
    CPU: (8) x64 Intel(R) Core(TM) i7-8809G CPU @ 3.10GHz
    Memory: 1.54 GB / 31.29 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.15.0 - /tmp/xfs-2fbb69bb/node
    Yarn: 2.2.2 - /tmp/xfs-2fbb69bb/yarn
    npm: 6.14.8 - /usr/bin/npm
    Watchman: 4.9.0 - /usr/bin/watchman
  SDKs:
    Android SDK:
      API Levels: 28, 29
      Build Tools: 28.0.3, 29.0.0, 29.0.2, 29.0.3, 30.0.0, 30.0.1
      System Images: android-22 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom
      Android NDK: Not Found
  IDEs:
    Android Studio: 4.1 AI-201.8743.12.41.6858069
  Languages:
    Java: 1.8.0_265 - /usr/bin/javac
    Python: 3.8.6 - /usr/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1 
    react-native: ^0.63.3 => 0.63.3 
  npmGlobalPackages:
    *react-native*: Not Found

## Steps To Reproduce

Create an app which renders the following component:
```jsx
export default function App() {
  return (
      <Text>
        <Text>This is text</Text>
        <Text style={{textAlignVertical: 'top', fontSize: 10}}>sup!</Text>
      </Text>
  );
}
```

## Expected Results

The "sup!" Text node should be aligned to the top edge of the line. Instead, "sup!" is aligned with the baseline:

### Web (expected)
![2020-11-12-141856_128x45_scrot](https://user-images.githubusercontent.com/3646758/98973102-118beb00-24f2-11eb-8d7d-ef120d9be586.png)

### Android

![2020-11-12-141936_167x69_scrot](https://user-images.githubusercontent.com/3646758/98973131-1d77ad00-24f2-11eb-8034-b5bdbe104a99.png)


## Snack, code example, screenshot, or link to a repository:

https://snack.expo.io/@jsamr/android-textalignvertical
Repository: rust
Issue: Unused local not eliminated by MIR optimizations
Labels: T-compiler,C-bug,A-mir-opt

The following example (https://godbolt.org/z/54ze7P) has an unnecessary copy of `_1`:
```rust
fn should_opt(_1: bool) -> () {
    debug input => _1;                   // in scope 0 at ./example.rs:1:15: 1:20
    let mut _0: ();                      // return place in scope 0 at ./example.rs:1:28: 1:28
    let _2: bool;                        // in scope 0 at ./example.rs:2:9: 2:10
    scope 1 {
        debug x => _2;                   // in scope 1 at ./example.rs:2:9: 2:10
    }

    bb0: {
        StorageLive(_2);                 // scope 0 at ./example.rs:2:9: 2:10
        _2 = _1;                         // scope 0 at ./example.rs:2:13: 2:18
        _0 = const ();                   // scope 0 at ./example.rs:1:28: 3:2
        StorageDead(_2);                 // scope 0 at ./example.rs:3:1: 3:2
        return;                          // scope 0 at ./example.rs:3:2: 3:2
    }
}
```

I would have expected `_2 = _1` to be eliminated in the optimized MIR, as it appears unused besides storage markers.
Repository: opencv
Issue: Add support to identify what colorspace a cvMat is in
Labels: feature,category: core,RFC

This is a feature request for opencv core.

Using opencv C++, is there a way to automatically detect what colorspace a cvMat is in? In my experience with opencv, I believe the answer is no. The responsibility of knowing what colorspace a cvMat is in has always been application-specific and relied on a dev to know how data was read in via `imread`.

This becomes problematic when interfacing with other libraries that use opencv and pass cvMat's around where it's not always clear how the cvMat was constructed. Either the colorspace must be documented or requires digging into the source code.

An _easy_ fix to this would be to add an enum (maybe call it `COLORSPACE`) that tracks what colorspace the data is in. Functions like `imread` and `cvtColor` would set/update the enum where appropriate. Here is a short example of how I imagine someone would use the enum solution.

```cpp
#include <opencv2/imgproc.hpp>
#include <iostream>

using namespace cv;
using namespace std;

int main(int argc, char **argv) {
    string image_file("some-image.jpg");
    Mat img = imread(image_file); // or possibly retrieve a cvMat from an external library
    if (img.empty()) {
        cout << "Can't read image from file: " <<  image_file << endl;
        return -1;
    }

    // what colorspace are we in? Does the Mat need converting with cv::cvtColor?
    if (img.COLORSPACE == cv::RGB) {
        cout << "this image is in RGB space" << endl
    }
    if (img.COLORSPACE == cv::BGR) {
        cout << "this image is in BGR space" << endl;
    }
}
```

Thoughts or suggestions?
Repository: godot
Issue: Particles 3d not animated in Multithreaded Render in 3.2
Labels: bug,topic:rendering,topic:particles

**Godot version:**
3.2.*, 3.1.\* (beginning from 3.1.0 alpha1 and up)


**OS/device including version:**
Reproduced on: Intel Celeron G4930/ASUS 1050ti, Windows10 and latest nvidia drivers
and Intel E8500/Gigabyte 750ti, Windows10 2004 19041.572, nvidia driver 445.75
(not reproduced on laptop with i5 6200U/940MX/Win10)


**Issue description:**
Particles animated in editor, but not when game launched, if rendering set to Multithreaded.
They just spawn and sit in their place, sometimes slowly drifting when mouse is moved.
(However they work, while you drag whole game window).
I discovered this by accidentally opening some old particles demo.
Guess not many folks using 3d particles with MT rendering.
![godot324](https://user-images.githubusercontent.com/72292300/98993385-6d309580-253f-11eb-8b65-b7143c1db513.gif)



Video of buggy behavior in 3.2.4 beta1:
https://drive.google.com/file/d/1M4Axo1M0X-ppa2Om5z_hIRBpsFGV1Ado/view

Video of expected like in 3.0.6 stable:
https://drive.google.com/file/d/1SCmnBpZplhfr3luQ8ddjj7_He9SnKBNT/view

**Steps to reproduce:**
1. Add Particle node to scene.
2. Setup particle's "draw pass 1" with new CubeMesh
3. Setup particle's "process material" with new ParticleMaterial
4. Add Camera to scene so it will be shown
5. Set Project setting - Rendering - Threads - Thread Model to Multi-Threaded
6. Launch scene, observe particles animated in editor but not in game.

**Minimal reproduction project:**
[MRP_Particles_MT.zip](https://github.com/godotengine/godot/files/5533090/MRP_Particles_MT.zip)
Repository: material-ui
Issue: Disabled Button focus within Portal
Labels: bug 🐛,component: button

<!-- Provide a general summary of the issue in the Title above -->

When is disabled `Button` placed within Portal, parent outside Portal does not receive `focus` properly.

<!--
  Thank you very much for contributing to Material-UI by creating an issue! ❤️
  To avoid duplicate issues we ask you to check off the following list.
-->

<!-- Checked checkbox should look like this: [x] -->

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

When you click on normally placed `Button`, parent receives focus correctly even when that `Button` is disabled. When you place that `Button` in portal, only enabled `Button` do that. 

## Expected Behavior 🤔

Events should work exactly the same in both cases, no matter if `Portal` is used.

## Steps to Reproduce 🕹

https://codesandbox.io/s/material-ui-issue-forked-eu17z?file=/src/Demo.js

Steps:

1. Click on normally placed enabled/disabled Button. Parent receives focus (marked by red outline)
2. Click on enabled `Button` in `Portal`. Parent receives focus as well.
3. Click disabled `Button` in `Portal`. Parent does not receive or lose focus depending on previous state.

## Context 🔦

Focused state of parent affects display of some controls within its tree. When user clicks disabled `Button`, these controls are hidden even though they should be displayed.

## Your Environment 🌎

<!--
  Include as many relevant details about the environment with which you experienced the bug.
  If you encounter issues with TypeScript please include version and tsconfig.
-->

| Tech        | Version |
| ----------- | ------- |
| Material-UI | v4.11.0 |
| React       |  17.0.1 |
| Browser     | Chrome 86 |
Repository: godot
Issue: GD.Print(float) on german locale uses comma as decimal separator
Labels: bug,confirmed,documentation,topic:dotnet

**Godot version:**
3.2.3 mono


**OS/device including version:**
Windows 10 and ubuntu 20 with **locale that uses the comma as decimal separator**


**Issue description:**
I'm using arcadiaGodot to develop and when I ask for a Transform it is returned as such:
((0,4999999, -0,01813666, -0,8658353), (0, 0,9997806, -0,02094242), (0,8660253, 0,01047121, 0,4998902)) - (2,597508, 0,04931428, -8,49967)


**Steps to reproduce:**
GD.Print(0.2); // will print 0,2 on machine using e.g. german locale

[foo.zip](https://github.com/godotengine/godot/files/5533436/foo.zip)
Repository: flutter
Issue: Engine clip layers have a lot of duplicated code
Labels: team,engine,P2,c: tech-debt,team-engine,triaged-engine

There are 3 clipping subclasses of `flutter::Layer` in the engine and all 3 have nearly identical code except for a few lines that deal with the specific clip information:

- ClipPathLayer
- ClipRectLayer
- ClipRRectLayer

We should probably have common code with the 3 variants represented by subclassing, templating, or a "clip shape" helper object.
Repository: godot
Issue: Runtime type checking regression for engine functions
Labels: bug,topic:core,regression

The commit ee06a70ea6ac51aa451d55c92b807346458822d7 changed the validation logic and doesn't check anymore if Variants of type `Object` are compatible.

The VariantCasterAndValidate struct had it's logic altered, instead of
```cpp
if (!Variant::can_convert_strict(p_args[p_arg_idx]->get_type(), argtype) ||
                               !VariantObjectClassChecker<T>::check(p_args[p_arg_idx])) {
```
it's just:
```cpp
if (!Variant::can_convert_strict(p_args[p_arg_idx]->get_type(), argtype)) {
```

Removing the type conversion check.
Repository: pytorch
Issue: NCCL 2.7.8 errors on PyTorch distributed process group creation
Labels: oncall: distributed,triaged

## 🐛 Bug

NCCL 2.7.8 errors on PyTorch distributed process group creation

## To Reproduce

Steps to reproduce the behavior:

1. On two machines, execute this command with ranks 0 and 1 after setting the environment variables (`MASTER_ADDR`, `MASTER_PORT`, `CUDA_VISIBLE_DEVICES`):
```
>>> dist.init_process_group(backend='nccl', rank=0, world_size=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/torch/distributed/distributed_c10d.py", line 442, in init_process_group
    barrier()
  File "/usr/local/lib/python3.8/dist-packages/torch/distributed/distributed_c10d.py", line 1947, in barrier
    work = _default_pg.barrier()
RuntimeError: NCCL error in: /pytorch/torch/lib/c10d/ProcessGroupNCCL.cpp:784, invalid usage, NCCL version 2.7.8
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

A clean initialization w/o error

## Environment

- PyTorch version: 1.7.0+cu110
- Is debug build: True
- CUDA used to build PyTorch: 11.0
- ROCM used to build PyTorch: N/A
- 
- OS: Ubuntu 18.04.5 LTS (x86_64)
- GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
- Clang version: Could not collect
- CMake version: version 3.10.2
- 
- Python version: 3.8 (64-bit runtime)
- Is CUDA available: True
- CUDA runtime version: Could not collect
- GPU models and configuration: GPU 0: Tesla P100-PCIE-16GB
- Nvidia driver version: 450.51.05
- cuDNN version: Probably one of the following:
- /usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
- HIP runtime version: N/A
- MIOpen runtime version: N/A
- 
- Versions of relevant libraries:
- [pip] Could not collect
- [conda] Could not collect

## Additional context
NCCL version is as follows:
- libnccl2=2.7.8-1+cuda11.0 


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @xush6528
Repository: go
Issue: cmd/compile: notice when function variables are never reassigned, avoid indirect calls
Labels: Performance,NeedsInvestigation,compiler/runtime

It's somewhat common for people to have package-level variables like:

```
var u64 = binary.BigEndian.Uint64
```

So later in their code they can just write `u64(buf[8:])` many times without stuttering a loud `binary.BigEndian.Uint64` etc all over the page.

But calling via such a func variable is ~7.5x slower than calling `binary.BigEndian.Uint64` directly: https://play.golang.org/p/eccPzwCSvfi

It'd be nice if the compiler noticed that the `u64` variable was only initialized once and never reassigned to and never had its address taken (so it can't be mutated elsewhere), and did the fast thing automatically, not doing the indirect call.

/cc @randall77 @mdempsky @ianlancetaylor @cherrymui @josharian @danderson
Repository: flutter
Issue: Rename FlutterMacOS.framework to Flutter.framework
Labels: platform-ios,tool,engine,platform-mac,a: desktop,P2,team-engine,triaged-engine

Pros:
1. "MacOS" isn't as meaningful with Catalyst, universal apps, etc.  Really, for Flutter it means "links on AppKit".
2. iOS Flutter.framework will soon be distributed as an [XCFramework](https://github.com/flutter/flutter/issues/60109) to support ARM iOS simulators.  XCFrameworks can encode slices for any darwin platform (ios, macos, catalyst, etc).  Future watchOS, tvOS, and Catalyst support could be added to the same XCFramework.
3. Flutter.framework and FlutterMacOS.framework currently share common .h and .m files.  The different names mean that https://github.com/flutter/flutter/issues/60025#issuecomment-726413256 cannot be easily fixed.
4. This matches Apple's own conventions.  For example, the CloudKit framework is named the same on every platform--there is no CloudKitWatch framework.

Cons:
The tool will no longer download macOS desktop engine artifacts separately.  This will increase the artifact cache size for iOS developers who are not building macOS apps, and vice versa.  This will not impact app size.

Work:
1. Engine files need to be updated to import and build a macOS Flutter.framework variant.
2. [Adopt XCFramework](https://github.com/flutter/flutter/issues/60109)
3. [Move the linking and embedding logic out of the Xcode project and into the tool](https://github.com/flutter/flutter/issues/56581)
4. Tool caching logic needs to be updated to download the common engine artifacts.
Repository: go
Issue: encoding/json: clarify Decoder.InputOffset semantics
Labels: Documentation,NeedsInvestigation

The documentation on [`Decoder.InputOffset`](https://golang.org/pkg/encoding/json/#Decoder.InputOffset) currently says:
>The offset gives the location of the end of the most recently returned token and the beginning of the next token.

This explanation is somewhat incorrect since the offset cannot be a single value if there are intervening whitespace in-between two JSON tokens. Furthermore, the `json` package implicitly handles colons and commas, which are technically JSON tokens according to RFC 7159, section 2. May the offset ever be past these implicit colons and commas, or will it always be before them? The "token" in this context is a somewhat ambiguous.

The documentation should be clarified to say one of the following:
* The offset may be between the end of the most recently returned token (exclusive), and before the beginning of the next token that may be returned (inclusive).
* The offset points to the next character immediately after the most recently returned token.
* The offset points to the first character of the next token that may be returned.

I chose the phrase "may be returned" to indicate that colons and commas aren't included since they aren't ever returned by the `json` API. I haven't checked the implementation yet to see what it actually returns.

The first definition gives more flexibility to how the `Decoder` may actually be implemented. The latter two definitions gives the user more assurance about what `InputOffset` actually means.

Updates #29688
Repository: react-native
Issue: FlatList inverted prop ordering of elements causes copy/paste issues
Labels: Component: FlatList,Needs: Triage :mag:,Never gets stale

## Description
When the `inverted` prop is applied to `FlatList` the elements remain in the order given and are reversed via styling rather than by reversing the order in which they are rendered. This makes it so that, for example, if `react-native-web` is used, when the list elements are copied, they end up pasting in reverse order. 

## React Native version:
0.63.3

## Steps To Reproduce
1. Create a list using `FlatList`
2. Apply the `inverted` prop
3. Note the order of some list items and copy them
4. Paste them and note that the order is backwards from what was displayed

## Expected Results
I would expect that when pasted the list would retain the order that is shown on the screen. 

## Snack, code example, screenshot, or link to a repository:
https://codesandbox.io/s/cold-wave-grzpj?file=/src/App.js
Repository: pytorch
Issue: ONNX export of a scripted submodule fails with "Modules that are called during a trace must be registered as submodules of the thing being traced"
Labels: oncall: jit,module: onnx,onnx-triaged

(Replacing original issue description with a much simpler root cause / repro instructions):

```python
import torch

class Inner(torch.nn.Module):
    def forward(self, x):
        return (x, )

class Outer(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.inner = torch.jit.script(Inner())

    def forward(self, x):
        return self.inner(x)

x = torch.zeros(1)
m = Outer()
torch.onnx.export(m, (x,), 'test.onnx')
```

Produces:
```
/usr/local/lib/python3.7/dist-packages/torch/nn/modules/module.py in _slow_forward(self, *input, **kwargs)
   1077         tracing_state = torch._C._get_tracing_state()
   1078         if not tracing_state or isinstance(self.forward, torch._C.ScriptMethod):
-> 1079             return self.forward(*input, **kwargs)
   1080         recording_scopes = torch.jit._trace._trace_module_map is not None
   1081         if recording_scopes:

RuntimeError: Tried to trace <__torch__.___torch_mangle_2.Inner object at 0x55753bc17ef0> but it is not part of the active trace. Modules that are called during a trace must be registered as submodules of the thing being traced.
```