sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Scenario: Keyboard Text Selection
Labels: Area-Input,Area-TerminalControl,Product-Terminal,Issue-Scenario

##### [Original issue: #715] [Original Spec: #2840] [Mark mode spec: #5804] [initial PR: #10824] [markers PR: #10865]

## Features
* [x] #715
* [x] Quick Edit (modify existing selection w/ keyboard)
* [x] #1469
* implicit mark mode
   * [ ] #11985
     - see also: #13369
* [x] [follow-up] #3663
* [x] [follow-up] #6649
* [x] [follow-up] #4985

## Bugs
- #13413
- #13447
- #13485 

## Misc.
* [ ] [Remove optional param for copy func, manually clear selection instead](https://github.com/microsoft/terminal/pull/13360#discussion_r905290481)
* feedback from #13533:
   - [ ] Prioritize mark mode key bindings over custom key bindings when in mark mode
   - Scrolling...
      - [ ] [PROTOTYPE] scrolling should move the "mark"
      - [ ] If we've scrolled, then we enter mark mode, start position should be somewhere in the visible area (NOT back at the input buffer aka the cursor position).


## PRs
- Spec...
	- #2840
	- #5804
- Impl...
	- #3758
	- #10824
	- #13045
	- #10865
	- #13053
	- #13358 
	- #13370 
	- #13405 
	- #13435
Repository: excalidraw
Issue: We should have a different hint when drawing multisegments lines on mobile
Labels: enhancement,good first issue
Repository: vscode
Issue: [rename on type] option-delete and pasting creates 2 undo stops
Labels: bug,editor-synced-region

Ref #88424

- Have content `<div></div|> `
- Option-delete or paste something
- You need two undo to restore the original content
Repository: godot
Issue: Project always starts in maximized window
Labels: bug,topic:porting,needs testing

**Godot version:** 3.2.1 stable

**OS/device including version:** Ubuntu 18.04.4, 2 monitors, main monitor 2560 x 1440, GTX 1060
 driver 435.21
**Issue description:** The project window size setting settings and editor window placement setting are ignored. Whatever I set, the project window always start maximized (OS.window_maximized always true on startup). It holds both for exported project and project run from editor.  Maybe related to #36462 and #35571

**Steps to reproduce:** Set window width and height to smaller values than the resolution of the screen and run the project.
Repository: pytorch
Issue: `conv2d` is slow with specific shapes of channels_last tensors
Labels: module: performance,module: cudnn,triaged,module: memory format

GPU: Tesla V100-SXM2
Cuda: 10.0
CudNN: 7603

```python
def f(x, w, args):
	o = torch.conv2d(x, w, *args)
	o.sum().backward()
	torch.cuda.synchronize()

inputs = ((100, 2048, 14, 14), (2048, 64, 3, 3), None, (2, 2), (1, 1), (1, 1), 32)
shape_i = inputs[0]
shape_w = inputs[1]
args = inputs[2:]
for mf in (torch.contiguous_format, torch.channels_last):
	x = torch.rand(shape_i, dtype=torch.float16, device='cuda').contiguous(memory_format=mf)
	w = torch.rand(shape_w, dtype=torch.float16, device='cuda', requires_grad=True).contiguous(memory_format=mf)
	
	print(mf)
	%timeit f(x,w,args)
```

```
torch.contiguous_format
4.11 ms ± 37.3 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)
torch.channels_last
143 ms ± 29.3 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
```

cc @csarofeen @ptrblck @VitalyFedyunin @jamesr66a @ngimel
Repository: godot
Issue: GridMap: Metadata issues on updating / removing Mesh Library
Labels: bug,topic:editor

**Godot version:** 3.0 - 3.2.1

**OS/device including version:** Windows 10 Pro 64-bit

**Issue description:**
I will start by saying that those are a number of issues which are all related to GridMap metadata, which include:
- Failure to update item preview on Mesh Library update
- Failure to update actual item (i.e. Mesh Library object) on Mesh Library update
- Wrong items and previews on Mesh Library update
- Wrong GridMap objects being rendered when running objects after Mesh Library update - GridMap objects in the editor are different to GridMap objects at runtime (this is perhaps the weirdest problem)
- Failure to clear GridMap metadata after removing Mesh Library - this can result in a messed scene if another library is attached, unless this library is compatible to old one, which is not always the case
- Unknown extra material changes happening during rendering after updating Mesh Library (i.e 3 material changes instead of 2)

All those issues are caused by either updating or removing / re-adding MeshLibrary. They can cause a lot of confusion to those unaware of them, as those issues are not obvious as to the cause.

Solutions:
- Always delete your /.import folder as well as all .import files when updating your Mesh Library
- You may need to delete and re-add your GridMap nodes if the issues persist, as they do store information which is not destroyed when removing / updating libraries
Repository: terminal
Issue: Suggestion: Translate vscode color themes to terminal color schemes
Labels: Product-Colortool,Help Wanted,Area-Settings,Issue-Task

For someone that knew the attributes in both vscode color themes and in terminal color scheme, it seems that it would be easy to write, say, a Python script to do this translation.
Because I know neither, I can only describe the need.
Repository: terminal
Issue: [Megathread] Panes Titlebar Follow-ups
Labels: Area-UserInterface,Product-Terminal,Issue-Scenario

##### [Panes megathread #1000] [Original PR: #7371] [Original Issue: #4717]

### Tasks

* [ ] Add a context menu entry for "close pane"
* [ ] Add a context menu entry for "zoom pane"
* [ ] Add optional "maximize/close" control
  - Like the MinMaxCloseControl, but without minimize, and with "maximize" being "zoom pane"
  - Should that option be in the theme? (#3327) _I'm thinking YES_
* [ ] Allow moving panes to other tabs #7075

### Open Discussion

* [ ] How should pane title color work with `tabColor`? https://github.com/microsoft/terminal/pull/7371#issuecomment-679223330
> > Currently, setting the tab's background color with the color picker does not update the pane titlebar color.
>
> I think that's fine. Currently, the order of precedence is [tab runtime color, control title color, theme color (unimplemented), default color]. So I could imagine this going two ways:
> * convert the "tab runtime color" to be a "pane runtime color". Then, using the color picker on the tab would set the active _pane_'s runtime color. This comes with the detrimental side effect that you'd have to re-color each pane in a tab manually.
> * add an additional "pane runtime color", and have the tab's color be composed from [tab runtime color, pane color (which is itself [pane runtime color, control title color, theme pane title color]), theme color, default]. This would allow panes to have their color changed at runtime with a color picker, and also have the tab have a manual color override.
> 
> 
> I'm of course just hypothesizing here in the comments - I don't think any of this is something that _needs_ to get done in _this_ PR. We can always loop back on the issue in a follow-up.

* [ ] Should the titlebar for a pane not appear until there are multiple panes? Kinda seems like there are three states: `paneTitlebarVisibility: [never, multiplePanes, always]`
Repository: terminal
Issue: Scenario: Add support for hyperlinks
Labels: Area-VT,Area-UserInterface,Product-Terminal,Issue-Scenario

This is the the megathread for tracking all the remaining work that needs to be done for hyperlink support in Terminal.

### "Soon" Timeframe

* [x] Original issue: #204 -> added in #7251 
* [x] Allow `file://` URIs -> added in #7526
* [ ] #7562 Allow other URI schemes
* [x] Render hyperlinks differently from regular text in Terminal -> added in #7420 
* [x] Hover underline text that have the same hyperlink ID and display the URI -> added in #7420 
* [x] Display a content dialog box for URIs we cannot parse/schemes we do not support -> added in #7523 
* [x] https://github.com/microsoft/terminal/issues/574 Add support for Terminal to auto-detect hyperlinks -> added in #7691 
* [ ] #7563 Switch the pointer to the 👆 icon when we're hovering a link (in the clickable state, like with ctrl pressed)
* [ ] `VtEngine::_SetHyperlink` uses `fmt::format` to render the hyperlinks, and it should really use `_WriteFormattedString`
* [ ] #7564 Hook up hyperlinks to conhost (rendering + clicking)
* [ ] #7565 Make sure hyperlinks are included in HTML copy
* [x] #8123 Only underline hyperlinks on hover -> added in #8148
* [ ] ~Controlling tooltip delay for URLs #8242~
  - Abandoned, platform limitation
* [x] ~Add a setting to disable auto detection of links (in PR #8239)~
  - Abandoned, we're not sure anyone actually ever wanted this
* [x] Links/URLs get offset when certain unicode characters are printed #8709
* [x]  #9117
* [x] #6649
* [ ] #11901

### Backlog
* [ ] Add a setting to configure the regex used to detect patterns
* [ ] #8849
  - Theoretically, this could supersede #7562 
  - Should be self-consistent with #8294
* [ ] Control the styling of hyperlinks - attributes used for autodetected hyperlinks, and then different attributes for hovered ones #8294
* [ ] #2671

### References
* This VsCode issue has an enormous set of references to improvements they've made: https://github.com/microsoft/vscode/issues/172084
* #15700
Repository: pytorch
Issue: Better examples in functional autograd functions
Labels: module: docs,module: autograd,triaged

The current documentation of `torch.autograd.functional` follows that same practice as other places: create random Tensors and print them.
We could improve that by:
- Use hard coded values to make them more readable and easily reproducible
- Find a way to test that the docstring example stays up to date with what the function does?

cc @ezyang @SsnL @albanD @zou3519 @gqchen
Repository: flutter
Issue: Web: PhysicalModelLayer doesn't check elevation
Labels: engine,platform-web,c: rendering,P2,team-web,triaged-web

Currently `physical_model_test.dart` disables some tests because we do not check elevation on the Web the same way mobile Flutter does (or at all). We need to match the mobile behavior.
Repository: excalidraw
Issue: Link the text inside a shape to the shape
Labels: enhancement

It can get a bit annoying when trying to move a block but it doesn't move the text inside it. Not a big issue, but I have forgotten to rubber-band (or command click) to move them together way too many times now :(

(I think there's a separate issue about linking arrows to shapes which is related)
Repository: TypeScript
Issue: for..of transform when targetting ES6< [Compiler option]
Labels: Suggestion,Awaiting More Feedback

## Search Terms
for..of, downlevelIteration, transform, optimization, compiler option

## Suggestion

Option for transforming `for..of` when targetting ES6 and above.

## Background

Based on my investigation, `for..of` loops are slower than the traditional `for` loops (see the result: https://github.com/aminya/TypeScript-optimization)

It is pretty funny that when I target ES5, TypeScript converts `for..of` to the traditional loops, which makes the code faster, but I cannot do this when I target anything above ES6. 

I noticed that there is `"downlevelIteration"` which does the opposite of what I want.

## Use Cases

It enhances the performance but allows to write readable code.

## Examples

```typescript
// for - of
  let sum = 0
  for (const a of arr) {
    sum += a
  }

// should be transformed to:
// Traditional
  let sum = 0
  for (let i = 0, l = arr.length; i < l; ++i) {
    sum += arr[i]
  }

// or
  let sum = 0
  for (let i = 0, l = arr.length; i < l; ++i) {
    let a = arr[i]
    sum += a
  }
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: TypeScript
Issue: Allow functions to have `new symbol` as the return type
Labels: Suggestion,Awaiting More Feedback

## Search Terms

- unique symbol
- new unique symbol
- new symbol

## Suggestion

I request that `unique symbol` be allowed as the return type of a function declaration.

Alternatively, it might be better to use `new symbol` to disambiguate <https://github.com/microsoft/TypeScript/issues/40106#issuecomment-677741032>.

## Use Cases

Currently, it’s impossible to create an alias or a wrapper function for the global `Symbol` constructor and use that to construct unique symbols:

```js
// ./es-globals/fundamentals.js
export const ESSymbol = Symbol;
export const { for: ESSymbol_for } = ESSymbol;
```
```ts
// ./es-globals/fundamentals.d.ts
export import ESSymbol = globalThis.Symbol;
export declare const ESSymbol_for: typeof ESSymbol.for;
```

```js
// ./symbols.js
import { ESSymbol, ESSymbol_for } from "./es-globals/fundamentals.js";

// should be `unique symbol`, but is instead `symbol`:
export const customSymbol = ESSymbol("custom");

// should be `unique symbol` or `global symbol "nodejs.util.inspect.custom"`,
// but is instead `symbol`:
export const nodejs_util_inspect_custom = ESSymbol_for("nodejs.util.inspect.custom");

// should be `unique symbol` or `global symbol "nodejs.util.promisify.custom"`,
// but is instead `symbol`:
export const nodejs_util_promisify_custom = ESSymbol_for("nodejs.util.promisify.custom");
```

## Examples

This would allow defining `SymbolConstructor` as:

```ts
declare interface SymbolConstructor {
	/**
	 * Returns a new unique Symbol value.
	 * @param description Description of the new symbol value.
	 */
	(description?: string | number): new symbol;

	/**
	 * Returns a Symbol object from the global symbol registry matching the given key if found.
	 * Otherwise, returns a new symbol with this key.
	 * @param key key to search for.
	 */
	for<T extends string>(key: T): global symbol T;
	// or, until GH-35909 is implemented:
	for(key: string): new symbol;
}
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## See also

- <https://github.com/microsoft/TypeScript/issues/36468>
- <https://github.com/microsoft/TypeScript/issues/35909> (`global symbol "<name>"` proposal)
- <https://github.com/microsoft/TypeScript/pull/24738>
- <https://github.com/microsoft/TypeScript/issues/24506>
- <https://github.com/microsoft/TypeScript/issues/40106>
- <https://github.com/microsoft/TypeScript/pull/42543>
- <https://github.com/microsoft/TypeScript/issues/53282>
Repository: vscode
Issue: Report task execution result in onDidEndTask
Labels: feature-request,api,tasks,api-proposal

The event `vscode.tasks.onDidEndTask` doesn't report the status of the task (i.e. succeeded or failed). It would be great if this can be added to be able to take actions based on that.

This will be particularly useful if the task has "dependent" tasks that might fail, in this case the event won't fire for the main task, so there has to be a way to know if any given task succeeded/failed in the chain.
Repository: go
Issue: os/signal: notify should filter out runtime-generated SIGURG
Labels: NeedsInvestigation,compiler/runtime

This program, when running under go 1.14, will show a huge number of `SIGURG` are received even though none should be (no network IO, no explicit kills).

https://play.golang.org/p/x7hFjPZnrg5
<pre>
package main

import (
	"fmt"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	ch := make(chan os.Signal, 1)
	signal.Notify(ch, syscall.SIGURG)

	for {
		select {
		case sig := <-ch:
			fmt.Printf("received %v: %s\n", sig, time.Now())
		default:
			_ = new(int) // generate some GC activities
		}
	}
}
</pre>

https://go.googlesource.com/proposal/+/master/design/24543-non-cooperative-preemption.md changes to use SIGURG to preempt goroutines, which is fine, but I think `os/signal.Notify` should filter out those runtime generated SIGURGs.

The reason I found this is that I have a program that happens to use `SIGURG` as a custom signal like `SIGUSR1`, which works fine with previous Go releases. I understand that it should probably use `SIGUSR1`, but still I think `os/signal` should hide any signals generated by the runtime as it's irrelevant for the user and an implementation detail.

/cc @aclements thoughts?
Repository: rust
Issue: Incorrect explanation for error E0117
Labels: T-compiler,C-bug,A-error-codes

As of commit 1e5450d, the detailed explanation for error E0117 begins with:

```
The `Drop` trait was implemented on a non-struct type.

Erroneous code example:

impl Drop for u32 {}
```

The "The `Drop` trait was implemented on a non-struct type" sentence appears to be meant for E0120, but accidentally got included as part of the E0117 text.

I'm not sure how upstream wants to proceed here, but note that the example `impl Drop for u32 {}` _will_ [trigger](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=edf3ea0cf084ba760ddb0fc8311080df) _both_ E0117 and E0120. So keeping this example- while changing the text- is probably fine. 

I lost more time than I'd like to admit to misreading the docs here :P.
Repository: rust
Issue: Tracking Issue for Result::flatten (`result_flattening`)
Labels: T-libs-api,B-unstable,C-tracking-issue,A-result-option,Libs-Tracked,Libs-Small

This is a tracking issue for the `Result::flatten` API.
The feature gate for the issue is `#![feature(result_flattening)]`.

```rust
impl<T, E> Result<Result<T, E>, E> {
      pub fn flatten(self) -> Result<T, E>;
}
```

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses 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
- [x] Implement 
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

### Implementation history

 * Implementation #70140
Repository: rust
Issue: Locals aligned to greater than page size can cause unsound behavior
Labels: A-LLVM,O-windows,P-high,T-compiler,I-unsound,C-bug,ICEBreaker-LLVM,C-external-bug

Forked from https://github.com/rust-lang/rust/issues/70022

Minimal example
```Rust
#[repr(align(0x10000))]
struct Aligned(u8);

fn main() {
    let x = Aligned(0);
    println!("{:#x}", &x as *const _ as usize);
}
```
Aligning the stack is done *after* the stack probe. Because stacks grow downwards and aligning the stack shifts it downwards, it can cause the end of the stack to extend past the guard page and cause invalid access exceptions *or worse* when those sections of the stack are touched.

~~Only confirmed that this occurs on `pc-windows-msvc`~~ (pnkfelix edit: see comment thread, its a more general problem.)

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"cuviper"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Statics aligned to greater than a page cause linker error
Labels: A-linkage,O-windows,T-compiler,C-bug,A-align

On Windows `link.exe` requires that the alignment of any section is less than or equal to the `/ALIGN` value. Statics with an alignment of 8192 or greater cause the section to have an alignment of 8192 (but not greater, see https://github.com/rust-lang/rust/issues/70022), but `link.exe` has a default `/ALIGN` of 4096 causing `fatal error LNK1164: section 0x6 alignment (8192) greater than /ALIGN value`. Specifying `-Clink-arg="/ALIGN:8192"` causes the error to go away.

Minimal example
```Rust
#[repr(align(0x100000))]
struct Aligned(u8);

static X: Aligned = Aligned(0);

fn main() {
    println!("{:#x}", &X as *const _ as usize);
}
```
Repository: node
Issue: gcc warning in inspector protocol implementation
Labels: c++,v8 engine

```
[1934/2890] CXX obj/gen/src/node/inspector/protocol/libnode.Protocol.o
gen/src/node/inspector/protocol/Protocol.cpp: In member function ‘virtual std::unique_ptr<node::inspector::protocol::Value> node::inspector::protocol::DictionaryValue::clone() const’:
gen/src/node/inspector/protocol/Protocol.cpp:698:21: warning: redundant move in return statement [-Wredundant-move]
  698 |     return std::move(result);
      |            ~~~~~~~~~^~~~~~~~
gen/src/node/inspector/protocol/Protocol.cpp:698:21: note: remove ‘std::move’ call
gen/src/node/inspector/protocol/Protocol.cpp: In member function ‘virtual std::unique_ptr<node::inspector::protocol::Value> node::inspector::protocol::ListValue::clone() const’:
gen/src/node/inspector/protocol/Protocol.cpp:739:21: warning: redundant move in return statement [-Wredundant-move]
  739 |     return std::move(result);
      |            ~~~~~~~~~^~~~~~~~
gen/src/node/inspector/protocol/Protocol.cpp:739:21: note: remove ‘std::move’ call
```