sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: go/build: ImportDir/Import no longer return os not found error for missing dir on local files
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

1.9

### Does this issue reproduce with the latest release?

Yes. Was not present before latest release.

### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mfarina/Code/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.9/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.9/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ml/55r2m1jd38x068q85txj8cvc0000gn/T/go-build428826794=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

### What did you do?

I have code that uses `ImportDir` (from the `go/build` package) to look at the packages used by another package. If there is an error from `ImportDir` the automation acts on the error to try and fix the problem.

### What did you expect to see?

I expected a missing directory to cause the returned error to be able to be detected by `os.IsNotExist`. This is how previous version of Go worked.

### What did you see instead?

The returned error was in the form of

```go
   fmt.Errorf("cannot find package %q in:\n\t%s", path, p.Dir)
```

In 1.8.3 (and before), the `Import` function would fall through to [`ctxt.readDir`](https://github.com/golang/go/blob/go1.8.3/src/go/build/build.go#L691) that used `io.ReadDir`...

https://github.com/golang/go/blob/352996a381701cfa0c16e8de29cbde8f3922182f/src/go/build/build.go#L171-L177

In 1.9 The code is a little different for local files. Instead the code stops at...

https://github.com/golang/go/blob/c8aec4095e089ff6ac50d18e97c3f46561f14f48/src/go/build/build.go#L687-L695

You can no longer rely on `os.IsNotExist` to detect missing package directories.

_This change was not documented in the release notes, either._
Repository: electron
Issue: Embed External Native Windows
Labels: enhancement :sparkles:

There is no clean method of taking a native window and embedding it into the application. I think, at least for desktop applications, this should be mainstreamed as virtually any other UI toolkit can accomplish this without many issues.
Repository: flutter
Issue: Add oldest supported iOS simulator tests
Labels: a: tests,team,platform-ios,P3,team-ios,triaged-ios

Devicelab iOS tests should also be run on iOS 8 and 9. Since physical devices have a nasty habit of being irreversibly updated to newer OS releases, and we need more simulator coverage anyway, simulators seem like the most reasonable approach.
Repository: rust
Issue: Tracking Issue for RFC 1826:  Change the default URL of doc.rust-lang.org
Labels: T-rustdoc,P-medium,B-RFC-approved,A-docs,T-infra,C-tracking-issue

This is a tracking issue for the RFC 1826 (rust-lang/rfcs#1826).

**Steps:**

- [ ] Implement the RFC 
- [ ] Switch doc.rust-lang.org over, which is sort of "stabilization" in this case.

**Unresolved questions:**

No official ones, but there will undoubtedly be tweaks during implementation.

NB: a prototype is at https://rust-docs.herokuapp.com, source here: https://github.com/steveklabnik/rust-docs This can serve as a starting point for discussing said details, but does not literally have to be the basis of implementation.
Repository: flutter
Issue: Scale text on Cupertino widgets to match iOS text sizes
Labels: platform-ios,framework,a: accessibility,a: fidelity,f: cupertino,P3,team-ios,triaged-ios

For Cupertino widgets, we need to figure out how to scale our text sizes so that when someone asks for a "headline" or other named sizes on iOS, they get the size that they expect.

On Android, there is a single FONT_SCALE (a double) that scales the font based on a system preference, but on iOS, the font size preference doesn't scale linearly with the different font usages.  For instance, an Extra Extra Extra Large headline on iOS is 18% larger, whereas a footnote is only 15% larger, and an "Extra Large" headline is 5% larger, while an "Extra Large" caption3 doesn't change size at all.

![iOS Font Size Table](https://i.stack.imgur.com/RiXd5.png)[](url)
(table from this [stackoverflow post](https://stackoverflow.com/questions/20510094/how-to-use-a-custom-font-with-dynamic-text-sizes-in-ios7/20510095#20510095))

In order to make sure that Cupertino assets get the sizes that match what iOS does, we'll probably need to change the tables in [`typography.dart`](https://github.com/flutter/flutter/blob/1b9c6a68351bc2925118494df185acdde6cb7936/packages/flutter/lib/src/material/typography.dart#L66) so that instead of fixed values for the font sizes, we do something more clever on each platform based on the preferred type size and the usage for the font.
Repository: neovim
Issue: Switch buffers before emitting modified buffer message
Labels: ux

In a simple usability improvement, error messages like

```
E37: No write since last change
E:162: No write since last change for buffer "[No Name]" (or whatever)
```

should be emitted _after_ the buffers between "current buffer" and "modified buffer in question" have been closed. i.e. when that error message is shown, the buffer being referenced should be the buffer loaded into view.

Currently, the behavior is 

```
nvim -u NORC
:set hidden
ifoo bar
:enew
:q
```

will result in the error messages above showing, while the contents of the newly-created buffer are visible. Pressing `ENTER` causes the newly-created (unmodified) buffer to be closed and the modified buffer triggering the error to show.
Repository: neovim
Issue: Unmodified buffers with set hidden causes multiple error messages on quit
Labels: ux,bug-vim

Just another usability enhancement, trivial importance:

- `nvim --version`: NVIM v0.2.1-867-gd2cbc31
- Vim (version: ) behaves differently? no
- Operating system/version: n/a
- Terminal name/version: n/a
- `$TERM`: xterm-256color (n/a)

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC
:set hidden
ifoo<ESC>
:q
```

### Actual behaviour
Two error messages are emitted:

```
E37: No write since last change
E162: No write since last change for buffer "[No Name]"
```

### Expected behaviour
The two errors are redundant. E162 provides more information and should be shown. There's no reason for E37 to also be shown.
Repository: rust
Issue: Tracking issue: RFC 2103 - attributes for tools
Labels: A-attributes,T-compiler,E-help-wanted,C-tracking-issue,disposition-merge,finished-final-comment-period,S-tracking-needs-summary

Support scoped attributes for white-listed tools, e.g., `#[rustfmt::skip]`

[RFC](https://github.com/rust-lang/rfcs/blob/master/text/2103-tool-attributes.md)
[discussion thread](https://github.com/rust-lang/rfcs/pull/2103)

- [x] implement for attributes ([mentoring instructions here](https://github.com/rust-lang/rust/issues/44690#issuecomment-331979427))
- [ ] implement for lints (https://github.com/rust-lang/rust/pull/52018; see https://github.com/rust-lang/rust/issues/44690#issuecomment-405749334)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

Current status: stabilised for attributes, some work still to do on lints.

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation
Repository: vscode
Issue: Unify indentation and formatting APIs
Labels: editor-autoindent,under-discussion

Maybe this is wishful thinking but I am experiencing many subtle issues with the relatively new [`editor.autoIndent` feature](https://code.visualstudio.com/updates/v1_14#_auto-indent-on-type-move-lines-and-paste). It's a very useful one and I want to keep it but it misbehaves quite frequently, see e.g. issues #29390, #32333 and [many others](https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3Aeditor-indentation%20label%3Abug). Quite a good example is this (from #32835):

Indentation via Format Document:

```tsx
const MyReactComponent = (props) => {
    return (
        <div>
            <Helmet titleTemplate='%s'>
                <title>Hello</title>
            </Helmet>
        </div>
    );
};
```

Formatting via Reindent Lines:

```tsx
const MyReactComponent = (props) => {
    return (
        <div>
        <Helmet titleTemplate='%s'>
        <title>Hello</title>
        </Helmet>
        </div>
    );
};
```

It often seems to me that [formatting API](https://code.visualstudio.com/blogs/2016/11/15/formatters-best-practices) produces better results than [indentation rules](https://code.visualstudio.com/updates/v1_14#_auto-indent-on-type-move-lines-and-paste) but even if that wasn't always the case it just seems logical to have a single API to power both features. It seems like this to me:

1. **Indenting** functionality cares about the **leading whitespaces**.
2. **Formatting** cares about the above **_plus_ anything after the first non-whitespace character**.

So it's a subset / superset problem and I don't think it should be implemented twice, in a completely different manner. What do you think? Would there be a chance to unify the two APIs and eliminate some bugs along the way?

---

For reference, some key issues related to this:

- Auto Indent / Code Formatting / Beautify #4039
- improve indentation rules #17868
- Options for automatic indentation #19303
Repository: go
Issue: runtime: use atomic.Store instead of simple assignment
Labels: NeedsInvestigation,early-in-cycle,compiler/runtime

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
master

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
any

May be it would be better to use `atomic.Load` here? https://github.com/golang/go/blob/master/src/runtime/mprof.go#L443
Anyway it lookg strange - we use atomic operation to store value and non atomic value to read it.
Repository: vscode
Issue: Support symbolic link folders in areas like debug, extensions
Labels: feature-request

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: 1.16.1
- OS Version: macOS sierra 10.12

Steps to Reproduce:

1. Open a empty workspace
2. Create a file and create a symlink to this file in workspace.
3. On opening the file, the linked file will be open in the editor. The path (on hovering over the opened file name) will be shown for the symlink and opening the file in Finder by right clicking will also open the symlink's parent folder. 

The issue with this is it also causes inconsistency with Git markers in enhanced scrollbar and all extensions which operate on open file (like gitlens for `git blame`).

There should be a editor property to configure this path to be set as original file's path or the symlink's path.

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes
Repository: rust
Issue: Weird error with inference when a function doesn’t compile
Labels: C-enhancement

```rust
fn foo(_: &[String]) -> Vec<std::std::string::String> {
    Vec::new()
}

fn main() {
    let x = foo(&Vec::new());
    foo(&x);
}
```

Here, the `foo` function is obviously wrong – `std::std::string::String`. However, it looks like *rustc* tried to typecheck the rest of the program and now thinks that `x` should have the type `[String]` – because of its use in `foo`. I guess the error message would be more explicit with `x.as_slice()` and that it has something to do with the auto deref coercion?

It results in two messages: the first one, correct, about the `std::std` thing. The second, about `[String`], which is really misleading.
Repository: TypeScript
Issue: Completions for callback parameter names
Labels: Suggestion,In Discussion,Domain: Completion Lists

**TypeScript Version:**  nightly (2.6.0-dev.20170919)

**Code**

```ts
function f(cb: (supercalifragilisticexpialidocious: boolean) => void): void { cb(true); }
f((/**/
```

**Expected behavior:**

Provides parameter name completions.

**Actual behavior:**

No help.
Repository: go
Issue: cmd/compile: cleaner solution for exporting linkname info
Labels: early-in-cycle,compiler/runtime

CL 33911 (e3efdffacdd27786e) added symbol linknames to the export data format, but in a suboptimal way: every symbol written into the export data now includes linkname information, even if they're not actually relevant (e.g., for local variables/labels in inline bodies).

This appears to have been done this way because it's less intrusive and didn't require a version bump for release, but we should do it correctly.

/cc @griesemer
Repository: go
Issue: cmd/compile: don't depend on statictmp_ variables being read only
Labels: NeedsFix,compiler/runtime

In cmd/compile/internal/gc/racewalk.go:
```
		// statictmp's are read-only
		if strings.HasPrefix(n.Sym.Name, "statictmp_") {
			return true
		}
```
This isn't really true. If you do:
```
type T struct {
	x int
}
var y = &T{}
```
Then the `&T` allocates a variable that starts with `statictmp_`, but it is writeable.

I think it would be hard to have a race on these variables, as they are only accessed directly during init functions.  But maybe we should update the comment.

@dvyukov
Repository: kubernetes
Issue: Is sharing GPU to multiple containers feasible?
Labels: sig/scheduling,sig/node,kind/feature,help wanted,area/hw-accelerators,lifecycle/frozen,triage/needs-information,wg/machine-learning

<!-- This form is for bug reports and feature requests ONLY! 

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).
-->

**Is this a BUG REPORT or FEATURE REQUEST?**: feature request
 /kind feature


**What happened**:
As far, we do not support sharing GPU to multiple containers, one GPU can only be assigned to one container at a time. But we do have some requirements on achieving this, is it feasible that we manage GPU just like CPU or memory?

**What you expected to happen**:
sharing GPU to multiple containers just like CPU and memory.
Repository: angular
Issue: `@angular/common/http` request throws an error that cannot be unit tested properly
Labels: area: testing,freq2: medium,area: common/http,type: use-case,P3

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
When `responseType` is `json` and the body of the response is a string (e.g.: url `http://domain.com/url-of-the-created-resource`), there is an error because [JSON.parse](https://github.com/angular/angular/blob/4.4.3/packages/common/http/src/xhr.ts#L187) fails. Previously using `res.json()` with `@angular/http` this did not throw an error but returned the `string` as is. We had unit tests for this but `TestRequest` behaves differently and it does not throw an error so it is impossible to test this behavior using `@angular/common/http/testing`.


## Expected behavior
A: `TestRequest` should behave the same way and throw an error in this case
B: Do not throw an error and have the same behavior as `@angular/http` had


## Minimal reproduction of the problem with instructions
```ts
this.http.request(method, url, {
    observe: "response",
    responseType: "json"
});
```

If body of the response is a string like "https://github.com" it throws an error with real XHR. However it does not throw using `TestRequest.flush`

## What is the motivation / use case for changing the behavior?
To improve reliability of unit tests or fix a potential issue.


## Environment
Angular version: 4.X.X

Browser:
<pre><code>
- [X ] Chrome (desktop) version Latest
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
Others:
<!-- Anything else relevant?  Operating system version, IDE, package manager, HTTP server, ... -->
</code></pre>
Repository: neovim
Issue: Incompatible with Vim when catching errors from Python commands
Labels: vimscript,compatibility,provider

Given `t.vim`:

```vim
try
  python3 meh
catch
  echom v:exception
endtry
```

`vim -u t.vim`:
```
Vim(python3):Traceback (most recent call last):
```

`neovim -u t.vim`:
```
Vim(return):Traceback (most recent call last):
```

There are plugins catching `python3` here explicitly, e.g. vim-maktaba: https://github.com/google/vim-maktaba/blob/2ae8b4478ea9bc2c6c8106acb55ddfb935754fb9/autoload/maktaba/python.vim#L57
Repository: godot
Issue: Mouse wheel scrolling is 3x faster when hovering scrollbar
Labels: bug,topic:editor,confirmed,usability

Godot 2.1.4
Windows 10 64 bits

I just noticed that in the script editor, if you use the mouse wheel over the text, it scrolls normally, but if you hover the vertical scrollbar it scrolls 3 times faster. Not sure if that's intented.

It also happens in the scene tree, probably in more places.
Repository: angular
Issue: The (needed) "index.html" disappears from Location URL upon page refresh or direct navigation
Labels: type: bug/fix,freq1: low,area: router,state: confirmed,router: URL parsing/generation,P3

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
I don't have a ready-made reproduction (sorry, too new at this), but I'm working with a team of folks on a version control repository (Git/Subversion) viewer type of application (rather like the GitHub code browser) where the repository path to be viewed is carried in the Angular app's route URL.  For example, the _repository path_ of a Subversion-versioned project's website index file might be `/trunk/www/index.html`, and the _Angular app's route_ for displaying the contents of that file might be `{{base_href}}/{{project_name}}/view/trunk/www/index.html`.

Note firstly that this all works as expected for most versioned items.  But for paths that actually end in the literal string `index.html`, Angular eats that bit of the location URL and the app shows the parent directory instead.  Now, from the parent directory display of my app (which shows as a directory listing with each subdirectory and file linked, as expected), I can navigate into an `index.html` repository file's display successfully.  But if I refresh the page, I see the Location URL change to have the `index.html` removed and my app again shows the parent directory listing.

I _suspect_ this may have something to do with this [logic in Location's constructor](https://github.com/angular/angular/search?q=_stripIndexHtml), but lack the skillz to prove it:

```this._baseHref = Location.stripTrailingSlash(_stripIndexHtml(browserBaseHref));```

## Expected behavior
I expect that the `index.html` part of a Location URL would be left in place and available to the router and components that need it.


## Environment

<pre><code>
Angular version: 4.3.5

Browser:
- [X] Chromium (desktop) version 60.0.3112.113
 
</code></pre>
Repository: flutter
Issue: Clarify fps in PerformanceOverlay
Labels: engine,c: performance,perf: speed,P2,team-engine,triaged-engine

Hitting 60fps in the PerformanceOverlay doesn't necessarily mean that your app will be 60fps. In fact, the PerformanceOverlay can show 60fps when a trace shows that the app is nowhere close to that.

The PerformanceOverly should make it clear what the 60fps mean that it shows.

This came up while looking at https://github.com/flutter/flutter/issues/12138.
Repository: rust
Issue: Consistent naming for Arm "thumb" targets?
Labels: O-Arm,T-compiler,C-bug,WG-embedded

[This commit](https://github.com/rust-lang/rust/commit/07494ecf78b3d21e8d67fd3a1a33466e63cae05d) changed the armv7-linux-androideabi target from generating Arm code to Thumb code. This may be deemed a valid change but I feel like it deserves at least a short discussion for a number of reasons.

* This is a breaking change for anyone that was relying on that target generating Arm code. e.g., anyone using inline assembly with Arm state only instructions or someone bit fiddling code pointers and maybe some other ways. However, I think it's unlikely someone was doing this.
* There is a convention for the rust target names that generate Thumb code to start with `thumb` instead of `arm`. This is the same convention clang uses for `--target` and LLVM.

Either way, the same change should probably be applied to all the `armv7*` targets for consistency.
Repository: opencv
Issue: 3rdparty/carotene: remove inline asm code
Labels: category: build/install

Currently "carotene" supports two code branches:
- legacy inline asm code (GCC 4.6 and older, doesn't support AARCH64). Currently it is not tested on OpenCV CI.
- optimization via intrinsic functions

Suggestion is to remove inline asm code.

Related: #9440(#9450) #9669
Repository: vscode
Issue: Display line number as hybrid styles
Labels: feature-request,editor-core

I believe there is currently no option to display both absolute and relative line numbers. Available options for vscode are: 'on', 'off', and 'relative'.

The relative shows the relative line numbers for all lines except the current line. The current line is displayed as absolute number.

![vscode](https://user-images.githubusercontent.com/31377202/30665564-05f0bbd2-9e17-11e7-9b37-770ef39fd0a7.png)

It would be nice, however, if we could have both absolute lines and relative lines displayed simultaneously. Here are two examples:

![vs](https://user-images.githubusercontent.com/31377202/30665590-19191e2a-9e17-11e7-9689-d03460126959.png)

![extension](https://user-images.githubusercontent.com/31377202/30665581-12cc620c-9e17-11e7-89d8-965a1682c14d.png)

The above images are from an extension of Visual Studio and the deprecated extension [Relative Line Numbers](https://marketplace.visualstudio.com/items?itemName=extr0py.vscode-relative-line-numbers). The extension is deprecated since VS Code 1.6 where the line number setting was officially supported.

In addition, some of additional features that would be great to have are:

1. to customise the colours of line numbers, preferably to different colours as shown in the 2nd image
1. to customise the positions of the two line numbers so we can choose to place absolute lines at left or right

Since this feature was already supported by an old extension, I imagine it would not be so hard to implement. Would it be possible to support Hybrid Line Number feature in VS Code?