From e2bbf0647aa1e78802607dc74d906b94ea127999 Mon Sep 17 00:00:00 2001 From: Oliver Scherer Date: Sat, 30 Nov 2019 18:17:38 +0100 Subject: [PATCH] Explain why "loading" constness from extern crates does not necessarily load anything --- src/librustc_metadata/rmeta/decoder.rs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/librustc_metadata/rmeta/decoder.rs b/src/librustc_metadata/rmeta/decoder.rs index b494c9bdd38..6edd17fe9ab 100644 --- a/src/librustc_metadata/rmeta/decoder.rs +++ b/src/librustc_metadata/rmeta/decoder.rs @@ -1360,11 +1360,15 @@ fn get_macro(&self, id: DefIndex) -> MacroDef { } } + // This replicates some of the logic of the crate-local `is_const_fn_raw` query, because we + // don't serialize constness for tuple variant and tuple struct constructors. fn is_const_fn_raw(&self, id: DefIndex) -> bool { let constness = match self.kind(id) { EntryKind::Method(data) => data.decode(self).fn_data.constness, EntryKind::Fn(data) => data.decode(self).constness, - // Some intrinsics can be const fn + // Some intrinsics can be const fn. While we could recompute this (at least until we + // stop having hardcoded whitelists and move to stability attributes), it seems cleaner + // to treat all const fns equally. EntryKind::ForeignFn(data) => data.decode(self).constness, EntryKind::Variant(..) | EntryKind::Struct(..) => hir::Constness::Const, _ => hir::Constness::NotConst, -- 2.44.0