[gcc/devel/rust/master] privacy: PrivacyReporter: Handle builtin and unimplemented types better

[gcc/devel/rust/master] privacy: PrivacyReporter: Handle builtin and unimplemented types better

[Thomas Schwinge]

https://gcc.gnu.org/g:b0527990a14efd5abb857ea7edfd96c7ad78792e

commit b0527990a14efd5abb857ea7edfd96c7ad78792e
Author: Arthur Cohen <arthur.cohen@embecosm.com>
Date:   Fri May 20 13:30:06 2022 +0200

    privacy: PrivacyReporter: Handle builtin and unimplemented types better

Diff:
---
 gcc/rust/privacy/rust-privacy-reporter.cc | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/rust/privacy/rust-privacy-reporter.cc b/gcc/rust/privacy/rust-privacy-reporter.cc
index 1685a969d45..4b010a05b02 100644
--- a/gcc/rust/privacy/rust-privacy-reporter.cc
+++ b/gcc/rust/privacy/rust-privacy-reporter.cc
@@ -163,11 +163,9 @@ PrivacyReporter::check_base_type_privacy (Analysis::NodeMapping &node_mappings,
     case TyTy::PROJECTION:
       return recursive_check (
 	static_cast<const TyTy::ProjectionType *> (ty)->get ());
-    case TyTy::NEVER:
     case TyTy::CLOSURE:
-    case TyTy::ERROR:
-    case TyTy::INFER:
-      rust_unreachable ();
+      sorry_at (locus.gcc_location (),
+		"privacy pass for closures is not handled yet");
       break;
 
       // If we're dealing with a generic param, there's nothing we should be
@@ -180,7 +178,13 @@ PrivacyReporter::check_base_type_privacy (Analysis::NodeMapping &node_mappings,
       // FIXME: Can we really not resolve Dynamic types here? Shouldn't we have
       // a look at the path and perform proper privacy analysis?
     case TyTy::DYNAMIC:
+      // The never type is builtin and always available
+    case TyTy::NEVER:
+      // We shouldn't have inference types here, ever
+    case TyTy::INFER:
       return;
+    case TyTy::ERROR:
+      rust_unreachable ();
     }
 }