Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considering using Octal Notation in Permissions Errors #16943

Closed
brycefisher opened this issue Sep 2, 2014 · 4 comments · Fixed by #16976
Closed

Considering using Octal Notation in Permissions Errors #16943

brycefisher opened this issue Sep 2, 2014 · 4 comments · Fixed by #16976

Comments

@brycefisher
Copy link

Currently permissions error messages print out the decimal representation of the file permission problem, without any indication of what number base is used (Ex: base 10, 8, or 16). Here's an example taken from a recent travis-ci:

screen shot 2014-09-02 at 8 32 30 am

In an ideal world, this error message would have been "bits: 700" instead of "bits: 448". I see that octal support was mostly added to support Linux file permissions, and it would be nice to use them in errors and debugging too :-)

@Thiez
Copy link
Contributor

Thiez commented Sep 2, 2014

I imagine this should be as easy as removing this line and manually implementing Show to do something along these lines:

impl fmt::Show for S {
    fn fmt(&self, formatter: &mut fmt::Formatter) -> Result<(), fmt::FormatError> {
        formatter.write_str("0o")
            .map_err(|_|fmt::WriteError)
            .and_then(|_|(&self.bits as &fmt::Octal).fmt(formatter))
    }
}

Sadly I do not have a compiler lying around, but if anyone feels inspired, use the above.

@treeman
Copy link
Contributor

treeman commented Sep 4, 2014

Well done @Thiez.

@Thiez
Copy link
Contributor

Thiez commented Sep 4, 2014

Thanks, and the same to you for actually implementing and testing.

@brycefisher
Copy link
Author

thanks!!!

lnicola pushed a commit to lnicola/rust that referenced this issue Apr 7, 2024
Fix tasks in tasks.json

rust-lang#16839 refactored the representation of tasks inside the VS Code extension. However, this data type is exposed to users, who can define their own tasks in the same format in `tasks.json` or `.code-workspace`.

Revert the data type to have a `command` field rather than a `program` field, and document the different fields. This code is also a little complex, so split out a `cargoToExecution` to handle the Task to Execution conversion logic.

After this change, any tasks.json with a `command` field works again. For example, the following tasks.json works as expected:

```
{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "cargo",
			"command": "build",
			"problemMatcher": [
			  "$rustc"
			],
			"group": "build",
			"label": "my example cargo build task"
		}
	]
}
```

Fixes rust-lang#16943 rust-lang#16949
lnicola pushed a commit to lnicola/rust that referenced this issue Apr 20, 2024
Fix tasks in tasks.json

rust-lang#16839 refactored the representation of tasks inside the VS Code extension. However, this data type is exposed to users, who can define their own tasks in the same format in `tasks.json` or `.code-workspace`.

Revert the data type to have a `command` field rather than a `program` field, and document the different fields. This code is also a little complex, so split out a `cargoToExecution` to handle the Task to Execution conversion logic.

After this change, any tasks.json with a `command` field works again. For example, the following tasks.json works as expected:

```
{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "cargo",
			"command": "build",
			"problemMatcher": [
			  "$rustc"
			],
			"group": "build",
			"label": "my example cargo build task"
		}
	]
}
```

Fixes rust-lang#16943 rust-lang#16949
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants