Add a smoke test for non-empty nullptr Span

[Ivorforce]

• Follow-up to GDScript Tokenizer crash when reporting mixed spaces and tabs for indentation on the first line #107422

The above bug occurred because a Span was created from nullptr with a size > 0. This is incorrect, because it's promising access to a memory region that does not exist.

We can catch this, at least for the nullptr case, by adding a smoke test. This should help us catch such bugs early in the future. The above bug could only have occurred in DEBUG builds, so it would have been prevented by this test.

The test is pretty cheap, so it shouldn't create performance problems for DEBUG. I'd still hesitate to add it to RELEASE because correct code should not need it, and in hot loops, it may actually prevent vectorization. Plus, setting _len = 0 is unlikely to be the correct fix anyway (though it should be better than nothing).

Note: Unfortunately, this change requires the function to be non-constexpr, because ERR_PRINT isn't constexpr. This can be fixed in c++20 with std::is_constant_evaluated. Fortunately, we do not use this property yet, so for Godot 4.5 we can give it up. In 4.6, we're planning to upgrade to C++20, so we can re-add constexpr then.

[lawnjelly]

Could we do this, or is too risky of having things compile in release but not debug? (and vice versa) 🤔

The CI checks should be pretty good at catching any problems as they do editor and template builds.

#ifdef DEBUG_ENABLED
	_FORCE_INLINE_ Span(const T *p_ptr, uint64_t p_len) :
			_ptr(p_ptr), _len(p_len) {
		// TODO In c++20, make this check run only in non-consteval, and make this constructor constexpr.
		if (_ptr == nullptr && _len > 0) {
			ERR_PRINT("Internal bug, please report: Span was created from nullptr with size > 0. Recovering by using size = 0.");
			_len = 0;
		}
	}
#else
	_FORCE_INLINE_ constexpr Span(const T *p_ptr, uint64_t p_len) :
			_ptr(p_ptr), _len(p_len) {}
#endif

[Ivorforce]

That would work, but i think since it's effectively constexpr anyway, it should be compiled as such with or without the constexpr modifier. The only difference being that we won't be able to use it in constexpr contexts, which is also the case with separate DEBUG and RELEASE definitions.

[akien-mga]

Thanks!