regression: ambiguous outer attributes

[BoxyUwU]

• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/DAC098.thoughts_server/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/Emilgardis.stream_alerts/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/Tricked-dev.dws/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/antoniusnaumann.dachterasse/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/cozyGalvinism.becbot-rs/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/fadiinho.manga-suku/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/folafunmi-db.rust-url-shortener-shuttle/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/grandafrato.school_event_safety/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/kaleidawave.discord-weather-bot/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/melkir.net-entreprise-scraper/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/mikeleppane.chat-app-axum/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/mre.zerocal/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/nonsensical-answers.python-rustrict/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/oddgrd.postgres-test-deploy/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/trezm.broken-deploy-example/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/reg/AskAI-0.1.0/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/reg/plow_cli-0.5.2/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/reg/varies-0.1.1/log.txt

[INFO] [stdout] error: ambiguous outer attributes
[INFO] [stdout]    --> src/main.rs:284:17
[INFO] [stdout]     |
[INFO] [stdout] 284 | /                 #[cfg(feature = "rustls")]
[INFO] [stdout] 285 | |                 server = server.listen_rustls(listener, ssl_builder)?;
[INFO] [stdout]     | |_____________________________________________________________________^
[INFO] [stdout]     |

Probably #124099 cc @davidtwco

[davidtwco]

cc @voidc as author of #124099

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

My question here is how do we want to handle the changes in #124099. I don't see a mention of it being aware about breaking changes (PR was even rolled up).

@rustbot label -I-prioritize +P-critical

[voidc]

I looked into each regression. Most are caused by a dependency on rustrict (versions 0.3.13..0.5.14) which contains the following code (source):

    /// TODO: This is untested.
    #[cfg(feature = "reset_censor")]
    pub fn reset(&mut self, text: I) {
        // ...
        #[cfg(any(feature = "find_false_positives", feature = "trace"))]
        self.total_matches = 0;
        // ...
    }

I assume the author meant to apply the attribute to the whole assignment statement but here it only applies to the expression self.total_matches. Applying the attribute to the statement would have required wrapping it in braces. Since the stmt_expr_attributes feature is still unstable, the above code would normally trigger an error. However, because the reset function is conditional on the (untested) reset_censor feature, the unstable feature error was never triggered during normal compilation. In a later commit the reset function was removed.

Besides rustrict there are three more problematic crates: thoughts_server, leptos_router, and varies.
In all of them, the regression boils down to a pattern similar to rustrict.

To summarize, in each case, an attribute is applied to the left-hand side of an assignment, which most likely does not match the authors' intention. This is exactly the kind of mistake that the error introduced in #124099 is meant to prevent.

[riking]

I'm unclear whether this requires nightly to trigger?

This should probably be reverted and changed to a future compat warning.

[apiraino]

Issue was briefly mentioned today in the t-compiler triage meeting (on Zulip).

Seems that given the timeframe leading to the next stable (2024-06-13, in 13 days), a revert would be more appropriate.