sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [RFC] Consider renaming "xs" breakpoint to "base"
Labels: new feature,discussion,breaking change,waiting for 👍,package: system,RFC

- [x] I have searched the [issues](https://github.com/mui/material-ui/issues) of this repository and believe that this is not a duplicate.

## Summary 💡

In order for the system to work well, it requires the first breakpoint to be `0px`. This is required in order for the min-width media query logic to trigger correctly.

The use of `xs` to name this baseline might be wrong, evermore to allow developers to customize it.

## Motivation 🔦

The discussion started at https://github.com/mui/material-ui/pull/26135#discussion_r626396190. We noticed the current customization demo is wrong:

```jsx
const theme = createMuiTheme({
  breakpoints: {
    values: {
      tablet: 640,
      laptop: 1024,
      desktop: 1280,
    },
  },
});
```

https://mui.com/material-ui/customization/breakpoints/#custom-breakpoints

It misses the `mobile: 0` breakpoint.

Maybe it would make sense to remove `xs` from the theme and rename it differently, like [`_`](https://styled-system.com/responsive-styles#using-objects), or `base`.

It's also to be noted that `xs` is the anagram of `sx`, which can create confusion when reading it: #34948.

---

Another request from a user:

> While using breakpoints object like this, How do we specify bgColor for devices less than xs? 

```jsx
<Box
    sx={{
      bgcolor: {
        xs: 'primary.light',
        sm: 'secondary.light',
      },
    }}
  />
```

## Complains

- https://twitter.com/ivanfc0o/status/1653956210968625152

## Benchmarks

- https://styled-system.com/responsive-styles: `_`
Repository: rust
Issue: Coverage only applies to spans in a contiguous span of source code (not both macro and caller)
Labels: A-code-coverage

Explore adding coverage spans for all sources that emit some coverable spans, including macros and the source that invokes the macros.

The current implementation of `-Zinstrument-coverage` requires choosing a span in which to report coverage. Typically this is the function's or closure's body_span, so functions that invoke macros will have coverage but code within the expanded macro will not have coverage. Or, if the macro starts the body span (if the macro emits the left curly brace), the macro will have coverage, and any code in the calling source (if passed as an argument to the macro) will not get coverage.

This latter effect was a problem for closures that don't include enclosing braces, until PR #84897 .

PR #84897 is better, but limited: The PR removed coverage from a macro that included most of the function logic (`on_error!()` defined in `closure_macro.rs` and `closure_macro_async.rs` coverage tests.)

Instead of the change in PR #84897, if we can actually add spans to all sources that emit some part of the actual covered, expanded function body syntax, I think this will give coverage results everywhere they apply (except perhaps for macros that generate code that splits a statement or terminator implementation across multiple source spans).
Repository: pytorch
Issue: Show commit hash for master branch docs on pytorch.org
Labels: triaged,enhancement,module: doc infra

Currently our `master` branch doc on pytorch.org is updated regularly to keep up to date with pytorch repo. But it's not clear to developers when they should expect to see their changes on the website (e.g. I landed inference_mode doc but didn't see it on the website even a day after so was wondering if I did something wrong). https://pytorch.org/cppdocs/notes/inference_mode.html
I think it'll help a lot if we display the commit hash on the website as well, at least for master branch. 

cc @ezyang @zou3519 @brianjo
Repository: vscode
Issue: Composable package.json extension manifest contributions through the use of external files
Labels: feature-request,api,extension-host

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

For any large extension the size of the `"contributes"` entry in `package.json` can also grow to be extremely large and difficult to maintain, especially since you cannot organize contributions by feature or add comments (since `package.json` must be pure JSON).

I would propose adding something like the following to `"contributes"` to allow for composition of extension contributions from one or more external files:

```jsonc
{
   "contributes": {
      "include": [
        "feature1.json",
        "feature2.json",
        ...
      ],
      ...
    }
}
```

Where `"feature1.json"` might be:
```jsonc
// contributions for feature1
{
  "commands": [
    ...
  ],
  "menus": [
    ...
  ],
  // other contribution points
}
```

The proposed order of composition would be:
1. Contributions provided by each file in `"include"` are applied in array order.
2. Contributions from `package.json` are applied last.

In the event of a collision where two contribution sources define the same contribution (such as two commands with the same name), I see at least two options:
1. Error when activating an extension with collisions, or
2. The last in wins, but `vsce` could provide errors or warnings for collisions prior to packing/publishing.

I'm generally in favor of "last in wins" so as not to hamper local development/testing while refactoring an extension, but don't have a strong preference either way.

One caveat to this approach is that there would need to be some way for VS Code to know that `feature1.json` is an external contribution manifest. This could possibly be accomplished by using a well-defined filename format such as `<name>-contributions.json` (similar to `language-configuration.json`), or by using a `"$schema"` entry on the top-level object.
Repository: vscode
Issue: Support fragment in Uri label formatter
Labels: feature-request,label-provider


Issue Type: <b>Feature Request</b>

We are using fragment for notebook cell uri and its cell metadata/output uri, it would be great if we can customize the label with fragment. It seems the label service label formatter only allow path, authority and query.

VS Code version: Code - Insiders 1.57.0-insider (Universal) (fe23c2041f848d6c2f6bd27875112a37bcc82f84, 2021-05-06T05:50:00.296Z)
OS version: Darwin x64 20.3.0


<!-- generated by issue reporter -->
Repository: godot
Issue: Shape2D.collide_and_get_contacts returns incorrect contact points between convex polygon and line segment
Labels: documentation,topic:physics

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
v3.2.3.stable.official
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:**
Windows 10, OpenGL ES 3.0 Renderer: GeForce GTX 1070/PCIe/SSE2
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->



**Issue description:**
`Shape2D.collide_and_get_contacts` can sometimes return incorrect contact points between a convex polygon and a line segment. The following script and screenshot illustrate this:

```gdscript
extends Node2D

var rect_points: PoolVector2Array
var segment_point_a: Vector2
var segment_point_b: Vector2
var contact_points: Array
var intersection_point: Vector2

func _ready():
	var rect_point_a: Vector2 = Vector2(294.51239, 351.953125)
	var rect_point_b: Vector2 = Vector2(423.069946, 505.161987)
	var rect_point_c: Vector2 = Vector2(729.48761, 248.046875)
	var rect_point_d: Vector2 = Vector2(600.930054, 94.838013)

	rect_points.append(rect_point_a)
	rect_points.append(rect_point_b)
	rect_points.append(rect_point_c)
	rect_points.append(rect_point_d)

	var rect_shape: ConvexPolygonShape2D = ConvexPolygonShape2D.new()
	rect_shape.set_point_cloud(rect_points)

	segment_point_a = Vector2(500, 100)
	segment_point_b = Vector2(500, 300)

	var segment_shape: SegmentShape2D = SegmentShape2D.new()
	segment_shape.a = segment_point_a
	segment_shape.b = segment_point_b

	contact_points = rect_shape.collide_and_get_contacts(Transform2D(), segment_shape, Transform2D())

	intersection_point = Geometry.segment_intersects_segment_2d(segment_point_a, segment_point_b, rect_point_d, rect_point_a)

func _draw():
	draw_colored_polygon(rect_points, Color.blue)
	draw_line(segment_point_a, segment_point_b, Color.green, 5)
	for contact_point in contact_points:
		draw_circle(contact_point, 5, Color.white)
	draw_circle(intersection_point, 5, Color.red)

```

![CollideAndGetContactsTest](https://user-images.githubusercontent.com/3267627/117362095-d955db80-ae88-11eb-844c-008be8d6b07b.png)

The white circles are the contact points returned by the call to `Shape2D.collide_and_get_contacts` (one of which is plainly incorrect), and the red circle is the intersection point found by `Geometry.segment_intersects_segment_2d` (which is plainly correct).
<!-- What happened, and what was expected. -->


**Steps to reproduce:**
Attach the above script to a Node2D and run the scene.

**Minimal reproduction project:**
The above script is a sufficient test and has no dependencies.
Repository: rust
Issue: Consider deprecating LLVM-specific feature names for -Ctarget-feature flag
Labels: A-LLVM,T-compiler

As of #84991 we support the same values for `-Ctarget-feature` as we do for the `#[target_feature]` attribute. However there is a fallback that passes through any unknown names, which effectively means that LLVM names are also accepted by the flag.

I think it makes sense for us to look into deprecating LLVM-specific names, and eventually remove the fallback (or destabilize the fallback behaviour).
Repository: pytorch
Issue: BFloat16 CUDA GEMM ops unsupported on Nvidia P100 (SM_60) on CUDA 11.3
Labels: module: cuda,triaged,module: cublas,module: bfloat16

## 🐛 Bug in CUDA?

As per #50442, Bfloat16 CUDA GEMM ops are supposed to be supported on Nvidia SM_53 GPUs & above.
However, with an Nvidia P100 ([SM_60 GPU](https://developer.nvidia.com/cuda-gpus#collapseOne)) & CUDA 11.3, such ops produce an error stating that they're unsupported.
Please confirm which Nvidia Compute-capability GPUs support them. Thanks!

## To Reproduce

Steps to reproduce the behavior:

1. Clone the PyTorch repo & run `python test_ops.py` in `pytorch/test`.
2. Some tests, such as `test_supported_backward_addbmm_cuda_bfloat16` would fail with the following error:
```
RuntimeError: CUDA error: CUBLAS_STATUS_NOT_SUPPORTED when calling `cublasGemmStridedBatchedExFix(handle, opa, opb,
(int)m, (int)n, (int)k, (void*)&falpha, a, CUDA_R_16BF, (int)lda, stridea, b, CUDA_R_16BF, (int)ldb, strideb, (void*)&fbeta, c,
CUDA_R_16BF, (int)ldc, stridec, (int)num_batches, CUDA_R_32F, CUBLAS_GEMM_DEFAULT_TENSOR_OP)
```
The corresponding test for `addmm`, `baddbmm` & `bmm` also failed with the same error.
For `addmm`, this test had even passed on SM_52 with CUDA 11.1.
The rest 3 are only enabled in `common_methods_invocations.py`, if SM version is above 52.

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

These BFloat16 CUDA GEMM tests should pass on `SM_60` GPUs (GPUs above SM_52), as they do with `SM_75` (Tesla T4) on CI.
FWIW, `addmm`'s corresponding test passes on `SM_52` with CUDA 11.1, while `baddbmm`'s fails on `SM_52`.
However, both are failing on Nvidia P100 with CUDA 11.3.

## Environment
PyTorch version: 1.9.0a0+gitebd2c0a
Is debug build: False
CUDA used to build PyTorch: 11.3

OS: Ubuntu 18.04.1 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: NVIDIA Tesla P100-PCIE-12GB
Nvidia driver version: 465.19.01
cuDNN version: Could not collect

## Additional context
cc @csarofeen @ptrblck @xwang233 @ngimel @zasdfgbnm

cc @mruberry @anjali411, as some OpInfos check for Nvidia SM_53 or above, so they might've to be modified based on updated info.
cc @ngimel
<!-- Add any other context about the problem here. -->
Repository: pytorch
Issue: Add CI automation tests for Infiniband for DDP
Labels: oncall: distributed,triaged

## 🚀 Feature
Add automation tests in CI for Infiniband for DDP. Currently this has to be tested manually.



cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: TypeScript
Issue: Discrepancy when typeToString when enclosingDeclaration is undefined vs defined.
Labels: Suggestion,Awaiting More Feedback

# Bug Report

I'm using `typeToString` functionality from the typescript compiler (via ts-morph) to build auto-generated API documentation. I've run into an issue with certain types that use default generic types. My goals:
 - I don't want the default parameters to show up
 - I want the module/sourcefile import included
 
 If I pass `enclosingDeclaration`, the default parameters don't show up, but the import is gone. If I don't pass `enclosingDeclaration` the opposite happens - import is there, but the default parameters show up.

### 🔎 Search Terms

Typescript typeToString generic optional default parameter ignore enclosingDeclaration

### 🕗 Version & Regression Information

I'm not sure this is bug but there is nothing I could find about it anywhere else. 

### ⏯ Playground Link

[link](https://www.typescriptlang.org/play?#code/LAKApgHgDg9gTgFwAQEsB2CxwGYEMDGYSA6iggBYAiYeArgDYIDiYaWK+AzgDwCCSAXiScEcdAHMANEgBCgpGloBbAEZYAfEgDeoJKjhww9MADdcGAFzDREgNygAvqFCRYiJAgCeUIgBUwIvIAFACUgpqkFNR0jCxsYly2QA)

[Code sandbox](https://codesandbox.io/s/silly-kirch-0lkwx?file=/src/App.tsx) which shows the issue.

<img width="721" alt="Screen Shot 2021-05-06 at 8 10 57 PM" src="https://user-images.githubusercontent.com/16563603/117381270-b5ef5880-aea9-11eb-86eb-84503e4af509.png">


### 💻 Code

Types:
```
export interface WithDefaultGenerics<A = string, B = number> {
  irrelevant: string;
}

export type Test = () => WithDefaultGenerics;
```

```ts
    const text = compiler.typeToString(
      compilerType, // This is the type of `Test`
      undefined,
      TypeFormatFlags.UseFullyQualifiedType | TypeFormatFlags.InTypeAlias
    );
    console.log('text is ', text);

    const text2 = compiler.typeToString(
      compilerType, // This is the type of `Test`
      node.compilerNode, // This is the node container of `Test`
      TypeFormatFlags.UseFullyQualifiedType | TypeFormatFlags.InTypeAlias
    );
    console.log('text2 is ', text2);
```

### 🙁 Actual behavior

```
text is  () => import("/Users/path/to/file").WithDefaultGenerics<string, number>

text2 is  () => WithDefaultGenerics
```

### 🙂 Expected behavior

I'm trying to get `() => import("/Users/path/to/file").WithDefaultGenerics`

The reason this is important to me is because in conjunction with, I suspect, [this issue](https://github.com/microsoft/TypeScript/issues/19198), getting a type for `(props: AllCasesProps) => ReactElement<AllCasesProps>` ends up looking like this:

<img width="766" alt="Screen Shot 2021-05-06 at 8 27 16 PM" src="https://user-images.githubusercontent.com/16563603/117381206-88a2aa80-aea9-11eb-83fd-ab9ab88f1d7f.png">
Repository: pytorch
Issue: LibTorch inference script model is slower than PyTorch, and the speed is not stable. Why?
Labels: oncall: jit

win10 cpu,libtorch1.8.1+cpu,pytorch1.8.1+cpu.

LibTorch inference script model is slower than PyTorch, and the speed is not stable. Why?

cc @gmagogsfm
Repository: pytorch
Issue: CUDA error: an illegal memory access was encountered
Labels: needs reproduction,module: cuda,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->
Hi, everyone, I have been stuck here for several days, I need some help, thanks in advance.
![image](https://user-images.githubusercontent.com/31238754/117386722-f38bca00-af19-11eb-9b5f-c0efde60a920.png)

## To Reproduce

Steps to reproduce the behavior:

1.install transformers==4.3.3
tqdm
sklearn
tensorboardX
apex(unnecessary),
zhconv==1.4.0 
pypinyin==0.34.1
pywubi==0.0.2 
boto3
botocore 
overrides
2.git clone https://github.com/ShannonAI/glyce.git
cd glyce 
python3 setup.py develop
3.git clone https://github.com/zyh3826/GlyceBertTest.git
modify dataset path and model path in config.yaml
4.download BERT-Base, Chinese at https://storage.googleapis.com/bert_models/2018_11_03/chinese_L-12_H-768_A-12.zip
convert tf checkpoint to pytorch, you can use transformers convert_bert_original_tf_checkpoint_to_pytorch.py or my convert_bert_original_tf_checkpoint_to_pytorch.py;
copy the bert's pytorch_model.bin to glyce_bert/;
modify glyph_config.bert_model in glyce_bert/bert_config.json;
5. python3 my_trainer.py and wait. if you use LCQMC/dev.txt as train, eval, test.txt as test dataset the error will happen at the third evaluation loop


<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->
no error
## Environment

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 Version (e.g., 1.0): 1.7.1
 - OS (e.g., Linux): Ubuntu 18.04.5 LTS (x86_64)
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source):
 - Python version: 3.8 (64-bit runtime)
 - CUDA/cuDNN version:  NVIDIA-SMI 440.33.01    Driver Version: 440.33.01    CUDA Version: 10.2
 - GPU models and configuration: RTX 2080Ti
 - Any other relevant information:
    GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
    CMake version: version 3.13.2

## Additional context

<!-- Add any other context about the problem here. -->


cc @ngimel
Repository: go
Issue: cmd/compile: optimize program running speed 
Labels: NeedsInvestigation,compiler/runtime

This is currently an idea, an idea to optimize the operation of the program. It may not be rigorous. I hope to rewrite the code to achieve optimal performance during the compilation phase. We all know that the most commonly used optimization method is splicing, not `fmt.Printf` or `fmt.Sprintf`.

But using `fmt.Printf` or `fmt.Sprintf` can achieve extremely high readability. So I was wondering whether it is possible to rewrite `fmt.Sprintf` into splicing during the compilation phase. E.g

```go
msg := fmt.Sprintf("now time: %s", time.Now())
// After rewriting 
msg := "now time:" + time.Now().String()

ok := false
msg := fmt.Sprintf("hello world: %t", ok)
// After rewriting 
msg := "hello world:" + strconv.FormatBool(ok)


type Int int
func (i Int) String() string {
	return fmt.Sprintf("%d",i)
}
func main() {
	ok := false
	number := 100
	number2 := Int(100)
	msg :=  fmt.Sprintf("hello world: %t \nnumer: %d \nnumer2: %d number2: %s", ok, number, number2, number2)
}

// After rewriting 
type Int int
func (i Int) String() string {
	return strconv.FormatInt(int64(i), 10)
}
func main() {
	ok := false
	number := 100
	number2 := Int(100)
	msg := "hello world: " + strconv.FormatBool(ok) + " \nnumer: " + strconv.FormatInt(int64(number), 10) + " \nnumer2: " + strconv.FormatInt(int64(number2), 10) + " number2: " + number2.String()

}
```



The above is a preliminary idea of mine. I think this optimization can greatly improve performance without changing the code. Welcome to discuss

A simple benchmark I did

```go
func BenchmarkPrintf(b *testing.B) {
	ok := false
	number := 100
	number2 := Int(100)
	var msg string
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		msg = fmt.Sprintf("hello world: %t \nnumer: %d \nnumer2: %d number2: %s", ok, number, number2, number2)
	}
	_ = msg
}

func BenchmarkStrconv(b *testing.B) {
	ok := false
	number := 100
	number2 := Int(100)
	var msg string
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		msg = "hello world: " + strconv.FormatBool(ok) + " \nnumer: " + strconv.FormatInt(int64(number), 10) + " \nnumer2: " + strconv.FormatInt(int64(number2), 10) + " number2: " + number2.String()
	}
	_ = msg
}
```

```
BenchmarkPrintf
BenchmarkPrintf-12       3365628               342.4 ns/op            67 B/op          2 allocs/op
BenchmarkStrconv
BenchmarkStrconv-12      7946673               145.9 ns/op            73 B/op          4 allocs/op
```
Repository: pytorch
Issue: BatchNorm grad calculation is imprecise
Labels: needs reproduction,module: numerical-stability,module: autograd,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->
While re-implementing SyncBatchNorm (for speed), I noticed that the weight gradient calculation was off. I root-caused it to the backward pass doing operations in a different order than in the forward pass. Due to floating point error accumulation this will result in a gradient that is less accurate than it needs to be.

The gradient calculation [here](https://github.com/pytorch/pytorch/blob/v1.8.1/aten/src/ATen/native/Normalization.cpp#L379) is equivalent to:

```
weight.grad = torch.sum((input - mean) * grad_output, dim=collapse_dims) * invstd
```

A more precise calculation would be:

```
weight.grad = torch.sum((input - mean) * invstd * grad_output, dim=collapse_dims)
```

in order to maintain consistency with the forward path which is:

```
output = (input - mean) * invstd + bias
```

For very large input tensors, I am seeing a noticeable difference between the current gradient calculation and the precise calculation above.

## To Reproduce

Steps to reproduce the behavior:

1.
1.
1.

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->

## Environment

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 Version (e.g., 1.0):
 - OS (e.g., Linux):
 - How you installed PyTorch (`conda`, `pip`, source):
 - Build command you used (if compiling from source):
 - Python version:
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano
Repository: node
Issue: `JOBS=1 make` does not work at macOS
Labels: build

`JOBS=1 make` (with ninja) does not work. It still use all cores instead of the specified 1 core.

Because the line which starts with tab and the one without tab mean different in Makefile. For more information see [Recipe-Syntax](https://www.gnu.org/software/make/manual/html_node/Recipe-Syntax.html)

It seems to be introduced in this PR: https://github.com/nodejs/node/pull/28881