profile
viewpoint

alexcrichton/toml-rs 637

A TOML encoding/decoding library for Rust

dtolnay/cargo-expand 614

Subcommand to show result of macro expansion

ehuss/cargo-prefetch 19

Cargo subcommand to download popular crates.

dqsully/atom-column-select 9

Atom package to enhance column selection.

ehuss/cargo-index 7

Cargo subcommand to manage a registry index.

ehuss/anno-2205-layouts 2

Tool for Anno 2205 layouts.

ehuss/atom-wrap-plus 2

Enhanced word wrapping for the Atom editor.

ehuss/cargo-clone-crate 1

Cargo subcommand to clone a repo from the registry.

ehuss/dotfiles 1

My dotfiles.

issue openedrust-lang/rustc-dev-guide

Document `RUSTFLAGS_STAGE_` environment variables

I just learned about these today: https://github.com/rust-lang/rust/pull/47836

Previously, I was modifying src/bootstrap/bin/rustc.rs and adding a check for a specific crate name. Knowing about these flags would have saved me time.

created time in an hour

issue commentrust-lang/cargo

Filter and build integration tests needed only

Ah, I did not know cargo --test part_a exists, I believe it would be nice to add an example for that. Yes, all my functions are prefixed with part_a, so cargo test part_a should work.

pickfire

comment created time in an hour

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs+[error index]: https://doc.rust-lang.org/error-index.html+[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md++### Lints versus fixed diagnostics++Some messages are emitted via [lints](#lints), where the user can control the+level. Some are hard-coded such that the user cannot control the level.++Hard-coded warnings should be avoided for normal code, preferring to use lints+instead. Some cases, such as warnings with CLI flags will require the use of+hard-coded warnings.++See the `deny` [lint level](#diagnostic-levels) below for guidelines when to+use an error-level lint instead of a fixed error.++## Diagnostic output style guide++- Write in plain simple English. If your message, when shown on a – possibly+  small – screen (which hasn't been cleaned for a while), cannot be understood+  by a normal programmer, who just came out of bed after a night partying,+  it's too complex.+- `Error`, `Warning`, `Note`, and `Help` messages start with a lowercase+  letter and do not end with punctuation.+- Error messages should be succinct. Users will see these error messages many+  times, and more verbose descriptions can be viewed with the `--explain`+  flag. That said, don't make it so terse that it's hard to understand.+- The word "illegal" is illegal. Prefer "invalid" or a more specific word+  instead.+- Errors should document the span of code where they occur – the `span_..`

I think that this may be the location of the span methods that you are referring to here? It might be helpful to elaborate so that they are easier to locate?

- Errors should document the span of code where they occur – the `librustc_errors::diagnostic_builder::DiagnosticBuilder`  `span_*` 
ehuss

comment created time in 2 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs+[error index]: https://doc.rust-lang.org/error-index.html+[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md++### Lints versus fixed diagnostics++Some messages are emitted via [lints](#lints), where the user can control the+level. Some are hard-coded such that the user cannot control the level.++Hard-coded warnings should be avoided for normal code, preferring to use lints+instead. Some cases, such as warnings with CLI flags will require the use of+hard-coded warnings.++See the `deny` [lint level](#diagnostic-levels) below for guidelines when to+use an error-level lint instead of a fixed error.++## Diagnostic output style guide++- Write in plain simple English. If your message, when shown on a – possibly+  small – screen (which hasn't been cleaned for a while), cannot be understood+  by a normal programmer, who just came out of bed after a night partying,

😂

ehuss

comment created time in 3 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs+[error index]: https://doc.rust-lang.org/error-index.html+[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md++### Lints versus fixed diagnostics++Some messages are emitted via [lints](#lints), where the user can control the+level. Some are hard-coded such that the user cannot control the level.++Hard-coded warnings should be avoided for normal code, preferring to use lints+instead. Some cases, such as warnings with CLI flags will require the use of+hard-coded warnings.++See the `deny` [lint level](#diagnostic-levels) below for guidelines when to+use an error-level lint instead of a fixed error.++## Diagnostic output style guide++- Write in plain simple English. If your message, when shown on a – possibly+  small – screen (which hasn't been cleaned for a while), cannot be understood+  by a normal programmer, who just came out of bed after a night partying,+  it's too complex.+- `Error`, `Warning`, `Note`, and `Help` messages start with a lowercase+  letter and do not end with punctuation.+- Error messages should be succinct. Users will see these error messages many+  times, and more verbose descriptions can be viewed with the `--explain`+  flag. That said, don't make it so terse that it's hard to understand.+- The word "illegal" is illegal. Prefer "invalid" or a more specific word+  instead.+- Errors should document the span of code where they occur – the `span_..`+  methods allow to easily do this. Also `note` other spans that have+  contributed to the error if the span isn't too large.+- When emitting a message with span, try to reduce the span to the smallest+  amount possible that still signifies the issue+- Try not to emit multiple error messages for the same error. This may require+  detecting duplicates.+- When the compiler has too little information for a specific error message,+  lobby for annotations for library code that allow adding more. For example+  see [`#[rustc_on_unimplemented]`](#rustc_on_unimplemented). Use these+  annotations when available!+- Keep in mind that Rust's learning curve is rather steep, and that the+  compiler messages are an important learning tool.+- When talking about the compiler, call it `the compiler`, not `Rust` or+  `rustc`.++### Lint naming++From [RFC 0344], lint names should be consistent, with the following+guidelines:++The basic rule is: the lint name should make sense when read as "allow+*lint-name*" or "allow *lint-name* items". For example, "allow+`deprecated` items" and "allow `dead_code`" makes sense, while "allow+`unsafe_block`" is ungrammatical (should be plural).++- Lint names should state the bad thing being checked for, e.g. `deprecated`,+  so that `#[allow(deprecated)]` (items) reads correctly. Thus `ctypes` is not+  an appropriate name; `improper_ctypes` is.++- Lints that apply to arbitrary items (like the stability lints) should just+  mention what they check for: use `deprecated` rather than+  `deprecated_items`. This keeps lint names short. (Again, think "allow+  *lint-name* items".)++- If a lint applies to a specific grammatical class, mention that class and+  use the plural form: use `unused_variables` rather than `unused_variable`.+  This makes `#[allow(unused_variables)]` read correctly.++- Lints that catch unnecessary, unused, or useless aspects of code should use+  the term `unused`, e.g. `unused_imports`, `unused_typecasts`.++- Use snake case in the same way you would for function names.++[RFC 0344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints++### Diagnostic levels++Guidelines for different diagnostic levels:++- `error`: emitted when the compiler detects a problem that makes it unable to+  compile the program, either because the program is invalid or the programmer+  has decided to make a specific `warning` into an error.++- `warning`: emitted when the compiler detects something odd about a program.+  Care should be taken when adding warnings to avoid warning fatigue, and+  avoid false-positives where there really isn't a problem with the code. Some+  examples of when it is appropriate to issue a warning:++  - A situation where the user *should* take action, such as swap out a+    deprecated item, or use a `Result`, but otherwise doesn't prevent+    compilation.+  - Unnecessary syntax that can be removed without affecting the semantics of+    the code. For example, unused code, or unnecessary `unsafe`.+  - Code that is very likely to be incorrect, dangerous, or confusing, but the+    language technically allows, and is not ready or confident enough to make+    an error. For example `unused_comparisons` (out of bounds comparisons) or+    `bindings_with_variant_name` (the user likely did not intend to create a+    binding in a pattern).+  - [Future-incompatible lints](#future-incompatible), where something was+    accidentally or erroneously accepted in the past, but rejecting would+    cause excessive breakage in the ecosystem.+  - Stylistic choices. For example, camel or snake case, or the `dyn` trait+    warning in the 2018 edition. These have a high bar to be added, and should+    only be used in exceptional circumstances. Other stylistic choices should+    either be allow-by-default lints, or part of other tools like Clippy or+    rustfmt.++- `help`: emitted following an `error` or `warning` to give additional+  information to the user about how to solve their problem. The error or+  warning portion should *not* suggest how to fix the problem, only the "help"+  sub-diagnostic should.

Maybe add a comment along the lines of:

"These messages include a suggestion string and librustc_errors::Applicability confidence level to guide automated source fixes by tools"

ehuss

comment created time in 2 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on the CLI.

     - [Emitting Errors and other Diagnostics](diagnostics.md)         - [`LintStore`](./diagnostics/lintstore.md)         - [Diagnostic Codes](./diagnostics/diagnostic-codes.md)+    - [Command-line arguments](./cli.md)

I would suggest moving this to the top of Part 3, next to the rustc-driver chapter.

ehuss

comment created time in 2 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on the CLI.

+# Command-line Arguments++Command-line flags are documented in the [rustc book][cli-docs]. All *stable*+flags should be documented there. Unstable flags should be documented in the+[unstable book].++## Guidelines++- Flags should be orthogonal to each other. For example, if we'd have a+  json-emitting variant of multiple actions `foo` and `bar`, an additional+  `--json` flag is better than adding `--foo-json` and `--bar-json`.+- Avoid flags with the `no-` prefix. Instead, use the [`parse_bool`] function,+  such as `-C embed-bitcode=no`.+- Consider the behavior if the flag is passed multiple times. In some+  situations, the values should be accumulated (in order!). In other+  situations, subsequence flags should override previous flags (for example,+  the lint-level flags). And some flags (like `-o`) should generate an error+  if it is too ambiguous what multiple flags would mean.+- Always give options a long descriptive name, if only for more understandable+  compiler scripts.+- The `--verbose` flag is for adding verbose information to `rustc` output+  when not compiling a program. For example, using it with the `--version`+  flag gives information about the hashes of the code.
  flag gives information about the hashes of the compiler code.
ehuss

comment created time in 2 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on the CLI.

+# Command-line Arguments++Command-line flags are documented in the [rustc book][cli-docs]. All *stable*+flags should be documented there. Unstable flags should be documented in the+[unstable book].++## Guidelines++- Flags should be orthogonal to each other. For example, if we'd have a+  json-emitting variant of multiple actions `foo` and `bar`, an additional+  `--json` flag is better than adding `--foo-json` and `--bar-json`.+- Avoid flags with the `no-` prefix. Instead, use the [`parse_bool`] function,+  such as `-C embed-bitcode=no`.+- Consider the behavior if the flag is passed multiple times. In some+  situations, the values should be accumulated (in order!). In other+  situations, subsequence flags should override previous flags (for example,
  situations, subsequent flags should override previous flags (for example,
ehuss

comment created time in 2 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs+[error index]: https://doc.rust-lang.org/error-index.html+[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md++### Lints versus fixed diagnostics++Some messages are emitted via [lints](#lints), where the user can control the+level. Some are hard-coded such that the user cannot control the level.++Hard-coded warnings should be avoided for normal code, preferring to use lints+instead. Some cases, such as warnings with CLI flags will require the use of+hard-coded warnings.++See the `deny` [lint level](#diagnostic-levels) below for guidelines when to+use an error-level lint instead of a fixed error.++## Diagnostic output style guide++- Write in plain simple English. If your message, when shown on a – possibly+  small – screen (which hasn't been cleaned for a while), cannot be understood+  by a normal programmer, who just came out of bed after a night partying,+  it's too complex.+- `Error`, `Warning`, `Note`, and `Help` messages start with a lowercase+  letter and do not end with punctuation.+- Error messages should be succinct. Users will see these error messages many+  times, and more verbose descriptions can be viewed with the `--explain`+  flag. That said, don't make it so terse that it's hard to understand.+- The word "illegal" is illegal. Prefer "invalid" or a more specific word+  instead.+- Errors should document the span of code where they occur – the `span_..`+  methods allow to easily do this. Also `note` other spans that have+  contributed to the error if the span isn't too large.+- When emitting a message with span, try to reduce the span to the smallest+  amount possible that still signifies the issue+- Try not to emit multiple error messages for the same error. This may require+  detecting duplicates.+- When the compiler has too little information for a specific error message,+  lobby for annotations for library code that allow adding more. For example

What do you mean by "lobby for annotations"? Do you mean ask the owners of a system for them?

ehuss

comment created time in 3 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->

I would prefer if we make it a visible TODO in the text or open an issue. It's likely to get forgotten if we leave it as a comment like this.

ehuss

comment created time in 3 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs+[error index]: https://doc.rust-lang.org/error-index.html+[RFC 1567]: https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md++### Lints versus fixed diagnostics++Some messages are emitted via [lints](#lints), where the user can control the+level. Some are hard-coded such that the user cannot control the level.

"Some are hard-coded"... what does this mean? it seems like most compiler errors are intentionally un-overridable, right? Or is this specifically about lints?

ehuss

comment created time in 3 hours

Pull request review commentrust-lang/rustc-dev-guide

Add some guidelines on diagnostics.

 error: the fobrulator needs to be krontrificated When code or an identifier must appear in an message or label, it should be surrounded with single acute accents \`. +### Error explanations++Some errors include long form descriptions. They may be viewed with the+`--explain` flag, or via the [error index]. Each explanation comes with an+example of how to trigger it and advice on how to fix it.++Please read [RFC 1567] for details on how to format and write long error+codes.++The descriptions are written in markdown, and all of them are linked in the+[`librustc_error_codes`] crate.++<!-- TODO: When should an error use an error code, and when shouldn't it? -->++[`librustc_error_codes`]: https://github.com/rust-lang/rust/blob/master/src/librustc_error_codes/error_codes.rs
[`librustc_error_codes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_error_codes/error_codes/index.html

In general, the convention is to link to the rustdocs when possible.

ehuss

comment created time in 3 hours

IssuesEvent

issue closedmatklad/tom

Revive the project

Hey, I'd like to try getting involved into this project mainly for the benefit of rust-analyzer.

@matklad would you be able to review or at least approve and merge prs here? Also, do you have any ideas on how to integrate this with ra?

Just some thoughts on high-level architecture: I think we can expose smth like ra_ide tom_ide API and add this crate as a dependency to rust-analyzer binary.

Also, it seems like we should avoid Cargo.toml specificity here, but I'd like to actually provide features for this specific case (like adding hints for packages versions ala vscode crates extension). It's hard to think how we could achieve this if we want to abstract from toml files content semantic interpretation. Or do you think adding such a feature here (maybe behind features = ["cargo_toml"]) wont be bad?

Also could you please take a quick rereview of the issues here to close potentially no-longer actual ones?

closed time in 4 hours

Veetaha

issue commentmatklad/tom

Revive the project

Also, I am not sure about the naming. I moved the code under crates/tom and crates/tom_lsp_server. I am not sure whether we should rename tom -> tom_syntax

Veetaha

comment created time in 4 hours

issue commentrust-lang/cargo

"cargo install --target-dir" does not work

Would like to work on this!

RalfJung

comment created time in 4 hours

push eventmatklad/tom

veetaha

commit sha 8d20331392008f8ad0f8d44b8b273e431dfb0d41

Add cargo-deny

view details

Veetaha

commit sha b60a49e552bc1f4ec49ab84a963a1fc4611e2f85

Merge pull request #38 from Veetaha/feat/add-cargo-deny Add cargo-deny

view details

push time in 4 hours

PR merged matklad/tom

Add cargo-deny
+71 -7

0 comment

4 changed files

Veetaha

pr closed time in 4 hours

PR opened matklad/tom

Add cargo-deny
+70 -7

0 comment

3 changed files

pr created time in 4 hours

push eventmatklad/tom

veetaha

commit sha bcadeb111231646b114ef0077cfcebdeac1a2516

Add vscode extension debug configurations

view details

Veetaha

commit sha b8de3dd0127666bac8b5ba5a0d104f806963a342

Merge pull request #37 from Veetaha/feat/add-debug-configs Add vscode extension debug configurations

view details

push time in 4 hours

PR merged matklad/tom

Add vscode extension debug configurations
+165 -3

0 comment

4 changed files

Veetaha

pr closed time in 4 hours

PR opened matklad/tom

Add vscode extension debug configurations
+165 -3

0 comment

4 changed files

pr created time in 4 hours

push eventmatklad/tom

veetaha

commit sha 4deae10b0f5c41f5b40e9c2af34c7a3cae366483

Remove tslint.json as it is no-longer used

view details

Veetaha

commit sha ef1e9f0a235fd39263149e82d0f06213daf3f44a

Merge pull request #36 from Veetaha/feat/transition-to-ra-like-ts-extension-setup Remove tslint.json as it is no-longer used

view details

push time in 5 hours

push eventmatklad/tom

veetaha

commit sha fa42f180bb8c6b1a5f7edfaa511ba81181a15101

Transition to rust-analyzer-like TypeScript extension setup

view details

Veetaha

commit sha 1adbe2094af91e7bf65adf1f6134454216e65001

Merge pull request #35 from Veetaha/feat/transition-to-ra-like-ts-extension-setup Transition to rust-analyzer-like TypeScript extension setup

view details

push time in 5 hours

issue commentrust-lang/cargo

Make `cargo outdated` part of cargo itself

Thanks for the cc @kbknapp I'm in the middle of wrapping up at my current job, but I should be more free starting next week to really look into this :)

behnam

comment created time in 5 hours

PR merged rust-lang/crates.io

Correct actions syntax S-waiting-on-review

r? @jtgeibel

+4 -4

4 comments

1 changed file

JohnTitor

pr closed time in 5 hours

more