-
Notifications
You must be signed in to change notification settings - Fork 386
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
rustfmt ignore deprecated #493
Comments
See rust-lang/rust#73078 to see why In short: it's a bug in rustfmt, should be fixed asap. I think it's best to migrate to |
The change in PR #495 breaks compilation of protobuf 2.15 (at least for me). I know the error is in rustfmt, but until it's fixed, perhaps a more conservative approach could be taken? The PR mentions that this issue should be fixed in 1.44.1, but so far I see the same behaviour adding the two tags to the default example in the Rust playground: Would it be acceptable to revert to the original tag (as in 2.14)? |
@hds can you please provide full example, which does not work? AFAIU,
does not work in root module, but works fine in other modules. |
Just in case, this file is committed to the repostory, it compiles just fine. |
... it is tested with Rust 1.44.1. |
Same here, it works locally, but breaks ci build. Very strange. If I could only reproduce this locally, it just works no matter what I try... |
9 | #![rustfmt::skip]
| ^^^^^^^^^^^^^^^^^
|
= note: for more information, see https://github.com/rust-lang/rust/issues/54726
= help: add `#![feature(custom_inner_attributes)]` to the crate attributes to enable
error[E0658]: non-builtin inner attributes are unstable
--> /home/runner/.cargo/registry/src/github.lhy31512.workers.dev-1ecc6299db9ec823/protobuf-2.15.1/src/well_known_types/wrappers.rs:9:1
|
9 | #![rustfmt::skip]
| ^^^^^^^^^^^^^^^^^
|
= note: for more information, see https://github.com/rust-lang/rust/issues/54726
= help: add `#![feature(custom_inner_attributes)]` to the crate attributes to enable
Compiling rand_hc v0.1.0
Compiling rand_isaac v0.1.1
Compiling rand_xorshift v0.1.1
error: aborting due to 13 previous errors
For more information about this error, try `rustc --explain E0658`.
error: could not compile `protobuf`.
warning: build failed, waiting for other jobs to finish...
error: build failed
##[error]Process completed with exit code 101.
Complete job full log here: https://github.com/sunshine-protocol/sunshine-bounty/pull/106/checks?check_run_id=820586662 |
@dvc94ch your logs say all jobs install rust nightly-2020-02-05, which is quite old. |
... even stable jobs seems to install the same nightly. |
Thanks, that was indeed the problem |
Protobuf 2.15 isn't compiling for rust 1.43 oddly. Protobuf 2.14 does compile using the same compiler. |
@Xaeroxe it is compatible with Rust mininum version 1.44.1, it is documented in changelog. Unfortunately, rust-protobuf dependency on rustfmt macros and clippy make it very hard to make the library compatible with a wide range of rust compiler versions. Life would be much easier if rustfmt supported comment markers, not just rust attributes. And |
I retested locally ensuring 1.44.1 and you are right, it does compile fine outside of the root module. |
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * In particular, Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable all-at-once at text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable all-at-once at text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable all-at-once at text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable all-at-once at text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once at text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
`@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
This is a copy of rust-lang#4296 with these changes: * file is not reopened again to find if the file is generated * first five lines are scanned for `@generated` marker instead of one * no attempt is made to only search for marker in comments `@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
This is a copy of rust-lang#4296 with these changes: * file is not reopened again to find if the file is generated * first five lines are scanned for `@generated` marker instead of one * no attempt is made to only search for marker in comments `@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
This is a copy of #4296 with these changes: * file is not reopened again to find if the file is generated * first five lines are scanned for `@generated` marker instead of one * no attempt is made to only search for marker in comments `@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
This is a copy of rust-lang#4296 with these changes: * file is not reopened again to find if the file is generated * first five lines are scanned for `@generated` marker instead of one * no attempt is made to only search for marker in comments `@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
This is a copy of #4296 with these changes: * file is not reopened again to find if the file is generated * first five lines are scanned for `@generated` marker instead of one * no attempt is made to only search for marker in comments `@generated` marker is used by certain tools to understand that the file is generated, so it should be treated differently than a file written by a human: * linters should not be invoked on these files, * diffs in these files are less important, * and these files should not be reformatted. This PR proposes builtin support for `@generated` marker. I have not found a standard for a generated file marker, but: * Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated) * Phabricator tool which was spawned from Facebook internal tool [also understands `@generated` marker](https://git.io/JnVHa) * Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP) My personal story is that rust-protobuf project which I maintain was broken twice because of incompatibilities/bugs in rustfmt marker handling: [one](stepancheg/rust-protobuf#493), [two](stepancheg/rust-protobuf#551). (Also, rust-protobuf started generating `@generated` marker [6 years ago](https://git.io/JnV5h)). While rustfmt AST markers are useful to apply to a certain AST elements, disable whole-file-at-once all-tools-at-once text level marker might be easier to use and more reliable for generated code.
Now in Rust 1.44, the
tags are now deprecated in favour of
#![rustfmt::skip]
, I tried to replace the tags but for some reason it doesn't work with the autogen code, and I didn't dig deeper.To replicate, I think it's just sufficient when updating to 1.44 and run a cargo fmt and it will format all autogen files in this repo or otherwise.
The text was updated successfully, but these errors were encountered: