Fix for #31267 and additional zero-width constant bug

[sdleffler]

Fixes #31267 - with this change, the code mentioned in the issue compiles.

Found and fixed another issue as well - constants of zero-size types, when used in ExprRepeats inside associated constants, were causing the compiler to crash at the same place as #31267. An example of this:

#![feature(associated_consts)]

#[derive(Clone, Copy, Debug)]
struct Bar;

const BAZ: Bar = Bar;

#[derive(Debug)]
struct Foo([Bar; 1]);

struct Biz;

impl Biz {
    const BAZ: Foo = Foo([BAZ; 1]);
}

fn main() {
    let foo = Biz::BAZ;
    println!("{:?}", foo);
}

However, I'm fairly certain that my fix for this is not as elegant as it could be. The problem seems to occur only with an associated constant of a tuple struct containing a fixed size array which is initialized using a repeat expression, and when the element to be repeated provided to the repeat expression is another constant which is of a zero-sized type. The fix works by looking for constants and associated constants which are zero-width and consequently contain no data, but for which rustc is still attempting to emit an LLVM value; it simply stops rustc from attempting to emit anything. By my logic, this should work fine since the only values that are emitted in this case (according to the comments) are for closures with side effects, and constants will never have side effects, so it's fine to simply get rid of them. It fixes the error and things compile fine with it, but I have a sneaking suspicion that it could be done in a far better manner.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nagisa]

See this for liblibc thing.

[sdleffler]

@nagisa Thanks! A variation on that did the trick.

[tamird]

Consider adding an rpass test containing the code from #31267 and squashing this down to one commit.

[sdleffler]

Well, I think I really bunged this one up, I'm going to close this PR and try again. Still adjusting to git.

[tamird]

There's no need to make a new PR; you can fix the commit history with git rebase -i master and "squash" all the commits.

[sdleffler]

@tamird I tried that and it resulted in the mess you can see above :P I'm going to start over with a clean slate. Things started to get really messed up on local and my fork. I'm sure it would have been possible to fix, but it was quicker to just make a new fork at this point.