Fully qualify std Result type

[alilleybrinker]

The prior macro expansion could produce errors if the macros were called in a context where Result is redefined, for example in a crate with its own Result type which pre-fills the error type. This replaces existing Result uses with std::result::Result to avoid the compilation error in that case.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	50da4a7
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/6926ac2c9428d200086cfb29

[codspeed-hq]

CodSpeed Performance Report

Merging #1025 will improve performances by 7.07%

_{Comparing alilleybrinker:patch-1 (50da4a7) with master (17bc55d)}

Summary

⚡ 1 improvement
✅ 12 untouched

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	amortized[Input]	2.2 µs	2.1 µs	+7.07%

[MichaReiser]

Thank you. Would you mind adding a test so that we catch future regressions early

[alilleybrinker]

@MichaReiser sure, where would you want tests to be for this? Cursory review of the repo didn't show an obvious place with existing tests I should be augmenting. Want to make sure I'm as consistent with any existing practice as possible.

[alilleybrinker]

To maybe be clearer, I think the test here would be a compilation success test, validating that the relevant macros can compile even if someone redefines Result in the importing module. At the moment I only see compile-fail tests. I'm happy to add a compile-success folder and put this in it, but wanted to check first.

[alilleybrinker]

Added a new "compile pass" test, and from it found some more spots that needed their use of Result to be fully qualified. Let me know if you want any more edits.

[MichaReiser]

Thank you