mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
master
rust/tests/ui/lint/deny-inside-forbid-ignored.cli_forbid.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

36 lines
1.3 KiB
Plaintext
Raw Permalink Normal View History

Allow `#[deny(..)]` inside `#[forbid(..)]` as a no-op with a warning Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense. Except it doesn't, because macros. Macros may reasonably use `#[deny]` in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint! Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden, keeping the level at forbid.
2024-10-17 12:34:04 -05:00
error[E0453]: allow(unsafe_code) incompatible with previous forbid
Expand test coverage for deny-inside-forbid interactions
2024-10-18 03:00:11 -05:00
--> $DIR/deny-inside-forbid-ignored.rs:12:17
Allow `#[deny(..)]` inside `#[forbid(..)]` as a no-op with a warning Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense. Except it doesn't, because macros. Macros may reasonably use `#[deny]` in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint! Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden, keeping the level at forbid.
2024-10-17 12:34:04 -05:00
|
LL | #[forbid(unsafe_code)] // NO UNSAFE CODE IN HERE!!
| ----------- `forbid` level set here
...
LL | #[allow(unsafe_code)] // let's have some unsafe code in here
| ^^^^^^^^^^^ overruled by previous forbid
error[E0453]: allow(unsafe_code) incompatible with previous forbid
Expand test coverage for deny-inside-forbid interactions
2024-10-18 03:00:11 -05:00
--> $DIR/deny-inside-forbid-ignored.rs:12:17
Allow `#[deny(..)]` inside `#[forbid(..)]` as a no-op with a warning Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense. Except it doesn't, because macros. Macros may reasonably use `#[deny]` in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint! Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden, keeping the level at forbid.
2024-10-17 12:34:04 -05:00
|
LL | #[forbid(unsafe_code)] // NO UNSAFE CODE IN HERE!!
| ----------- `forbid` level set here
...
LL | #[allow(unsafe_code)] // let's have some unsafe code in here
| ^^^^^^^^^^^ overruled by previous forbid
|
= note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`
error: usage of an `unsafe` block
Expand test coverage for deny-inside-forbid interactions
2024-10-18 03:00:11 -05:00
--> $DIR/deny-inside-forbid-ignored.rs:16:13
Allow `#[deny(..)]` inside `#[forbid(..)]` as a no-op with a warning Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense. Except it doesn't, because macros. Macros may reasonably use `#[deny]` in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint! Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden, keeping the level at forbid.
2024-10-17 12:34:04 -05:00
|
LL | unsafe { /* ≽^•⩊•^≼ */ }
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
note: the lint level is defined here
Expand test coverage for deny-inside-forbid interactions
2024-10-18 03:00:11 -05:00
--> $DIR/deny-inside-forbid-ignored.rs:8:10
Allow `#[deny(..)]` inside `#[forbid(..)]` as a no-op with a warning Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense. Except it doesn't, because macros. Macros may reasonably use `#[deny]` in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint! Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden, keeping the level at forbid.
2024-10-17 12:34:04 -05:00
|
LL | #[forbid(unsafe_code)] // NO UNSAFE CODE IN HERE!!
| ^^^^^^^^^^^
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0453`.
Reference in New Issue Copy Permalink