Tweak type inference for const operands in inline asm

[Amanieu]

Previously these would be treated like integer literals and default to i32 if a type could not be determined. To allow for forward-compatibility with str constants in the future, this PR changes type inference to use an unbound type variable instead.

The actual type checking is deferred until after typeck where we still ensure that the final type for the const operand is an integer type.

[rustbot]

r? @michaelwoerister

rustbot has assigned @michaelwoerister.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Amanieu]

Unfortunately this fails in tests when an invalid type is passed to const operands.

error: invalid type for `const` operand
  --> /home/amanieu/code/rust/tests/ui/asm/type-check-1.rs:61:20
   |
LL |         asm!("{}", const &0);
   |                    ^^^^^^--
   |                          |
   |                          is a `&i32`
   |
   = help: `const` operands must be of an integer type

error: internal compiler error: compiler/rustc_borrowck/src/universal_regions.rs:880:36: cannot convert `'{erased}` to a region vid

thread 'rustc' panicked at compiler/rustc_borrowck/src/universal_regions.rs:880:36:

This happens because the invalid type now reaches a later compilation stage and is processed by the borrow checker. This seems similar to #96304. @compiler-errors had a PR to fix this in #116087 but that was closed. I'm not exactly sure what the correct approach is for solving this.

[lcnr]

a suggestion: you can move this check into fn anon_const_type_of and return the returned type with ty::Error if it's not an int. THis should also fix the ICE in mir borrowck

[folkertdev]

I tried this here master...folkertdev:rust:const-asm-type-fix and that makes the test work! However, error messages are now emitted out of order. I'm not sure how big a problem that is, and how to fix it if needed.

[folkertdev]

as an extra note, this issue appears to be entirely unrelated to #96304, lifetimes work fine in these const expressions.

core::arch::global_asm!("/* {} */", const Foo::<'static>::X);

struct Foo<'a>(&'a ());

impl<'a> Foo<'a> {
    const X: u64 = 42;
}

[lcnr]

👍 yeah, that's my preferred solution, though I'd maybe keep the check in intrinsicck as an assert in case type_of gets changed in the future. I don't think the message order is something we should worry about here.

[Amanieu]

@rustbot ready

[lcnr]

use the ErrorGuaranteed from the above emit

[lcnr]

same here

[folkertdev]

time to try again? or should we try some specific things? messing with the asm tests is kind of annoying, maybe we could have some sort of lint for the asm-support annotation?

[rustbot]

Failed to set assignee to ready: cannot assign: response: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/assignees#add-assignees-to-an-issue","status":"404"}

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[folkertdev]

ok lol I can't mark this as ready, @Amanieu can you do that?

[Amanieu]

@rustbot ready

[lcnr]

@folkertdev what did you change since the last merge attempt? Would like to avoid having unstable tests in the ui test suite 🤔 could you try and look through the backtrace for the error to check where a hashmap may be involved as suggested by @oli-obk. Alternatively, put the backtrace into a gist and I can take a quick look

[folkertdev]

since the last merge attempt, only eb726a5 was added because that broke a test.

The tests in question are, based on the CI that we've run so far, completely stable in their current form.

In any case, here is a reduced testcase that, based on my understanding of the problem, should have the error in CI

https://gist.github.com/folkertdev/1afae9ede304e8c14040458039bd70c3

it triggers the same error using an invalid sym with both asm! and global_asm!. Locally, the asm! error comes first, but on CI it would come second. It's unclear to me which of the error messages is "at fault" (is one too early, or the other too late) so I've added traces for both.

"hash" does not occur, so it might be something different. But again, to my knowledge, this is not a problem any more for the current PR.

[lcnr]

@bors r+

[bors]

📌 Commit eb726a5 has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit eb726a5 with merge c9687a9...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing c9687a9 to master...

[rust-timer]

Finished benchmarking commit (c9687a9): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Cycles

Results (secondary -6.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.7%	[-6.7%, -6.7%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 761.437s -> 762.407s (0.13%)
Artifact size: 336.80 MiB -> 336.88 MiB (0.03%)