Deprecate #![crate_type] and #![crate_name] by bjorn3 · Pull Request #83676 · rust-lang/rust
added 4 commits
March 30, 2021 15:00labels
Mar 30, 2021
bjorn3
deleted the
deprecate_crate_type_name
branch
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Dec 8, 2021…e_name, r=Mark-Simulacrum Deprecate crate_type and crate_name nested inside #![cfg_attr] This implements the proposal in rust-lang#83676 (comment), with a future compatibility lint imposed on usage of crate_type/crate_name inside cfg's. This is a compromise between removing `#![crate_type]` and `#![crate_name]` completely and keeping them as a whole, which requires somewhat of a hack in rustc and is impossible to support by gcc-rust. By only removing `#![crate_type]` and `#![crate_name]` nested inside `#![cfg_attr]` it becomes possible to parse them before a big chunk of the compiler has started. Replaces rust-lang#83676 ```rust #![crate_type = "lib"] // remains working #![cfg_attr(foo, crate_type = "bin")] // will stop working ``` # Rationale As it currently is it is possible to try to access the stable crate id before it is actually set, which will panic. The fact that the Session contains mutable state beyond debugging things also doesn't completely sit well with me. Especially once parallel rustc becomes the default. I think there is currently also a cyclic dependency where you need to set the stable crate id to be able to load crates, but you need to load crates to expand proc macro attributes that may define #![crate_name] or #![crate_type]. Currently crate level proc macro attributes are unstable or completely unsupported (can't remember which), so this is not a problem, but it may become an issue in the future. Finally if we want to add incremental compilation to macro expansion or even parsing, we need the StableCrateId to be created together with the Session or even earlier as incremental compilation determines the incremental compilation session dir based on the StableCrateId.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Dec 8, 2021…e_name, r=Mark-Simulacrum Deprecate crate_type and crate_name nested inside #![cfg_attr] This implements the proposal in rust-lang#83676 (comment), with a future compatibility lint imposed on usage of crate_type/crate_name inside cfg's. This is a compromise between removing `#![crate_type]` and `#![crate_name]` completely and keeping them as a whole, which requires somewhat of a hack in rustc and is impossible to support by gcc-rust. By only removing `#![crate_type]` and `#![crate_name]` nested inside `#![cfg_attr]` it becomes possible to parse them before a big chunk of the compiler has started. Replaces rust-lang#83676 ```rust #![crate_type = "lib"] // remains working #![cfg_attr(foo, crate_type = "bin")] // will stop working ``` # Rationale As it currently is it is possible to try to access the stable crate id before it is actually set, which will panic. The fact that the Session contains mutable state beyond debugging things also doesn't completely sit well with me. Especially once parallel rustc becomes the default. I think there is currently also a cyclic dependency where you need to set the stable crate id to be able to load crates, but you need to load crates to expand proc macro attributes that may define #![crate_name] or #![crate_type]. Currently crate level proc macro attributes are unstable or completely unsupported (can't remember which), so this is not a problem, but it may become an issue in the future. Finally if we want to add incremental compilation to macro expansion or even parsing, we need the StableCrateId to be created together with the Session or even earlier as incremental compilation determines the incremental compilation session dir based on the StableCrateId.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters