which causes #4390

I tested

diff --git a/naga/src/valid/function.rs b/naga/src/valid/function.rs
index 23e6204cc..c60f3a7e9 100644
--- a/naga/src/valid/function.rs
+++ b/naga/src/valid/function.rs
@@ -1365,7 +1365,11 @@ impl super::Validator {
     ) -> Result<FunctionInfo, WithSpan<FunctionError>> {
         let mut info = mod_info.process_function(fun, module, self.flags, self.capabilities)?;
 
-        let local_expr_kind = crate::proc::ExpressionKindTracker::from_arena(&fun.expressions);
+        let mut local_expr_kind = crate::proc::ExpressionKindTracker::from_arena(&fun.expressions);
+
+        for (handle, _) in fun.expressions.iter() {
+            local_expr_kind.force_non_const(handle);
+        }
 
         for (var_handle, var) in fun.local_variables.iter() {
             self.validate_local_var(var, module.to_ctx(), &info, &local_expr_kind)

and it doesn't fix, but we should still need correct constness information for fixing the issue.

I thought this should be fine for wgsl-out and the validator. The reason it's not ok in the frontend is because treating them as const changes semantics in a non-spec compliant way. What would be an example where this is an issue?

I do not have concrete example but

I see, that would be a problem indeed. I think the wgsl backend should just not emit function-local consts at all (that would mean reverting 6125ab4 & 8e967db).
As for the validator, I think it should be fine as we aren't evaluating those expressions and we already check constness in the frontend.

The problem is that both let a = 5; and const a = 5 will create same result in IR (named expr), but there is no way to now if expr was defined as (local) const (or is just const-able). I think we will need to refactor

Or alternatively do the reverts and remove const from named_expressions as we use local_table for lookup anyway (and let backends inline local const like it's done in #7213):

Not having them in named_expressions sounds fine to me.

Will this have negative consequences on our ability to generate debug information?

Will this have negative consequences on our ability to generate debug information?

What exactly is considered as debug info in naga?

I don't think this has a strict definition yet, nor is it set in stone. I think currently the spirv backend uses the variable name in the named_expressions to add label the name of certain values to spirv when debug information is enabled. I would be willing to accept this is the wrong place to do it, and I don't know the specifics, but there are spirv-out tests with debug information in the snapshots.

Leaving local const declarations out of named_expressions entirely would be fine with me. When our constant expression and abstract type handling gets better reconciled with validation, we should be able to keep them without any difficulty.