Suggest Default::default() when binding isn't initialized

[chenyukang]

Fixes#102087

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[chenyukang]

My first try on the type-checking part, there are several parts I'm not sure.

[nagisa]

Hm, seems quite unfortunate that we only handle the bindings that have a specified type. As such code like this isn’t really covered:

fnapple(_:u32){}fnbanana(){let chaenomeles;apple(chaenomeles);}

Not saying though that this needs to be implemented here and now, but perhaps a FIXME comment or an issue for this would be warranted.

[chenyukang]

Fixed the code to support this scenario now, the type infer know it's a u32, so here we give this suggestion:

error[E0381]: used binding `chaenomeles` isn't initialized
--> bug.rs:5:11
|
4 | let chaenomeles;
| ----------- binding declared here but left uninitialized
5 | apple(chaenomeles);
| ^^^^^^^^^^^ `chaenomeles` used here but it isn't initialized
|
help: consider assigning a value
|
4 | let chaenomeles = 0;
| +++

[nagisa]

This is quite awesome!

@bors r+

[bors]

📌 Commit 21b9222 has been approved by nagisa

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- failed in a rollup (test needs update)
https://github.com/rust-lang-ci/rust/actions/runs/3120399661/jobs/5060949966#step:25:24352
#102247

[chenyukang]

@bors r- failed in a rollup (test needs update) https://github.com/rust-lang-ci/rust/actions/runs/3120399661/jobs/5060949966#step:25:24352#102247

updated it!
How can we avoid this happend for those testcase which depended on some specific arch?
I just manually removed the only-aarch64 and generated the stderr.

[nagisa]

How can we avoid this happend for those testcase which depended on some specific arch? I just manually removed the only-aarch64 and generated the stderr.

Unfortunately that’s the downside of only running the tests on the specified architecture. The more appropriate thing to do is to write the test in a way that is able to cross-compile if necessary to test target-specific details, but this isn’t always feasible (e.g. when test depends on libstd.)

The most straightfoward thing to do today is to just let bors deal with it, to be honest.

@bors r+ rollup=never

[bors]

📌 Commit 8b2a008fd2edfd01c8f9ede3d5131dbea5d0d725 has been approved by nagisa

It is now in the queue for this repository.

[nagisa]

@bors r-

Could you squash the commits a little please? Commits like “cleanup” or “update test” don’t really carry themselves.

[chenyukang]

@bors r-

Could you squash the commits a little please? Commits like “cleanup” or “update test” don’t really carry themselves.

squashed!

[nagisa]

@bors r+

[bors]

📌 Commit 672e3f4 has been approved by nagisa

It is now in the queue for this repository.

[bors]

⌛ Testing commit 672e3f4 with merge 84946fe...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing 84946fe to master...

[rust-timer]

Finished benchmarking commit (84946fe): 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

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.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-4.0%, -4.0%]	1
All ❌✅ (primary)	-	-	0

Cycles

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

Footnotes

1. the arithmetic mean of the percent change↩

2. number of relevant changes↩