sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net/url: PathEscape treatment of reserved characters is inconsistent
Labels: NeedsInvestigation

`;` and `,` are permitted by [RFC 3986](https://tools.ietf.org/html/rfc3986#page-23) in path segments, but `PathEscape` percent-encodes them because "URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents". However, it does _not_ escape other reserved characters potentially subject to the same kind of special treatment:
* `=` is "often used to delimit parameters and parameter values", particularly in conjunction with `;` (e.g., "name;v=1.1")
* `.` is used in `.` and `..` "dot-segments" to "indicate relative position within the hierarchical tree of names… interpreted within the URI path hierarchy… removed as part of the resolution process".
* `:` is not allowed in the first path segment of a relative-path reference, "as it would be mistaken for a scheme name" (e.g., a URI reference of "foo:bar/baz/quux" is very different from "foo-bar/baz/quux").

### What version of Go are you using (`go version`)?
1.11

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
linux amd64

### What did you do?
https://play.golang.org/p/f-byVa3k2gi
```go
pathSegments := []string{"non-scheme:non-authority", "foo=bar;bar=baz", ".."}
for i, segment := range pathSegments {
	pathSegments[i] = url.PathEscape(segment)
}
fmt.Println(strings.Join(pathSegments, "/"))
```

### What did you expect to see?
`non-scheme%3Anon-authority/foo%3Dbar%3Bbar%3Dbaz/%2E%2E` (all potentially special characters percent-encoded), or maybe `non-scheme:non-authority/foo=bar;bar=baz/..` (no characters percent-encoded unless required by RFC).

### What did you see instead?
`non-scheme:non-authority/foo=bar%3Bbar=baz/..`
Repository: flutter
Issue: [Material] Include support for cut corner borders in NoStrokeInputBorder widget
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

Widget is introduced in #21289
Repository: flutter
Issue: platform_channel and platform_channel_swift examples don't seem to work with the iOS simulator
Labels: e: device-specific,platform-ios,engine,d: examples,has reproducible steps,P3,team-ios,triaged-ios,found in release: 3.22,found in release: 3.23

I tried doing `flutter run` in `flutter/examples/platform_channel` and in `flutter/examples/platform_channel_swift` on my macOS machine using an iPhone 8 Plus simulator that used iOS 11.4.  In both cases, the example app reports "Battery level: unknown" and "Battery status: unknown".  Tapping on the "Refresh" button shows "Failed to get battery level."

I haven't tried it with a physical iOS device because I don't have a provisioning profile set up.
Repository: go
Issue: x/text/message/catalog: documentation mentions type that doesn't exist
Labels: Documentation,NeedsInvestigation

In the documentation for [`golang.org/x/text/message/catalog`] it says:

>  Package catalog defines various interfaces: Dictionary, Loader, and Message.

But there is no such type `Loader`. I started to change the documentation, but wasn't sure if this was an oversight, something that was removed, or some functionality that hadn't been committed yet.

/cc @mpvl 

[`golang.org/x/text/message/catalog`]: https://godoc.org/golang.org/x/text/message/catalog
Repository: TypeScript
Issue: Inserting intersections with 'Function' while narrowing breaks code
Labels: Suggestion,Breaking Change,Awaiting More Feedback

@ahejlsberg and I ran into something like this in the RWC. This currently repros on the nightlies.

```ts
function foo(x: Object | (() => string)) {
    if (typeof x === "function") {
        // Previously had no errors
        x();
    }
}
```

**Expected**: No error

**Actual**:

```
[ts] Cannot invoke an expression whose type lacks a call signature. Type '(() => string) | (Object & Function)' has no compatible call signatures.
```

Potentially related to #25243.
Repository: TypeScript
Issue: Import type is escaped
Labels: Bug,Domain: Declaration Emit

**TypeScript Version:**  3.1.0-dev.20180906

**Code**

```ts
// @declaration: true

// @Filename: /jalapeño.ts
export interface I { x: number; }
export function f(): I { return { x: 0 }; }

// @Filename: /a.ts
import { f } from "./jalapeño";
export const x = f();
```

**Expected behavior:**

`a.d.ts` is: `export declare const x: import("./jalapeño").I;`

**Actual behavior:**

`a.d.ts` is: `export declare const x: import("./jalape\u00F1o").I;`
Repository: go
Issue: x/vgo: delete repo in March 2019 (1 month after Go 1.12)
Labels: NeedsFix

Since Go 1.11 was released several issues related to mixing vgo and go 1.11 have been logged, eg, #27562

I propose that vgo should be changed to work only with versions of Go in the range [1.10.3,1.11)
Repository: rust
Issue: -C remark=loop-vectorize doesn't point to the source line
Labels: A-LLVM,C-enhancement,A-diagnostics,T-compiler,C-optimization

I was trying to use `-C remark` to understand why a loop didn't get vectorized. You can [see the simple example code on godbolt](https://rust.godbolt.org/z/KHuX1A).

```rust
fn simple_loop(values: &[u32; 1024]) -> u32 {
    values.into_iter().fold(0, |acc, i| { /* something */ })
}
```

The loop itself isn't very important, the issue is with what the remark message says:

```
note: optimization analysis for loop-vectorize at /checkout/src/libcore/slice/mod.rs:2431:20: ...
```
As you can see, instead of saying something like `at <source_file>:2:5: ...`, it points to a method in the standard library. In this case, there was only one iterator loop in the file, but it quickly becomes impossible to determine which loop it refers to if there are multiple ones.

A temporary solution is to give up on Rust's iterators and use a primitive `while` loop to get an accurate indication:

```rust
let mut i = 0;
while i < 1024 { /* ... */ }
```

Now the message becomes:

```rust
note: optimization analysis for loop-vectorize at <source>:14:4: ...
```

So it's easier to determine which loop it was referring to.
Repository: rust
Issue: Slow performance of std::iter::Rev with iterator adapters using std::iter::Iterator::nth()
Labels: I-slow,C-enhancement,E-mentor,T-libs-api,A-iterators

The following example shows a benchmark of the iterator adapter `step_by()`. Once using `step_by()` directly on the range and once with a redirection via `rev()`.

```rust
use test::Bencher;

#[bench]
fn bench_forward_skip(b: &mut Bencher) {
    b.iter(|| (0..10001).step_by(100).sum::<i32>());
}

#[bench]
fn bench_reverse_skip(b: &mut Bencher) {
    b.iter(|| (0..10001).rev().step_by(100).sum::<i32>());
}
```

Running this benchmark with the current nightly shows these results:

```
test tests::bench_forward_skip ... bench:         137 ns/iter (+/- 6)
test tests::bench_reverse_skip ... bench:       3,878 ns/iter (+/- 327)
```

`step_by()` makes use of `nth()` of the adapted iterator. A range provides an optimized version of `nth()`, but by using `rev()` we get to use the default implementation of `nth()`.

We should Extend `std::iter::DoubleEndedIterator` to provide a new method maybe `nth_back()` or `rnth()` with a default implementation which then can get adapted by `rev()`. Similar to the already existing `next_back()`, `try_rfold()`, `rfold()` and `rfind()`.

**Update:**

`nth_back()` has been merged in #56802. Types which have a specialized `nth()` and implement `DoubleEndedIterator` are candidates for a specialized `nth_back()`. The following list shows these candidates and their implementation status:

- [x] Box (#59328)
- [x] Bytes (#60023)
- [X] Chain (#60492)
- [X] Chunks (#61048)
- [x] ChunksExact (#62064)
- [X] ChunksExactMut (#63265)
- [x] ChunksMut (#62074)
- [X] &mut DoubleEndedIterator (#56802)
- [x] Enumerate (#60023)
- [x] Fuse _(default fn)_ (#60023)
- [x] Fuse _(where FusedIterator)_ (#60023)
- [x] slice::Iter _(defined by a macro)_ (#60772)
- [x] slice::IterMut _(defined by a macro)_ (#60772)
- [x] Range (#61671)
- [x] RangeInclusive (#61671)
- [X] RChunks (#60555)
- [X] RChunksExact (#60555)
- [X] RChunksExactMut (#60555)
- [X] RChunksMut (#60555)
- [X] Rev (#56802)
- [x] Skip (#60454)
- [X] Windows (#59328)
- [ ] Zip
- [ ] Zip _(in ZipImpl default fn)_
- [ ] Zip _(in ZipImpl where TrustedRandomAccess)_
Repository: flutter
Issue: Table > TableRow > TableCell colspan
Labels: c: new feature,framework,f: material design,customer: crowd,c: proposal,P2,team-design,triaged-design

Hi,

How can I have a colspan in the Table Widget ?

Mean:
|--------|--------| 
|..**`col1`**..|..**`col2`**.|   
|--------|--------| 
|.........**`col3`**........|
|--------|--------| 

Thank you.
Repository: opencv
Issue: Bad error message from VideoWriter::open() about unknown fourcc
Labels: category: videoio,RFC

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

Please:

* Read the documentation to test with the latest developer build.
* Check if other person has already created the same issue to avoid duplicates. You can comment on it if there already is an issue.
* Try to be as detailed as possible in your report.
* Report only one problem per created issue.


This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV =>  3.4.0
- Operating System / Platform => all
- Compiler => all

##### Detailed description

<!-- your description -->

When one runs the following code:

fourcc = cv2.VideoWriter_fourcc(*'PIM1')
out = cv2.VideoWriter('output.mpeg',fourcc, 20.0, (640,480))

The code complains about an invalid fourcc value, but still runs correctly.

##### Steps to reproduce

The problem seems to be in cap_ffmpeg_impl.hpp  ( CvVideoWrite_FFMPEG::open )

This code first uses the file extension (av_guess_format) to find an appropriate list of fourcc's to check for. If it does not find the fourcc in this list, it then uses a default list of fourcc's ( avformat_get_mov_video_tags).  The fourcc checks are using av_codec_get_id().

After if finds a fourcc match, it then validates that the fourcc is in the original list from the file extension, and prints an error message if this is the case.  When the fourcc is from the default list, it does not match the original list, so an error message is always printed in this case.  The error message is just informational and does not change the program flow.

There seems to be two solutions:
   (1) remove the final valid step (not sure why needed)
   (2) validate against the default list when use default list (this seems to be the easier of the two)

The change for (2) is quite small:
```
diff modules/videoio/src/cap_ffmpeg_impl.hpp  hold/
1930d1929
<     const AVCodecTag *const *chk_tags = fmt->codec_tag;
1961,1963c1960
<         }else{
< 	  chk_tags = fallback_tags;
< 	}
---
>         }
1966c1963
<     if (cv_ff_codec_tag_list_match(chk_tags, codec_id, fourcc) == false)
---
>     if (cv_ff_codec_tag_list_match(fmt->codec_tag, codec_id, fourcc) == false)
```

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: rust
Issue: Treat closures as `move` when their type escapes their captures' scope.
Labels: C-enhancement,A-closures,T-lang,T-compiler

Unlike previously discussed *inference* of `move` from lifetimes (which has been deemed unfeasible/undesirable), we can completely ignore lifetime bounds and NLL analysis.

*Note: everything discussed here "trivially" doesn't pass lifetime inference/checks currently, so allowing such code to compile should be entirely backwards-compatible.*

<hr/>

Instead, I think we should focus on expressions that had their types inferred to contain closure types, and compare their (lexical/"drop") scopes with the scopes the closure captures are declared in, e.g.:
```rust
let x = String::new();
let f = {
    let y = vec![0];
    Some(|| (x.clone(), y.clone()))
};
```
`typeof f` is `Option<closure>`, where the closure captures `x` and `y`, and *the only way* the closure could be capturing any of them by reference, is if their scopes contain the scope of `f`.
This is true for `x` (assuming `f` is as far as the closure escapes), but *not* `y`, and the closure should *therefore* capture `x` by value, allowing that code to compile without explicit `move`.

Another, perhaps more common example is `.flat_map(|x| (0..n).map(|i| x + i))` - the inner closure escapes the scope of `x` (by being returned from the outer closure).

<hr/>

If the closure is turned into a trait object (e.g. `Box<dyn Fn(...) -> _>`) in the scope where it is created in (with all the captures in scope), we can't change anything there, since it'd require lifetime analysis.

But since the stabilization of `impl Trait`, it's becoming increasingly common to return various types that contain closures (such as iterators), and that case can be *readily* served by this change, e.g.:
```rust
fn compose<A, B, C>(
    f: impl Fn(A) -> B,
    g: impl Fn(B) -> C,
) -> impl Fn(A) -> C {
    // Currently requires `move`, but we can solve that.
    /*move*/ |x| g(f(x))
}
```

<hr/>

There's only one issue I could think of, with this approach: `Copy` by-value captures can have surprising outcomes, in that the capture leaves the original accessible, without a syntactical indication, e.g.:
```rust
let outer_get_x = {
    let mut x = 0;
    let get_x = || x;
    x += 1;
    get_x
};
assert_eq!(outer_get_x(), 0);
```
If `x` were to be declared before `outer_get_x`, then this code would not compile, as the closure would be borrowing it (which would conflict with `x += 1` mutating `x`), instead of holding onto a copy of it.

What can we do? I think that ideally we'd treat the closure as capturing by borrow, but only in terms of preventing mutable access to `x` for the remainder of its scope, and otherwise capture a copy.
(Then you could only observe a problem if you had a copyable type with interior mutability.)

But I'm not sure what the best implementation approach for that would be.

cc @nikomatsakis @cramertj @withoutboats
Repository: go
Issue: gccgo: internal compiler error: in mangled_name
Labels: NeedsInvestigation

## Update
I change package domain from `9fans.net` to `fans.net`, it can build without any error.
I think package domain can't start with number in gccgo.

--------------
gccgo 8.2.0 work well in most case at my **SunOS 5.10/SPARC** mechine.
But compiler error when I trying to build `9fans.net/go/draw`

I try gccgo in Windows WSL, and the error can be reproduced.

### What version of Go are you using (`go version`)?
go1.10.3 gccgo (GCC) 8.2.0 solaris/sparc
go1.10.3 gccgo (GCC) 8.2.0 linux/amd64(in windows WSL)

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
SunOS 5.10/SPARC
windows10 WSL(ubuntu)/amd64

### What did you do?
```bash
cd $GOPATH/src/9fans.net/go/draw
go build
```

### What did you expect to see?
success build

### What did you see instead?
```
# 9fans.net/go/draw/drawfcall
go1: internal compiler error: in mangled_name, at go/gofrontend/names.cc:539
0x668549 Type::mangled_name[abi:cxx11](Gogo*) const
        ../../gcc-8.2.0/gcc/go/gofrontend/names.cc:539
0x710b8a Gogo::specific_type_function_names(Type const*, Named_type const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*)
        ../../gcc-8.2.0/gcc/go/gofrontend/names.cc:290
0x74f897 Type::specific_type_functions(Gogo*, Named_type*, long, Function_type*, Function_type*, Named_object**, Named_object**)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:2014
0x74e395 Type::type_functions(Gogo*, Named_type*, Function_type*, Function_type*, Named_object**, Named_object**)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:1946
0x6e9a02 Specific_type_functions::type(Type*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2424
0x7378d2 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:318
0x73a324 Forward_declaration_type::do_traverse(Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:12059
0x7378e8 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:326
0x6e9988 Specific_type_functions::type(Type*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2447
0x7378d2 Type::traverse(Type*, Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/types.cc:318
0x6ecedc Bindings::traverse(Traverse*, bool)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:7950
0x6ed101 Gogo::traverse(Traverse*)
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2498
0x6ed197 Gogo::write_specific_type_functions()
        ../../gcc-8.2.0/gcc/go/gofrontend/gogo.cc:2474
0x6e876a go_parse_input_files(char const**, unsigned int, bool, bool)
        ../../gcc-8.2.0/gcc/go/gofrontend/go.cc:162
0x6e456f go_langhook_parse_file
        ../../gcc-8.2.0/gcc/go/go-lang.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
```
Repository: TypeScript
Issue: Covariant assignability of type guard functions is unsound
Labels: Suggestion,Help Wanted,Committed

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  master (af8e44a)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** user-defined type guard predicate assignable assignability unsound covariant invariant

**Code**

```ts
class A {
    a: string;
}
class B extends A { 
    b: string;
}
function isB(x: {}): x is B { 
    return x instanceof B;
}
const isA: (x: {}) => x is A = isB;  // allowed, should be compile error

const x = <A | string>new A();
if (!isA(x)) {
    console.log(x.slice());  // runtime error
}
```

**Expected behavior:** Assignability error where marked.

**Actual behavior:** Successful compilation, runtime error.

**Playground Link:** [link](https://www.typescriptlang.org/play/#src=class%20A%20%7B%0D%0A%20%20%20%20a%3A%20string%3B%0D%0A%7D%0D%0Aclass%20B%20extends%20A%20%7B%20%0D%0A%20%20%20%20b%3A%20string%3B%0D%0A%7D%0D%0Afunction%20isB(x%3A%20%7B%7D)%3A%20x%20is%20B%20%7B%20%0D%0A%20%20%20%20return%20x%20instanceof%20B%3B%0D%0A%7D%0D%0Aconst%20isA%3A%20(x%3A%20%7B%7D)%20%3D%3E%20x%20is%20A%20%3D%20isB%3B%20%20%2F%2F%20allowed%2C%20should%20be%20error%0D%0A%0D%0Aconst%20x%20%3D%20%3CA%20%7C%20string%3Enew%20A()%3B%0D%0Aif%20(!isA(x))%20%7B%0D%0A%20%20%20%20console.log(x.slice())%3B%20%20%2F%2F%20runtime%20error%0D%0A%7D%0D%0A)

**Related Issues:** #24865

If we want a kind of type guard function that is covariant, we need to not narrow when it returns false, i.e., a "true" result would be sufficient but not necessary for the value to be of the tested type.  And we'd need a different syntax for the type of a type guard function that is necessary and sufficient compared to a type guard function that is sufficient but not necessary.  One idea for the latter is `(x: {}) => x is A | false`.  (A type guard function that is necessary but not sufficient would then be `(x: {}) => x is A | true`.)  Getting all these variants supported would help us support conjunctions and disjunctions of type guard calls with other boolean expressions in #24865.  If you like, this issue can be for the removal of the unsound assignability rule and I can file a separate suggestion for the new kinds of type guard functions.
Repository: go
Issue: cmd/compile: eliminate unnecessary extend-of-truncate calculations in prove pass
Labels: Performance,NeedsInvestigation,compiler/runtime

Consider:

```go
func f(x uint64) uint64 {
  return uint64(uint32(x))
}
```

If, when inlined, x is known to be small, then f can be replaced by the identity function.

I was curious, so I sketched this quickly for a specific case by adding this case to `func simplifyBlock` in prove.go:

```go
		case OpZeroExt32to64:
			if trunc := v.Args[0]; trunc.Op == OpTrunc64to32 {
				orig := trunc.Args[0]
				lim, ok := ft.limits[orig.ID]
				if !ok {
					continue
				}
				if lim.umax < (1<<32) || (lim.max < (1<<31) && ft.isNonNegative(orig)) {
					if b.Func.pass.debug > 0 {
						b.Func.Warnl(v.Pos, "Proved %v bounded", v.Op)
					}
					v.reset(OpCopy)
					v.AddArg(orig)
				}
			}
```

It triggers just a few times during make.bash.

This issue is to explore whether adding more cases makes this trigger enough times to be worth doing. There are lots more variants of signed/zero extension, and maybe other ways to generalize this optimization. (It also needs tests, both of correctness and that the optimization triggers.) Also, my limit tests in the code above could easily have fencepost problems. :)

cc @rasky @randall77
Repository: go
Issue: cmd/gofmt: call("arg", newline /* comment */) is changed to syntax error
Labels: NeedsFix

### What version of Go are you using (`go version`)?
go version go1.10.3 windows/amd64

### Does this issue reproduce with the latest release?
Yes, see https://play.golang.org/p/Gv-AmNeMSdT

### What did you do?
Open https://play.golang.org/p/Gv-AmNeMSdT, click Format.

### What did you expect to see?
After formatting, the program still compiles.

### What did you see instead?
Gofmt removes the comma, leading to a syntax error:

> prog.go:8:33: syntax error: unexpected newline, expecting comma or )