feat: Implement `feature(exhaustive_patterns)` from unstable Rust by iDawer · Pu... - JOYK Joy of Geek, Geek News, Link all geek

Conversation

Contributor

iDawer commented 7 days ago

Recognize Rust's unstable #![feature(exhaustive_patterns)] (RFC 1872). Allow omitting visibly uninhabited variants from match expressions when the feature is on.

This adjusts match checking to the current implementation of the postponed RFC 1872 in rustc.

RalfJung and Stargateur reacted with heart emojiVeykril reacted with rocket emoji All reactions

Contributor

Author

I cannot find how r-a handles unstable features. Is it just silently accepts a wider superset of stable Rust?
This PR adds an ugly ad-hoc feature detection. Don't like it! Could be designed better for sure but.
Are there other places in r-a that could benefit from feature detection infrastructure? Making it fully fledged for the sake of the only match checking feels.. IDK
Alternatively, assume that exhaustive_patterns enabled for everything effectively turning the current false errors in nightly Rust into false no-errors in stable when omitting uninhabited variants.

Quick performance test not showing visible degradation. Should not be fooled, it iterates root attributes on each match expression!

Open question:

Feature detection design/decision (feat: Implement feature(exhaustive_patterns) from unstable Rust #13167 (comment))

Member

lnicola commented 7 days ago

Is it just silently accepts a wider superset of stable Rust?

Yes. I don't think we've felt the need for more until now.

crates/hir-ty/src/diagnostics/match_check/usefulness.rs

Outdated

		pub(super) fn feature_exhaustive_patterns(&self) -> bool {
		// FIXME see MatchCheckCtx::is_uninhabited
		false
		*self.feature_exhaustive_patterns.get_or_init(\|\| {
		let def_map = self.db.crate_def_map(self.module.krate());
		let root_mod = def_map.module_id(def_map.root());
		let rood_attrs = self.db.attrs(root_mod.into());
		let mut nightly_features = rood_attrs
		.by_key("feature")
		.attrs()
		.map(\|attr\| attr.parse_path_comma_token_tree())
		.flatten()
		.flatten();
		nightly_features.any(
		\|feat\| matches!(feat.segments(), [name] if name.to_smol_str() == "exhaustive_patterns"),
		)
		})

Member

Veykril 7 days ago •

edited

I think we should record the all enabled features in the DefMap instead of parsing them here. We will need the enabled features for completions as well once we implement honoring them there (and probably other places can benefit from knowing features as well).
Then exposing the feature list from the def map seems fine as an API until more things make use of it at which point we can reconsider I'd say.

iDawer and lnicola reacted with thumbs up emoji All reactions

Contributor

Author

iDawer 6 days ago

Done.

All reactions

iDawer

marked this pull request as draft

7 days ago

iDawer

marked this pull request as ready for review

6 days ago

crates/hir-def/src/nameres.rs

		@@ -114,6 +114,8 @@ pub struct DefMap {
		registered_attrs: Vec<SmolStr>,
		/// Custom tool modules registered with `#![register_tool]`.
		registered_tools: Vec<SmolStr>,
		/// Unstable features of Rust enabled with `#![feature(A, B)]`.
		unstable_features: FxHashSet<SmolStr>,

Member

Veykril 6 days ago •

edited

I think we can just go with a Vec here, there aren't gonna be too many features so searching a Vec seems fine, though I suppose it doesn't really matter

All reactions

Member