sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Word wrapping incorrect for variable width font with formatting that changes the width of characters
Labels: bug,editor-wrapping

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->

Version: 1.55.0-insider
Commit: 5d80c30e5b6ce8b2f5336ed55ad043490b0b818f
Date: 2021-03-08T05:14:50.001Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Linux x64 5.11.6-arch1-1

Steps to Reproduce:

1. Set font to something variable width (I tested with Verdana)
2. Ensure the Editor: Word Wrap setting is "on"
3. Ensure the Editor: Wrapping Strategy is set to "advanced"
4. Create a markdown file
5. Type some text surrounded by double asterisks or beginning with `# ` to format with **bold**.
6. Word wrapping occurs as though the text weren't bold, but bold text is wider and thus causes horizontal scroll

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported direct to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: flutter
Issue: AppBarTheme is not complete
Labels: framework,f: material design,d: api docs,P2,team-design,triaged-design

there's a number of properties that define AppBar appearance, though are not present in AppBarTheme:

* shape
* primary
* toolbarOpacity
* bottomOpacity
* toolbarHeight
* leadingWidth

cc @HansMuller
Repository: rust
Issue: Confusing error reported for trait impls on DST with the last field being Sized  
Labels: A-diagnostics,E-needs-test,T-compiler,D-confusing,D-incorrect

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d9a00dc0e329f0ea73b037f3af9f26db

```rust
use std::marker::PhantomData;

trait Trait {}

struct Unsized([u8], ());
struct Foo<T: ?Sized>(PhantomData<T>);

impl<T> Trait for Foo<T> {}
impl Trait for Foo<Unsized> {}
```

The current output is:

```
error[E0119]: conflicting implementations of trait `Trait` for type `Foo<Unsized>`:
 --> src/main.rs:9:1
  |
8 | impl<T> Trait for Foo<T> {}
  | ------------------------ first implementation here
9 | impl Trait for Foo<Unsized> {}
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Foo<Unsized>`

```

Ideally the output should look like:

```
error[E0277]: the size for values of type `[u8]` cannot be known at compilation time
 --> src/lib.rs:1:16
  |
5 | struct Unsized([u8], ());
  |                ^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `[u8]`
  = note: only the last field of a struct may have a dynamically sized type
  = help: change the field's type to have a statically known size
help: borrowed types always have a statically known size
  |
5 | struct Unsized(&[u8], ());
  |                ^
help: the `Box` type always has a statically known size and allocates its contents in the heap
  |
5 | struct Unsized(Box<[u8]>, ());
  |                ^^^^    ^

error: aborting due to previous error

```

Note: this error is particularly confusing because the trait impls \*dont\* overlap after fixing the field ordering error

cc @estebank
Repository: vscode
Issue: Using key commands to scroll to top or bottom of document does not incorporate editor.paddingTop and editor.paddingButtom
Labels: bug,editor-commands

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
- VS Code Version: 1.54.2
- OS Version: macOS 10.15.7

If `editor.paddingTop` or `editor.paddingBottom` are set, using the keyboard to scroll to the top or bottom of the document does not incorporate that padding... it pins the first/last line at the top/bottom of the viewport.

This was unexpected for me. I have these top/bottom padding settings enabled because I don't like the top or bottom of my code jammed up against the UI or the bottom of the window, and when I use the keyboard to "go to the top" or "go to the bottom" I mean both "put the cursor on the first/last line" and "scroll maximally in that direction".

Steps to Reproduce:

1. Set `editor.paddingTop` and `editor.paddingBottom` to `120`.
2. Scroll to the top with the mouse (120 padding shows — good).
3. Scroll to the bottom with the mouse (120 padding shows — good).
4. Press the key command to scroll to the top of the document (⌘-↑ on macOS... presumably "Home" on Windows?).
5. Note that the first line is at the top of the viewport, with no 120 padding.
6. Press the key command to scroll to the bottom of the document (⌘-↓ on macOS... presumably "End" on Windows?).
7. Note that the last line is at the bottom of the viewport, with no 120 padding.

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported direct to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: flutter
Issue: [Documentation] Improve documentation on ImageFilter.blur() sigma values
Labels: engine,d: api docs,d: examples,P2,team-engine,triaged-engine

The documentation for the [ImageFilter.blur()](https://api.flutter.dev/flutter/dart-ui/ImageFilter/ImageFilter.blur.html) method currently does not mention the sigma values and what they are. This can make it confusing to convert gaussian blurs from other frameworks (like HTML/CSS with [blur()](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/blur()) or WPF with the [BlurEffect](https://docs.microsoft.com/en-US/dotnet/api/system.windows.media.effects.blureffect?view=net-5.0)).

I currently found conversions from sigma to radius in the flutter engine [here](https://github.com/flutter/engine/blob/867d4f277d723034081a0d7f678ab54536f0eb9c/lib/web_ui/lib/src/engine/util.dart#L551) and [here](https://github.com/flutter/engine/blob/ceafbefb1a6cfdff3d6d1b8dfdc4069b0b237abc/lib/web_ui/lib/src/engine/html/scene_builder.dart#L580), but the actual calculation of the radius inside Skia seems to be a bit more complicated (see [here](https://skia.googlesource.com/skia/+/refs/heads/master/src/core/SkGaussFilter.h#22), [here](https://skia.googlesource.com/skia/+/refs/heads/master/src/core/SkGaussFilter.cpp#108) and [here](https://skia.googlesource.com/skia/+/refs/heads/master/src/core/SkGaussFilter.cpp#91)).

Therefore it would be really great to have some clarification on that from the experts :)
Repository: opencv
Issue: MacOSX: repair build with VTK 9.0
Labels: bug,category: build/install,category: infrastructure,category: viz

[3.4](http://pullrequest.opencv.org/buildbot/builders/3_4-mac/builds/1038):
```
-- VTK is not found. Please set -DVTK_DIR in CMake to VTK build directory, or to VTK install subdirectory with VTKConfig.cmake file
```

[4.x](http://pullrequest.opencv.org/buildbot/builders/master-mac/builds/11470):
```
-- VTK support is disabled. Compilation of the sample code has failed.
```

---

Affected build-worker: `macosx-1` (`macosx-2` still uses VTK 8.x)
Repository: rust
Issue: Tracking Issue for NOOP_METHOD_CALL lint
Labels: A-lints,T-lang,C-tracking-issue,S-tracking-impl-incomplete

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the `NOOP_METHOD_CALL` lint (https://github.com/rust-lang/lang-team/issues/67)

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implement the initial version of the lint (https://github.com/rust-lang/rust/pull/80723)
- [ ] Extend this to more complicated cases, like `ToOwned`
- [x] Make the lint warn-by-default

### Known issues:

- [ ] https://github.com/rust-lang/rust/issues/91536

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

* Should we lint when a method is called via UFCS? This could be interpreted as the user explicitly choosing to call a no-op method.
* Should we allow external crates to mark their own methods as being 'noop-ops', so that this lint can fire on third-party methods?

### Implementation history

* Initial version implemented in https://github.com/rust-lang/rust/pull/80723
Repository: rust
Issue: Inline generators before state machine conversion in order to reduce branching
Labels: I-slow,C-enhancement,A-coroutines,A-mir-opt,C-optimization

As of 6c51ec96bb5b6679645be1651d4ff1d079412af6, which is the fix for #76181, generators no longer inline in MIR. This results in missing the following optimization opportunity:

    pub async fn f() {
        foo().await;
        g().await;
    }

    async fn g() {
        bar().await;
        h().await;
    }

    async fn h() {
        baz();
    }

should become:

    async fn f() {
        foo().await;
        bar().await;
        baz().await;
    }

I checked a simple example and LLVM didn't seem to do the inlining, which doesn't surprise me as after the state machine transformation it's going to be quite hard to perform it.

This could be an important optimization because recreating the nested call stack when a generator is resumed can be O(n) in bad cases like this one. (This was brought up as a potential problem when comparing C++ coroutines with Rust generators.)
Repository: rust
Issue: Document encode_utf16() endianness; maybe add endianness and BOM options.
Labels: C-enhancement,T-libs-api,A-docs

The documentation does not specify the endianness of `str::encode_utf16()`and `char::encode_utf16()`: it looks from the source like they are big-endian (UTF-16BE), but I may be reading it wrong and they are little-endian (UTF-16LE) or native-endian. 

This may be a deliberate design decision: if so I think it should be reconsidered, as the encoding is useless for some purposes if you don't know its endianness.

It would also be nice to indicate whether `str::encode_utf16()` inserts a byte-order mark (BOM): pretty sure it does not from the source, which is fine.

It is probably too late to rename these functions or to add equivalents of opposite endianness at this point, which is too bad. It's an odd API given that the corresponding decode functions have little-endian and big-endian variants.
Repository: flutter
Issue: Provide `addPostLayoutCallback` or other way to make RenderObject's paint influenceable by its position
Labels: c: new feature,framework,c: proposal,P3,team-framework,triaged-framework

Consider https://stackoverflow.com/questions/66624590/style-a-decoratedbox-depending-on-its-global-position-on-the-screen, where I try to affect how an object is paint depending on its final absolute position on the screen.

Flutter is missing a way to style `RenderObject`s after their absolute position.

For an intermediate solution, it would be nice to be able to schedule a callback between `pipelineOwner.flushLayout();` and before `pipelineOwner.flushCompositingBits();`.

```Dart
mixin RendererBinding on BindingBase, ServicesBinding, SchedulerBinding, GestureBinding, SemanticsBinding, HitTestable {
...
  @protected
  void drawFrame() {
    assert(renderView != null);
    pipelineOwner.flushLayout();
<------------------- CALLBACK HERE ------------------>
    pipelineOwner.flushCompositingBits();
    pipelineOwner.flushPaint();
    if (sendFramesToEngine) {
      renderView.compositeFrame(); // this sends the bits to the GPU
      pipelineOwner.flushSemantics(); // this also sends the semantics to the OS.
      _firstFrameSent = true;
    }
  }
```

However, a better approach would be to have a general hook on `RenderObject`s that is fired whenever the object changed its global position.

```Dart
class RenderObject {
  ...
  void globalPositionChanged();
  ...
}
```
Repository: flutter
Issue: [custom devices] Allow configuring or auto-detecting the target platform
Labels: tool,c: proposal,P3,team-tool,triaged-tool

Right now (when #78113 passes) any custom device has `TargetPlatform.linux_arm64`, which is okay for now since only platform-agnostic stuff is built (the assets bundle).

In the future, it'd be better to allow configuring or auto-detecting the target platform. If we at some point want to build release artifacts for custom devices, we need to know the target arch.

(This is just an issue so I have something for the TODO-item in the PR-code to link to)
Repository: flutter
Issue: Support Microsoft Edge on Mac and Linux in flutter run
Labels: c: new feature,tool,platform-mac,platform-linux,c: proposal,browser: edge,P3,team-tool,triaged-tool

Continuing #55322

MS edge has stable release on Mac and currently has dev releases on Linux.
Please lift the "Windows only" restriction for `flutter run -d edge`.

In the long term, please allow user to choose and use any chromium-based browser installation for `flutter run` and not have to request support for every one of them.
Add a "at your own risk" disclaimer if you don't want to officially support them, but let the devs choose their environment.
Repository: electron
Issue: [Feature Request]: Option to Hide Icon in Dock/Taskbar on Linux
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Hi, could we get an option to hide the app icon in the dock/taskbar on Linux, i.e. a Linux equivalent of skipTaskbar for windows and app.dock.hide for Linux.

### Proposed Solution

None

### Alternatives Considered

None

### Additional Information

None
Repository: pytorch
Issue: hope to support something like  "torch::manual_seed_for_mulit_thread"
Labels: module: cpp,triaged,enhancement,module: random

```

int main() {
    torch::Tensor mu=torch::zeros(1);
    torch::Tensor std=torch::ones(1);
    std::vector<double> vc;
    vc.reserve(8);
#pragma omp parallel for num_threads(8) default(shared)
    for(int i=0;i<8;++i){
        int tdidx=omp_get_thread_num();
       torch::manual_seed(tdidx);
        vc[tdidx]=at::normal(mu,std,gen).item<float>();
    }
    std::cout<<"!!!!!!!!!!!!!" <<std::endl;
    std::cout<< vc[0]<<std::endl;
    std::cout<< vc[1]<<std::endl;
    std::cout<< vc[2]<<std::endl;
    return 0;
}
```
wanna see the result to stay the same.
but vc[0] always change,is there any  way to do this? 

cc @yf225 @glaringlee @pbelevich
Repository: godot
Issue: Running a specific project on M1 Mac on v.3.2.4.rc5.official causes kernel panic
Labels: bug,topic:editor,confirmed,crash

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
v3.2.4.rc5.official


**OS/device including version:**
Mac mini (M1, 2020) - macOS Big Sur (11.2.2)


**Issue description:**
When building the attached project, there is a panic: Kernel data abort, which crashes the Mac.


**Steps to reproduce:**
Building the attached project.
This likely is resulting from some faulty code (possible memory leak) I unintentionally implemented as I cannot recreate it with other projects.

**Minimal reproduction project:**
[The-Last-Knight-master.zip](https://github.com/godotengine/godot/files/6137032/The-Last-Knight-master.zip)
Repository: material-ui
Issue: [Autocomplete] Update to ARIA 1.2
Labels: accessibility,breaking change,component: autocomplete

- [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 😯

The combo box follows [ARIA 1.1](https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html).

## Expected Behavior 🤔

The combo box follows ARIA 1.2

<img width="841" alt="Screenshot 2021-03-14 at 18 53 29" src="https://user-images.githubusercontent.com/3165635/111078610-a03b6380-84f6-11eb-80fc-7ecdeb7d19d9.png">

https://www.w3.org/TR/wai-aria-1.2/#combobox

The new implementation example: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/.

## Related efforts

- https://github.com/carbon-design-system/carbon/pull/7777

## Your Environment 🌎

v5.0.0-alpha.27
Repository: godot
Issue: Popup containing an auto-wrap label opens too tall
Labels: bug,confirmed,topic:gui

Some issues slightly related to similar problems exist, but they were worked around by turning off autowrap instead of actually fixing the problem with it.

**Godot version:**
Godot 3.2.3, Godot 3.2.4

**OS/device including version:**
Windows 10 64 bits

**Issue description:**
I have an `AcceptDialog` with a `VBoxContainer` inside. I added a label with some description text inside, and enabled `autowrap` so it fits inside the dialog.
Controls have the correct width when the popup opens, but no matter which sequence of setup I use, it always opens with a crazy high vertical size:
![image](https://user-images.githubusercontent.com/1311555/111079010-02449a80-84f0-11eb-8e29-accadc3a8877.png)

**Steps to reproduce:**
I do this in a module, so this is the code I used to reproduce it in GDScript:
```gdscript
extends Node

class CustomDialog extends AcceptDialog:
	func _init():
		rect_min_size = Vector2(300, 280)
		var vb = VBoxContainer.new()
		# Does not fix it
		#vb.rect_size = rect_min_size
		var label = Label.new()
		label.text = "This is custom text to debug my problem with the dialog size"
		label.autowrap = true
		# Does not fix it
		#label.rect_size = rect_min_size
		vb.add_child(label)
		add_child(vb)

var _dialog

func _init():
	_dialog = CustomDialog.new()
	add_child(_dialog)

func _on_Button_pressed():
	_dialog.popup_centered_minsize()
```

**Minimal reproduction project:**
[PopupWithAutowrapLabel.zip](https://github.com/godotengine/godot/files/6137260/PopupWithAutowrapLabel.zip)

I suspect the reason is because at some point, controls get sorted in a state where the label is given a width of zero, making it become very tall to fit each letter in one column. I tried to workaround this by giving controls an initial size, and gave the popup a minimum size, to no avail.
Repository: rust
Issue: Tracking Issue for `proc_macro_back_compat`
Labels: T-compiler,C-tracking-issue,A-proc-macros,A-proc-macro-back-compat,S-tracking-needs-to-bake

## What is this issue?

If you're a crate author who's been linked here, your crate (indirectly) depends on a version of a procedural macro crate that will stop compiling in the future. All affected crates have updated versions published, so you should update to the latest version of the crate mentioned by the compiler warning you saw.

### Background 

In the past, the Rust compiler has had several bugs in the way that it passes a `TokenStream` to procedural macros ('proc-macro's). Fixing these bugs resulted in changes the input `TokenStream`, which some proc-macros were not prepared to handle.

To avoid breaking large portions of the ecosystem, several hardcoded hacks were added to the compiler. When specific macros from certain crates (e.g. `time-macros-impl`) are invoked, we invoke the macro with a modified `TokenStream` (what would have been used before the bugfix), which keeps the project compiling.

However, hard-coding specific crate and macro names in the compiler is a huge hack, which we'd like to remove as soon as possible. This issue tracks our progress towards removing all of these hacks.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

TODO

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->


### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->