debuginfo: Make sure that all calls to drop glue are associated with debug locations.

This commit makes rustc emit debug locations for all call
and invoke statements in LLVM IR, if they are contained
within a function that debuginfo is enabled for. This is
important because LLVM does not handle the case where a
function body containing debuginfo is inlined into another
function with debuginfo, but the inlined call statement
does not have a debug location. In this case, LLVM will
not know where (in terms of source code coordinates) the
function was inlined to and we end up with some statements
still linked to the source locations in there original,
non-inlined function without any indication that they are
indeed an inline-copy. Later, when generating DWARF from
the IR, LLVM will interpret this as corrupt IR and abort.

Unfortunately, the undesirable case described above can
still occur when using LTO. If there is a crate compiled
without debuginfo calling into a crate compiled with
debuginfo, we again end up with the conditions triggering
the error. This is why some LTO tests still fail with the
dreaded assertion, if the standard library was built with
debuginfo enabled.
That is, `RUSTFLAGS_STAGE2=-g make rustc-stage2` will
succeed but `RUSTFLAGS_STAGE2=-g make check` will still
fail after this commit has been merged. This is a problem
that has to be dealt with separately.

Fixes #17201
Fixes #15816
Fixes #15156
Mention array sugar in guide
Cleanup error messages for anonymous impl for types not declared in the current module

Followup to RFC 57.

Fixes #7607
Fixes #8767
Fixes #12729
Fixes #15060
auto merge of #17533 : michaelwoerister/rust/function-call-locs, r=luqmana

This PR makes rustc emit debug locations for *all* call and invoke statements in LLVM IR, if they are contained within a function that debuginfo is enabled for. This is important because LLVM does not handle the case where a function body containing debuginfo is inlined into another function with debuginfo, but the inlined call statement does not have a debug location. In this case, LLVM will not know where (in terms of source code coordinates) the function was inlined to and we end up with some statements still linked to the source locations in there original, non-inlined function without any indication that they are indeed an inline-copy. Later, when generating DWARF from the IR, LLVM will interpret this as corrupt IR and abort.

Unfortunately, the undesirable case described above can still occur when using LTO. If there is a crate compiled without debuginfo calling into a crate compiled with debuginfo, we again end up with the conditions triggering the error. This is why some LTO tests still fail with the dreaded assertion, if the standard library was built with debuginfo enabled. That is, `RUSTFLAGS_STAGE2=-g make rustc-stage2` will succeed but `RUSTFLAGS_STAGE2=-g make check` will still fail after this PR has been merged. I will open a separate issue for this problem.
auto merge of #17321 : apoelstra/rust/error-on-unknown-impl, r=alexcrichton

Followup to RFC 57.

Fixes #7607
Fixes #8767
Fixes #12729
Fixes #15060
auto merge of #17535 : Manishearth/rust/patch-2, r=steveklabnik

It's a rather useful syntax, and non-obvious.

A friend of mine is learning Rust and was trying to find a way to easily do such an initialization — he couldn't find it in the guide and was pretty surprised when I showed him. Looks like something that should be mentioned.

r? @steveklabnik
Fixed quote_method!() implementation

Parser.parse_method now has a second argument, I assume ast::Inherited is the correct visibility in this case.
auto merge of #17409 : farcaller/rust/patch-1, r=huonw

Parser.parse_method now has a second argument, I assume ast::Inherited is the correct visibility in this case.
rustc: Fix permission denied error in 'ar' when lto is enabled

The reason that 'ar' can fail with permission denied is that when
link-time optimizations are enabled, rustc copies libraries into a
temporary directory, preserving file permissions, and subsequently
modifies them using 'ar'.

The modification can fail because some package managers may install
libraries in system directories as read-only files, which means the
temporary file also becomes read-only when it is copied.

I have fixed this by giving the temporary file's owner read+write
permissions after the copy.

I have also added a regression test for this issue.