sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/build/cmd/relui: macOS installer should add GOBIN to PATH
Labels: Builders,NeedsInvestigation

We currently provide installers for Go for Windows (an .msi file) and macOS (a .pkg file).

Both installers add `$GOROOT/bin` to `PATH`. This lets users run commands like `go build` without having to edit `PATH` themselves.

However, users still need to edit `PATH` in order to run binaries installed with `go install` or `go get`. This introduces unnecessary confusion for new developers. To avoid this, both installers should add `$GOBIN` to `PATH` as well.

(Note that neither `GOBIN` nor `GOPATH` are likely to be set when an installer runs. If they are set, we should respect them; the goal is just to ensure that the directory where `go install` writes binaries is added to `PATH`).
Repository: vscode
Issue: Ellipsis in search viewlet shows more UI, not commands
Labels: debt,ux,search

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

In the search viewlet, the ellipsis button is used to reveal include and exclude input boxes. I don't think ellipsis should be used to permanently modify the UI. I believe ellipsis should only be used to temporarily show UI or commands for which there currently is not enough space to show permanently.
![EllipsisInSearchViewletShowsMoreUINotAdditionalCommands](https://user-images.githubusercontent.com/1704059/84418591-52b06400-ac0f-11ea-8f0f-969080c80d34.png)


<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No
Repository: go
Issue: x/tools/gopls: change links in hover for replaced modules
Labels: NeedsFix,gopls,Tools

- Run `go version` to get version of Go
	- go version go1.14.4 windows/amd64
- Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders
	- 1.45.1 x64
- Check your installed extensions to get the version of the VS Code Go extension 
	- 0.14.4
- Run `go env` to get the go development environment details
```
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\dtsp\AppData\Local\go-build
set GOENV=C:\Users\dtsp\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\dtsp\YandexDisk\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\GO
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\GO\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map
```
### Share the Go related settings you have added/edited
```
    "go.testFlags": [
        "*.go": "go"
    "[go]": {},
    "go.formatTool": "goimports",
    "go.useLanguageServer": true,
```

### Describe the bug
When I enable Go Language Server all my local Go modules become unavailable.
![image](https://user-images.githubusercontent.com/38575605/84374853-516b4100-abe7-11ea-92df-ae9823f7efdc.png)

All these modules are local to project folder and are available using `replace`:

```
replace (
	transflow.ru/pkg/api v0.0.0 => ../api
	transflow.ru/pkg/assign v0.0.0 => ../assign
	transflow.ru/pkg/cache v0.0.0 => ../cache
	transflow.ru/pkg/consts v0.0.0 => ../consts
)
```

But even struct `Server` which is defined at the very same package is unavailable as you may see at screenshot.
Repository: godot
Issue: Variables bigger than a certain size are displayed as null in the editor debugger
Labels: bug,topic:core,topic:editor,confirmed

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
0eaefa73a11b88dc6c181f0fcc7236ccea2198c6

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Win10 64-bit GLES2

**Issue description:**
<!-- What happened, and what was expected. -->

I have a loop that will take random PackedScenes out of an Array and copy them into a new Array.  (A shuffling thing.)

It works fine until it gets up to 10 in the iteration.  Then the debugger shows that it goes null.  However, a print() will show about 11 of the 30 expected elements.  It will behave as null from there on and crash later.

```
	var list = []

	var set  = sets[0].set
	var size = set.size()

	set.append(set[0])

	for n in p_number:
		
		var ridx = RNG.rand_int()
		var tscn = set[ridx % size]

		list.push_back(tscn)

	return list
```
Prints some of the elements, even though it claims it is null.
![godot_debug_64_R8t0rjtWiy](https://user-images.githubusercontent.com/13004169/84428267-d6c61400-ac2e-11ea-86f3-f4e6c27b5f63.png)

Goes null during 10th execution...

![godot_debug_64_jSuIM7tj2a](https://user-images.githubusercontent.com/13004169/84428245-d0379c80-ac2e-11ea-835f-12176e0d4da5.png)

@akien-mga Has there been any GScript commits lately that could be causing a regression and I can check against?

@vnen Might you know of a way to better isolate this?

**Steps to reproduce:**
Use the project below and set breakpoints to inspect the array.  Not sure yet of an operation that will crash it all the time, as the values are in some sort of limbo, sometimes they behave null, sometimes they work, even when the debugger claims null.

![godot windows tools 64_mfcWAjgn0F](https://user-images.githubusercontent.com/13004169/84484565-9a80cb00-aca3-11ea-82ae-ca9f7852f91c.png)

Observe the enemies Array, and the first and last element.

1. The Array `enemies` is null.
2. The first element, `first_tscn` has a value.
3. The last element, `last_tscn` is null.

![godot windows tools 64_XTOSCGblFS](https://user-images.githubusercontent.com/13004169/84484557-98b70780-aca3-11ea-8853-cd757f3e9d66.png)

**Minimal reproduction project:**


Reducing the total enemies in the wave property below 7085 will get normal behavior.

**NOTE:  Use breakpoints to inspect results in wave.gd**

[Arrays Going Null.zip](https://github.com/godotengine/godot/files/4769730/Arrays.Going.Null.zip)
Repository: godot
Issue: Parse error: Unexpected token: Identifier
Labels: bug,topic:dotnet

<!-- Please search existing issues for potential duplicates before filing yours:	
https://github.com/godotengine/godot/issues?q=is%3Aissue	
-->

**Godot version:**
Version 3.2.1 official build


**OS/device including version:**
Windows 10


**Issue description:**
<!-- What happened, and what was expected. -->
![image](https://user-images.githubusercontent.com/66799893/84431616-df691b00-ac2b-11ea-8f4e-04223ff18032.png)

![image](https://user-images.githubusercontent.com/66799893/84431581-ceb8a500-ac2b-11ea-8a73-ea7424c4fdeb.png)

If we add multiple generic type constraints the parser will throw an error. It does not occur with only one constraint. The project builds correctly even if this happens.

**Steps to reproduce:**
Simply create a generic type or method with two or more constraints and try to build the project.
Repository: go
Issue: proposal: cmd/go: extend syntax go.mod to allow overriding fetch protocol
Labels: Proposal

## Update
The original proposal was build on the idea that we could extend `replace` directive (see the original text below). 

After several rounds of discussions here in the comments, the current semantics of `replace` isn't about fetching the dependency but about local substitution of the source path and version (see [this comment from @bcmills](https://github.com/golang/go/issues/39536#issuecomment-670483278)).

I have re-title the proposal and [suggested the new syntax](https://github.com/golang/go/issues/39536#issuecomment-670616528) to solve the described problem.

## Original Proposal
I propose to extend the syntax of go.mod's `replace` directive to support overwriting the protocol, which Go will use to fetch the module. That is

```
replace example.com/foo/bar => git+ssh://private.example.com/foo/bar
```

## Background
As it’s for Go 1.14, the syntax of `replace` directive in `go.mod` allows overwriting module’s import path by defining an alternative version, alternative import path, or a path on the local FS (refer to [[1]]).

For non-FS-based replaces, Go fetches the replaced modules from modules proxy server as it does for other dependencies.

If a project uses private dependencies or private forks to replace a dependency, managing the modules become an extra burden for the developers, who work on the project. Even though the dependency is an attribute of the project itself, it’s the responsibility of every developer of the project to define the correct values for `GOPRIVATE`, `GONOPROXY`, etc, which alters their "normal" development workflow.

With private dependencies explicitly listed as the ones, that can't be fetched from any modules-proxy server, the project's workflow wouldn't be any different from a project, that only uses public modules (_providing that a developer has the required accesses_).

Specifying the protocol explicitly would also solve the issue where “go get” chooses to fetch a private dependency via HTTPS, which usually forces developers to manipulate their host’s `.gitconfig`, adding custom `insteadOf` rules to force go-get to use SSH when downloading modules from GitHub repositories.

## Prior Experience
Dependency-management systems in other programming languages have similar mechanisms. For example:

- Node.js + NPM
`package.json` `"dependency"` syntax accepts URLs, Git URLs and some other [[2]].

- Rust + Cargo
`Cargo.toml` allows overwriting the source of the dependent crate, passing project’s Git URL [[3]].

- Go + dep
`Gopkg.toml` allows specifying dependencies' `source` as an alternate location, passing the URL [[4]].

[1]: https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
[2]: https://docs.npmjs.com/files/package.json#dependencies
[3]: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html
[4]: https://golang.github.io/dep/docs/Gopkg.toml.html#dependency-rules-constraint-and-override
Repository: go
Issue: cmd/cgo: more expansive test coverage
Labels: help wanted,NeedsFix,compiler/runtime

cgo is very subtle, yet it's lacking in test coverage. For example, misc/cgo/test doesn't have any tests for C.enum_foo or C.struct_bar, and misc/cgo/testgodefs doesn't have any tests for constants (to be addressed by CL 237558).

/cc @ianlancetaylor
Repository: terminal
Issue: Tooltips should display keybindngs
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
The tooltip for new tab, close etc should say the keybinding in brackets, for example: "New Tab (Ctrl+T). Although it would be hard to implement as users can change shortcuts.
Repository: node
Issue: ./deps/v8/third_party/zlib instead of the copy in ./deps/zlib ?
Labels: zlib,dependencies

This is not a bug, rather a deduplication idea:
a lot of ./deps/zlib is similar to ./deps/v8/third_party/zlib.
Repository: godot
Issue: Delete, rename, open confuses godot editor.
Labels: bug,discussion,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:	
https://github.com/godotengine/godot/issues?q=is%3Aissue	
-->

**Godot version:**
3.2.1


**OS/device including version:**
Fedora 32/KDE, it does not matter.

**Issue description:**
Delete, rename, open flow confuses godot editor.

**Steps to reproduce:**
1.) Open a scene, 1.tscn (scene A).
2.) Open a scene, 2.tscn (scene B).
3.) Delete scene 1.tscn.
4.) Rename scene 2.tscn to scene 1.tscn.
5.) Open 1.tscn.

Expected behaviour: show scene B
Actual behaviour: shows scene A
Repository: rust
Issue: Tracking issue for `#![feature(const_precise_live_drops)]`
Labels: A-destructors,T-lang,T-compiler,B-unstable,C-tracking-issue,A-const-eval,S-tracking-needs-summary

This is a tracking issue for a more precise version of checking for drops in `const` contexts.

The feature gate for the issue is `#![feature(const_precise_live_drops)]`.

With this feature enabled, drops are checked on slightly elaborated MIR. This makes the analysis that prevents dropping in `const fn` more accurate for code that does not actually drop anything: specifically, if the initial MIR contains an unnecessary call to `drop` that may be eliminated in elaboration, it can be accepted with `const_precise_live_drops`.

Internally, the library can also use this on a per-function basis with `#[rustc_allow_const_fn_unstable(const_precise_live_drops)]`.

### 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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps

- [x] implementation:  #71824

### Blockers and Concerns:

- https://github.com/rust-lang/rust/issues/91009
- Changes to what exact elaboration occurs may change what we accept
- (per Ralf on Zulip): ideally this would run on the same MIR and with the same logic as borrowck, but that is hard.
Repository: flutter
Issue: Text widget incorrectly wraps Korean text
Labels: framework,a: internationalization,dependency: skia,a: typography,has reproducible steps,P2,found in release: 3.7,found in release: 3.9,team-framework,triaged-framework,fyi-text-input

The Text widget breaks Korean words in the middle - see screenshot.  This does not happen with English text, where the lines break along spaces, as expected.

## Steps to Reproduce

```
@override
Widget build(BuildContext context) {
  return Text('조선시대의 인구 조사에 따르면 조선의 인구는 대체로 700만 명을 넘지 못했다. 조세와 부역 등을 피하려고 호구조사를 기피하는 등 여러 가지 요인으로 40% 가까이 누락되었을 것으로 추측되고');
```

**Expected results:**

Lines break along spaces.

**Actual results:**

Lines break in middle of words.  See screenshot below.

![image](https://user-images.githubusercontent.com/66804265/84442793-4ecf1280-ac0c-11ea-917f-1998178a5817.png)
Repository: TypeScript
Issue: Provide a better display experience for unresolved values and types
Labels: Suggestion,In Discussion,Rescheduled

Today, an unresolved type, or the type of an unresolved variable will look something like `any`. Internally, these resolve to a well-known error type that semantically acts as `any`.

However, in https://github.com/microsoft/TypeScript/issues/37713, we may not have a full picture of the world because we're limited to a single file.

I think we should consider doing two things

1. In the syntactic mode, the type of any unresolved symbol should be of a new `any`-like type called `loading`.
2. anywhere else, usage of an unresolved type should "stick around" and be recognized as a type reference to an extremely permissive type. This could be implemented through something similar to https://github.com/microsoft/TypeScript/issues/38836

According to @CyrusNajmabadi, Roslyn already does something really similar to this.
Repository: TypeScript
Issue: Expand when `isNewIdentifierLocation` is set in the syntax server
Labels: Suggestion,In Discussion

In https://github.com/microsoft/TypeScript/issues/37713, we might not have a full picture of the world, so it might overly restrictive to only suggest identifiers in the current file. We should consider being more permissive so that editors don't aggressively auto-complete on identifiers in these contexts.
_____

Aside: if we do this, we should make sure that the work done in https://github.com/microsoft/TypeScript/issues/38836 doesn't cause conflicts.

For example, let's say you have an empty file like

```ts
thing/**/
```

and completions get triggered at `/**/`. A user **should not** get completions for `thing` at that point.
Repository: TypeScript
Issue: Consider loose completions in the syntax server on unresolved/error types
Labels: Suggestion,In Discussion

Assume that no type named `Foo` exists in the current project, and assume the current file.

```ts
export let x: Foo;

x./**/
```

When requesting completions at `/**/`, we should consider giving a list of identifiers in the current file, similar to what we do for `any` in JavaScript files. This contrived example isn't great, but when opening a larger file, this could be helpful.

This is somewhat related to

* https://github.com/microsoft/TypeScript/issues/5334, where we considered giving identifier completions whenever hitting `any`
* https://github.com/microsoft/TypeScript/issues/39032, where we discussed producing these special `loading` types and unresolved error types.
Repository: TypeScript
Issue: Partial Semantic Mode Meta-Issue
Labels: Meta-Issue,Rescheduled

See https://github.com/microsoft/TypeScript/issues/37713 as a pre-requisite for this issue!

____

https://github.com/microsoft/TypeScript/pull/38561 implements the core idea proposed in https://github.com/microsoft/TypeScript/issues/37713.

Beyond that, there is still a set of UX issues that we should probably address:

- [x] make cross-file go-to-definition work in the syntax-only server (https://github.com/microsoft/TypeScript/issues/39037)
- [ ] make find-all-refs work on unresolved locals (https://github.com/microsoft/TypeScript/issues/38836)
- [ ] better display experience for error types on the syntax server (https://github.com/microsoft/TypeScript/issues/39032)
- [ ] expand when `isNewIdentifierLocation` on the syntax server (https://github.com/microsoft/TypeScript/issues/39033)
- [ ] consider loose completions on the syntax server on unresolved/error types (https://github.com/microsoft/TypeScript/issues/39034)
Repository: rust
Issue: Ztime-passes: columns not always seperated
Labels: T-compiler,C-bug,A-self-profile

Sometimes when compiling code with `-Ztime-passes`, there is no space between rss column and the pass-name column:
````
time: 0.001; rss: 110MB	match_checking
time: 0.000; rss: 110MB	liveness_and_intrinsic_checking
time: 0.002; rss: 110MB	misc_checking_2
time: 0.016; rss: 117MB	MIR_borrow_checking
time: 0.000; rss: 117MB	MIR_effect_checking
time: 0.000; rss: 117MB	layout_testing
time: 0.000; rss: 117MB	death_checking
time: 0.000; rss: 117MB	unused_lib_feature_checking
time: 0.000; rss: 117MB	crate_lints
time: 0.000; rss: 117MB	module_lints
time: 0.001; rss: 117MB	lint_checking
time: 0.000; rss: 117MB	privacy_checking_modules
time: 0.003; rss: 117MB	misc_checking_3
time: 0.000; rss: 117MB	monomorphization_collector_root_collections
time: 0.000; rss: 51MBparse_crate
time: 0.000; rss: 51MBattributes_injection
time: 0.000; rss: 54MBrecursion_limit
time: 0.000; rss: 54MBplugin_loading
time: 0.000; rss: 54MBplugin_registration
time: 0.000; rss: 54MBpre_AST_expansion_lint_checks
time: 0.000; rss: 54MBcrate_injection
time: 0.009; rss: 67MBexpand_crate
time: 0.000; rss: 67MBcheck_unused_macros
time: 0.010; rss: 67MBmacro_expand_crate
time: 0.000; rss: 67MBmaybe_building_test_harness
time: 0.000; rss: 67MBAST_validation
time: 0.000; rss: 67MBmaybe_create_a_macro_crate
time: 0.000; rss: 67MBcomplete_gated_feature_checking
time: 0.011; rss: 67MBconfigure_and_expand
time: 0.001; rss: 67MBprepare_outputs
time: 0.000; rss: 67MBhir_lowering
time: 0.000; rss: 67MBearly_lint_checks
time: 0.000; rss: 70MBsetup_global_ctxt
time: 0.000; rss: 70MBdep_graph_tcx_init
time: 0.001; rss: 70MBcreate_global_ctxt
time: 0.000; rss: 72MBlooking_for_entry_point
time: 0.000; rss: 72MBlooking_for_plugin_registrar
time: 0.000; rss: 72MBlooking_for_derive_registrar
````

``
rustc 1.46.0-nightly (feb3536eb 2020-06-09)
binary: rustc
commit-hash: feb3536eba10c2e4585d066629598f03d5ddc7c6
commit-date: 2020-06-09
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0
``