sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: encoding/json: support struct tag for time.Format in JSON Marshaller/Unmarshaller
Labels: Proposal,Proposal-Hold

I will start with the proposal as a TL;DR before explaining the motivations behind it: 

**Proposal**

It would be quite convenient if we could have the `encoding/json` package understand the format of `time.Time` as part of the struct definition. Something like this:

```go
type User struct {
	Name     string
	JoinDate time.Time `time:"2006-01-02"`
}
``` 

This means that when you write `json.Unmarshal(data, &user)`, the json package will understand what format to parse/serialize the field with. 

**Motivation/Experience Report**

Currently, there are three workarounds: 

1. `type MyTime time.Time`: [https://goplay.space/#APZL4Rzlm_](https://goplay.space/#APZL4Rzlm_)

2. Embedding time.Time in MyTime type: https://goplay.space/#q-oKnSTtQV

3. Implementing `json.Unmarshaller` on the parent struct: https://goplay.space/#mzb8MQfajl

Those workarounds are not bad. However, I've noticed that they get out of hand once your codebase starts to scale.

Imagine having hundreds of structs with hundreds of fields where many of them could have different Time types just because they have different serialization formats, and nothing else. 

The `time.Time` package, I think, might be too opinionated to assume RFC3339 is the only acceptable format in the `json.Unmarshaller` interface: https://github.com/golang/go/blob/ce10e9d84574112b224eae88dc4e0f43710808de/src/time/time.go#L1366. (Same goes for RFC3339Nano in the json.Marshaller implementation).

I think it makes sense for it to be a default serialization format, but not the only one. The workaround is initially not bad at all. However, it gets cumbersome when your project scales. 

I think this proposal shows that the above solution can make our code more declarative and less cumbersome. This echo's Rob Pike's [talk](https://www.youtube.com/watch?v=rFejpH_tAHM) in that here we can hide complexity behind a simple interface. 

Lastly, this doesn't make or break my Go experience, but I personally see room for enhancement here.
Repository: rust
Issue: Initializing array of Option<T> using [None; n] syntax should not require std::marker::Copy for T
Labels: T-compiler,C-feature-request,A-array

I am new to Rust so forgive me if this is a stupid assertion.

Currently if you have an array of ```Option<T>``` the ```std::marker::Copy``` must be on ```T``` when using the repeated element syntax while initializing the array.

Case and point:

```rust
let arr: [Option<String>; 5] = [None; 5];
```

Shouldn't the compiler know that it is only "copying" ```None``` and allow the assignment?
Repository: go
Issue: doc: contribution guidelines: reference and/or incorporate docs for git/gerrit
Labels: Documentation,NeedsFix

The contribution guidelines explicitly assume a working knowledge of git and implicitly assume a working knowledge of gerrit.

These are large systems but the average contributor will need to know only a few basics of each to proceed. Linking to appropriate and specific documentation for what is needed in the common case will make it easier for a potential contributor to attain any missing knowledge, judge the necessary time investment of the desired contribution, and, if nothing else, realize that this isn't that complicated.

Git is a very common tool but has many obscure commands and abstruse workflows. Stating that a contributor has a "basic understanding of Git" can mean quite a lot of things, but the understanding necessary is, indeed, quite basic.

Aside from the commands provided by the `codereview` extension, and rare commands needed for troubleshooting, the average contributor whould only need to know a handful of commands and tasks that can be exhaustively listed. Saying something along the lines of "A contributor should be familiar with
- `git add`
- `git branch`
- (and so on)

If not, see _this linked tutorial_", would not add much to the length of the docs but would let a reader say either
- okay, I know all that—great!
- hmm, I guess I need to click that link . . .

While few may need to click that link (or links), it would be very reassuring to know upfront that you won't be spending the afternoon on stackoverflow trying to figure out why `git eldritch-horror` fails with `error: no erorr`. Anyone who does needs to click that link would surely appreciate finding that out before starting.

Gerrit is simpler than git, but it is a much less commonly used tool.

The docs assume far too much knowledge of its use to the point that for the most part it is written as if gerrit is something that just automatically happens outside the contribution process, though it is where everything important takes place. When steps to be taken in gerrit are mentioned it often only says *what* needs to be done and not *how* to do it. This is sufficient for anyone who has used gerrit before but can be intimidating for someone who has never used gerrit. (The [Reviewing code by others](https://golang.org/doc/contribute.html#download) section is an excellent example of a good mix of what and how, though it appears to be outdated).

Like git, there should be very few tasks required of the average contributor that can be exhaustively listed, linking to mini how-tos for general tasks such as drafting and submitting comments.

Screencasts of common tasks and annotated screenshots (even if the annotation is "just ignore this") of various common polygerrit screens could also help demystify the experience. 

The how-tos, screencasts, and screenshots could be hosted on the wiki, if they do not already exist: the important part is that the docs link to those, wherever they may be, when appropriate.

CC @spf13
Repository: rust
Issue: rustc silently ignores invalid -C target-feature names
Labels: C-enhancement,A-diagnostics,T-compiler,A-target-feature

Compiling a simple `Hello, World` program:

```
$ rustc -V
rustc 1.20.0 (f3d6973f4 2017-08-27)

# Note the trailing "zzzz"
$ RUSTFLAGS=-Ctarget-feature=+crt-staticzzzz cargo build -v
   Compiling rust-test v0.1.0 (rust-test)
     Running `rustc --crate-name rust_test src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=aafe1708c049ad76 -C extra-filename=-aafe1708c049ad76 --out-dir rust-test/target/debug/deps -L dependency=rust-test/target/debug/deps '-Ctarget-feature=+crt-staticzzzz'`
    Finished dev [unoptimized + debuginfo] target(s) in 0.25 secs
```

Should `RUSTFLAGS=-Ctarget-feature=+crt-staticzzzz` be silently accepted?

If I pass `RUSTFLAGS=-Ctarget-feature=+batman`, a warning is printed, as expected.

```
'+batman' is not a recognized feature for this target (ignoring feature)
```

Why is trailing misspelling silently allowed?
Repository: rust
Issue: Crate not found when using extern macro in another macro and invoked from another crate
Labels: T-compiler,A-macros-2.0,C-bug

```rust
// -----------------------------------------------
// serde-test/src/lib.rs

//! This crate provides a macro that creates serializable structs.

#![feature(use_extern_macros)]

#[doc(hidden)]
pub extern crate serde_derive;

#[macro_export]
macro_rules! serde_test {
    () => {
        #[derive($crate::serde_derive::Deserialize, $crate::serde_derive::Serialize)]
        pub struct Serializable {
        }
    }
}

// -----------------------------------------------
// serde-test-test/Cargo.toml

[package]
name = "serde-test-test"
version = "0.1.0"
authors = ["Tim Kuehn <tikue@google.com>"]

[dependencies]
serde-test = { path = "../serde-test" }

// -----------------------------------------------
// serde-test-test/src/lib.rs

#![feature(use_extern_macros)]

#[macro_use]
extern crate serde_test;

serde_test! {}
```

In serde-test-test directory:
```$ cargo build
error[E0463]: can't find crate for `_serde`
 --> src/lib.rs:6:1
  |
6 | serde_test! {}
  | ^^^^^^^^^^^^^^ can't find crate
  |
  = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

error: Could not compile `serde-test-test`.

To learn more, run the command again with --verbose.
```

This error goes away if you add `serde = "*"` to serde-test-test/Cargo.toml.
Repository: rust
Issue: `std::io::Read::read_to_end` does not specialize for `&[u8]` or `Take<&'a [u8]>`
Labels: C-enhancement,T-libs,A-io

`read_to_end` currently includes some logic to do exponentially large `.resize` / `.read`  operations.

For `&[u8]` or `Take<&'a [u8]>`, the problem is much simpler as we know the size that will be required :
```rust 
v.extend_from_slice(&data);
let n = v.len();
data = &data[n..];
```

The `manual` implementation is typically between 3 and 5 times faster on my computer.

Assuming what seems a non-pathological case : no resize required, the `Vec` has a sufficient capacity to begin with, and running the following benchmark https://gist.github.com/fulmicoton/a1fb87c3f3578f118552917636c95933
yields the following result :

```
test tests::bench_read_manual ... bench:           9 ns/iter (+/- 1)
test tests::bench_read_std    ... bench:          35 ns/iter (+/- 6)
```
Repository: pytorch
Issue: Learning rate scheduler have different APIs
Labels: module: optimizer,triaged

The default API for step is either step() or step(epoch): https://github.com/pytorch/pytorch/blob/master/torch/optim/lr_scheduler.py#L26

The default API for ReduceLROnPlateau is step(metric):
https://github.com/pytorch/pytorch/blob/master/torch/optim/lr_scheduler.py#L252

Moreover, **this is not documented**. In fact, none of the LR schedulers have .step documented. Please either document this thoroughly or fix it.
http://pytorch.org/docs/master/optim.html#how-to-adjust-learning-rate

cc @vincentqb
Repository: go
Issue: runtime: ebpf uretprobe support
Labels: help wanted,OS-Linux,compiler/runtime

We had issue with using uprobes with ebpf due to dynamic nature of golang stacks. Is there a proposal/way to address that?
Repository: pytorch
Issue: Add the new lr_scheduler which called poly
Labels: module: optimizer,triaged

The learning policy is from [DeepLab v2](https://arxiv.org/abs/1606.00915):

> Learning rate policy: We have explored different learning rate policies when training DeepLab-LargeFOV. Similar to [86], we also found that employing a “poly” learning rate policy (the learning rate is multiplied by (1􀀀 iter max iter )power) is more effective than “step” learning rate (reduce the learning rate at a fixed step size).

If you agree, I open a pull request later.

cc @vincentqb
Repository: rust
Issue: Tracking issue for RFC 2011: Generic assert
Labels: B-RFC-approved,T-libs-api,T-compiler,C-tracking-issue,A-error-handling,A-fmt,Libs-Tracked,PG-error-handling,S-tracking-impl-incomplete,F-generic_assert

This is a tracking issue for rust-lang/rfcs#2011.
The feature gate for the issue is `#![feature(generic_assert)]`.

Sub tracking-issue: #96949.

### 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

- [x] Implementation (see section *Implementation history*)
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

### Blockers

* [Does not work in const eval yet](https://github.com/rust-lang/rust/pull/96496#issuecomment-1126815652).

### Implementation history

* #97233
* #97450
* #97665
* #98148
* #98337
* #111928
* #135139
* #135712
Repository: rust
Issue: Tracking issue for RFC 2045: improving `#[target_feature]`
Labels: A-stability,T-lang,T-libs-api,B-unstable,A-SIMD,C-tracking-issue,Libs-Tracked,S-tracking-design-concerns,A-target-feature

This is a tracking issue for the `#[target_feature]` segment of RFC 2045 (https://github.com/rust-lang/rfcs/pull/2045).
`#[cfg(target_feature)]` was tracked in [#29717](https://github.com/rust-lang/rust/issues/29717) and has since been stabilized.

**Steps**

* [x] Implement the proposed `#[target_feature]` semantics
* [x] Document these semantics: https://github.com/rust-lang/reference/pull/545
* [ ] Stabilize
    * x86_64 & i686
        * [x] The basic set (sse–sse4.2, avx, avx2, ...) (#49664)
        * [x] adx: https://github.com/rust-lang/rust/pull/93745
        * [ ] avx512
        * [x] ~~mmx~~ (never going to be stabilized)
        * [ ] sse4a
        * [ ] tbm
        * [ ] lahfsahf
        * [ ] prfchw
    * [ ] arm
    * [ ] aarch64
    * [ ] hexagon
    * [ ] powerpc
    * [ ] mips

@gnzlbg have anything else you want filled out here?

*(below added from comments on PR)*

- [ ] consensus on the API for run-time feature detection
- [ ] should `cfg!(feature)` work across #[inline(always)] functions, generics, etc?

And some related tasks:

- [x] API breaking change: allow `#[target_feature]` on unsafe functions only
- [x] API breaking change: `#[target_feature = "+feature"]` => `#[target_feature(enable = "feature")]`
- [ ] fix bug: https://github.com/rust-lang/rust/issues/42515
- [x] resolve bug: https://github.com/rust-lang/rust/issues/44367
Repository: go
Issue: x/build: Add gdb to Windows Builders
Labels: OS-Windows,Builders,NeedsFix

As observed in golang/go#22012 the Windows builders do not have gdb causing them to skip any gdb related test. 

Add [gdb to these packages](https://github.com/golang/build/blob/master/env/windows/startup.ps1#L134)
Repository: rust
Issue: Add --slowtest mode to test harness for finding the slowest test
Labels: C-feature-request,A-libtest

[Elixir has this](https://twitter.com/elixirlang/status/912361337287856128). It would be pretty useful for speeding up large testsuites.

Probably should exist as a `--slowtest N` parameter to the test harness, which `cargo test` passes down.

Doubt this needs an RFC?
Repository: rust
Issue: resolve how to handle constants and default binding modes
Labels: T-compiler,C-feature-request

Another interesting question that @tschottdorf encountered when implementing default binding modes: What do we do with constants? The RFC specifies that we ought to treat a `FOO` binding that resolves to a constant as something which can skip through `&T` types -- however, that runs into trouble if the type of the constant itself is `&str` or `&[T]`. The current logic at least skips through all `&T` or `&mut T` types when it skips through *any*, but handling `&str` correctly would require skipping through "only the right number".

@tschottdorf implemented various rules but we should at minimum update the RFC to match.
Repository: go
Issue: cmd/compile: redundant branch
Labels: Performance,compiler/runtime

```
func f(x interface{}) bool {
	if x == nil {
		return false
	}
	switch x.(type) {
	case bool:
		return true
	default:
		return false
	}
}
```
Compiles to
```
	0x0000 00000 (/Users/khr/go/tmp4.go:3)	MOVQ	"".x+8(SP), AX
	0x0005 00005 (/Users/khr/go/tmp4.go:4)	TESTQ	AX, AX
	0x0008 00008 (/Users/khr/go/tmp4.go:4)	JEQ	47
	0x000a 00010 (/Users/khr/go/tmp4.go:7)	JEQ	41
        ...
```
That second branch is useless.  We should get rid of it somehow.
Repository: go
Issue: gotype: type-checking external test files that rely on internal test files fails
Labels: NeedsFix

I tried to use `go/types` to type check a package with internal test files (with `package foo`) and external test files (with `package foo_test`). The internal test files expose some symbols that the external test files consume. This works fine in `go test`. However,  the `go/types` code does not recognize the symbols exported by the internal test files.

I want to use the `go/types` package to write a refactoring tool that consumes external test files that rely on symbols exported by internal tests files, but I can't because of this error.

I think the issue is that the `go/types` import logic ignores the internal `_test.go` files when type-checking the external `_test.go` files. The `go/types` config https://golang.org/pkg/go/types/#Config does not seem to have a knob to import `_test.go` files.

### What version of Go are you using (`go version`)?
```
go version go1.9 darwin/amd64
```

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOOS="darwin"
```

### What did you do?

I created a new package `testgotypes` with 3 files:

`testgotypes.go`, without this file gotype doesn't run:
```
package testgotypes
```

`internal_test.go`, which exports a variable for the external test:
```
package testgotypes

var Export = "hello"
```

`external_test.go`, which tries to access the variable exported by `internal_test.go`:
```
package testgotypes_test

import (
	"testing"

	"testgotypes"
)

func TestExport(t *testing.T) {
	if testgotypes.Export != "hello" {
		t.Error("uh oh")
	}
}
```

I ran tests, which worked just fine:
```
➜  testgotypes git:(master) go test -v  
=== RUN   TestExport
--- PASS: TestExport (0.00s)
PASS
ok  	testgotypes	0.006s
```

Then I tried to run `gotype`, compiled from `/usr/local/Cellar/go/1.9/libexec/src/go/types/gotype.go`:
```
➜  testgotypes git:(master) gotype -x -t .
external_test.go:10:5: Export not declared by package testgotypes
```
It fails with the same error my refactoring code sees.

To sanity check `gotype`, I then renamed `internal_test.go` to `internal.go` to make it part of the non-test build. Then `gotype` is happy:
```
➜  testgotypes git:(master) mv internal_test.go internal.go
➜  testgotypes git:(master) gotype -x -t .
```

### What did you expect to see?
`gotype` successfully type checking `external_test.go`.

### What did you see instead?
`gotype` fails to type check the `external_test.go` file.
Repository: youtube-dl
Issue: Error 404 while trying to download from Vimeo On Demand
Labels: account-needed

Hello, everyone. I am getting an HTTP Error 404: Not Found while trying to download from Vimeo On Demand. Any guess on the reason this is happening? Thanks in advance.

C:\Users\lucas\Desktop\Downloads>youtube-dl -v -u lucas@com https://vimeo.com/ondemand/dozecamadas/190360067 --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '-u', 'PRIVATE', 'https://vimeo.com/ondemand/dozecamadas/190360067', '--verbose']
Type account password and press [Return]:
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2017.09.24
[debug] Python version 3.4.4 - Windows-10-10.0.15063
[debug] exe versions: none
[debug] Proxy map: {}
[vimeo:ondemand] dozecamadas: Downloading webpage
ERROR: Unable to download webpage: HTTP Error 404: Not Found (caused by HTTPError()); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmp1uop9avr\build\youtube_dl\extractor\common.py", line 503, in _request_webpage
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmp1uop9avr\build\youtube_dl\YoutubeDL.py", line 2178, in urlopen
  File "C:\Python\Python34\lib\urllib\request.py", line 470, in open
  File "C:\Python\Python34\lib\urllib\request.py", line 580, in http_response
  File "C:\Python\Python34\lib\urllib\request.py", line 508, in error
  File "C:\Python\Python34\lib\urllib\request.py", line 442, in _call_chain
  File "C:\Python\Python34\lib\urllib\request.py", line 588, in http_error_default
Repository: TypeScript
Issue: Nested Tagged Unions
Labels: Suggestion,In Discussion


**TypeScript Version:**  2.5.2

**Code**

```ts
type A = { type: "a", a: number }
type B = { type: "b", b: number }

type X = { type: A, a: string }
type Y = { type: B, b: string }

let x: X | Y

if (x.type.type === "a") {
	x.a // Type Error
}
```

**Expected behavior:**

I would expect x to have type `X` inside the if-statement after disambiguating the nested tagged union types.

**Actual behavior:**
Repository: go
Issue: cmd/link: stop requiring gold on arm64 when GNU ld is fixed
Labels: NeedsFix

### What version of Go are you using (`go version`)?
Any, more specifically 1.8, 1.9, master, most probably all versions supporting AArch64/arm64 target

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
linux/arm64

### What did you do?

GC on linux/arm64 assumes gold linker availability see `src/cmd/link/internal/ld/lib.go:1182`
When gold is not available gcc fails due to it missing, when it tries to invoke it. All in shared_test.
When gold flag is remove by removing `sys.ARM64`  from codition on `src/cmd/link/internal/ld/lib.go:1173`, build/test fail with 

```
--- FAIL: TestTrivialExecutable (0.29s)
	shared_test.go:66: executing go install -installsuffix=5577006791947779410 -linkshared trivial failed exit status 2:
		# trivial
		/root/go/pkg/tool/linux_arm64/link: running gcc failed: exit status 1
		/usr/bin/ld: /tmp/go-link-151650837/go.o(.data.rel.ro+0x2c0): unresolvable R_AARCH64_ABS64 relocation against symbol `go.link.abihash.libruntime,sync-atomic.so'
		/usr/bin/ld: final link failed: Nonrepresentable section on output
		collect2: error: ld returned 1 exit status
```
And so one for most of the cases shared_test.

### What did you expect to see?

All tests pass. GC working with default binutils ld.

### What did you see instead?

GC failing to build some binaries with binutils ld.
Repository: rust
Issue: Inconsistent linking against stdlib based on whether a Workspace is used
Labels: A-FFI,T-cargo,C-bug

Minimal repro: https://github.com/illicitonion/repro-rustworkspacerpath

I have a dynamic library which I produce. I am trying to split it into a few crates internally, to logically decompose it, and speed up compilation. I would like to end up producing a dylib with no runtime dependencies on the system (as I do when just building one crate).

If I decompose into sub-crates and don't add a [workspace] section to my Cargo.toml, my top-level dylib is produced as I expect. It has no dynamic dependency on libstd listed when I run `otool -L` on my Mac. However, `cargo test --all` doesn't pick up the sub-crate tests.

If I add a [workspace] section to my Cargo.toml, `cargo test --all` picks up the sub-crate tests, but my top-level dylib now has a dynamic dependency on libstd.

As far as I can tell, there doesn't appear to be a way to both have `--all` work, and not pick up a runtime dependency on a dylib which I'd like to avoid.

Which of the following is the bug, I'm not sure:
 1. `cargo test --all` doesn't pick up non-workspace sub-crates
 2. `cargo build` produces different linkage configuration depending on whether you're in a workspace
but it seems wrong that there's no way to get the best of both behaviours.
Repository: vscode
Issue: Allow to switch to folder/workspace without window reload
Labels: feature-request,workbench-state,keep

#34774

1. VSCode, open a no folder vscode
2. Click on the big open folder button in the explorer
3. Notice that VSCode reloads - unlike most other scenarios where we are adding aditional folders where this just happens