On Windows the InnoSetup installer was superseded by the MSI installer. It's no longer needed.

This allows us to write

fn char_to_string() -> String {
    'a'.into()
}

which was not possible before.

Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.

Fixed grammar and sentence structure on appropriate instances.

…s recently merged

This commit updates rustc's LLVM submodule to include new AVR-specific
fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch.

All of these cherry-picked commits exist in upstream LLVM and were
cherry-picked into Rust's LLVM fork in commit 6c040dd86ed.

  |- 6c040dd86ed Merge pull request #66 from dylanmckay/avr-pick-upstream-llvm-fixes
    |- 12dfdd3aed7 [AVR] Rewrite the function calling convention.
    |- 118ac53f12b [AVR] Don't adjust for instruction size
    |- bc27c282e13 [AVR] Fix miscompilation of zext + add
    |- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior
    |- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer
    |- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup
    |- 93ee4da19cf [AVR]  Fix I/O instructions on XMEGA
    |- 962c2415ffb [AVR] Do not place functions in .progmem.data
    |- 65b8b170aef [AVR] Do not use divmod calls for bigger integers
    |- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal
    |- handlers too
    |- cc4286349b4 [AVR] Respect the 'interrupt' function attribute
    |- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget
    |- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch
    |- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr
    |- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values
    |- 6dfc55ba53b [AVR] Use correct register class for mul instructions

These changes include both correctness fixes and LLVM assertion error
fixes. Once all of these commits have been cherry-picked, all of the
LLVM plumbing for rust-lang/master to compile the AVR blink program will
be in place. Once this commit is merged, only PR #73270 will
be blocking successful compilation and emission of the AVR LED blink program.

I know very little about rust, so I saw this example and tried to generalize it by writing,
```
    let layout = Layout::new::<T>();
    let new_obj = unsafe {
        let ptr = alloc(layout) as *mut T;
        *ptr = obj;
        Box::from_raw(ptr)
    };
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I also added a comment that explains why `.write`
is used, but I think adding that comment is optional and may be too verbose
here. I do however think that changing this example is a good idea to
suggest the correct generalization. `.write` is also used in most of the rest
of the documentation here, even if the example is `i32`, so it would additionally
be more consistent.

Co-authored-by: Niko Matsakis <niko@alum.mit.edu>

Linked the logo/svg to https://www.rust-lang.org/
(change if required)

Added responsiveness to image logo based on device width (set at 90% of device width, which can be changed as per requirement)

update master

They are gated by internal feature gate const_likely

This commit applies the existing 'extra angle bracket recovery' logic
when parsing fields in struct definitions. This allows us to continue
parsing the struct's fields, avoiding spurious 'missing field' errors in
code that tries to use the struct.

Co-authored-by: Oliver Scherer <github35764891676564198441@oli-obk.de>

Fixes #67765

When reporting errors during MIR region inference, we sometimes use
`universal_upper_bound` to obtain a named universal region that we
can display to the user. However, this is not always possible - in a
case like `fn foo<'a, 'b>() { .. }`, the only upper bound for a region
containing `'a` and `'b` is `'static`. When displaying diagnostics, it's
usually better to display *some* named region (even if there are
multiple involved) rather than fall back to a generic error involving
`'static`.

This commit adds a new `approx_universal_upper_bound` method, which
uses the lowest-numbered universal region if the only alternative is to
return `'static`.

…xamples

Use back-ticks instead of quotation marks in docs for the block comment
variant of TokenKind.

Fix missing punctuation

Also adds back-ticks when referring to the contents of this collection.

…=Amanieu

stabilize leading_trailing_ones

This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in #57969 (comment) I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks!

cc/ @djc @rust-lang/libs

Add liballoc doc panic detail according to RawVec

This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.

This reverts commit 8bc3122.

added regions with counter expressions and counters.

Added codegen_llvm/coverageinfo mod for upcoming coverage map

Move coverage region collection to CodegenCx finalization

Moved from `query coverageinfo` (renamed from `query coverage_data`),
as discussed in the PR at:

#73684 (comment)

Address merge conflict in MIR instrument_coverage test

The MIR test output format changed for int types.

moved debug messages out of block.rs

This makes the block.rs calls to add coverage mapping data to the
CodegenCx much more concise and readable.

move coverage intrinsic handling into llvm impl

I realized that having half of the coverage intrinsic handling in
`rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any
non-llvm backend would be bound to the same decisions about how the
coverage-related MIR terminators should be handled.

To fix this, I moved the non-codegen portion of coverage intrinsic
handling into its own trait, and implemented it in `rustc_codegen_llvm`
alongside `codegen_intrinsic_call`.

I also added the (required?) stubs for the new intrinsics to
`IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do
not fail if called with these new but known intrinsics.

address PR Feedback on 28 June 2020 2:48pm PDT

…s, r=Mark-Simulacrum

rustbuild: Move compiler-builtins build logic to manifest

This commit moves the compiler-builtins-specific build logic from
`src/bootstrap/bin/rustc.rs` into the workspace `Cargo.toml`'s
`[profile]` configuration. Now that rust-lang/cargo#7253 is fixed we can
ensure that Cargo knows about debug assertions settings, and it can also
be configured to specifically disable debug assertions unconditionally
for compiler-builtins. This should improve rebuild logic when
debug-assertions settings change and also improve build-std integration
where Cargo externally now has an avenue to learn how to build
compiler-builtins as well.

Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.

However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.

This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.

Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.

The number of symbols we allocate (even early on) seems to be platform
dependent. We only care about hygiene for the purposes of this test,
so just set all of the symbol ids to zero

…s, r=cuviper

[AVR] Update the rust-lang/llvm-project submodule to include AVR fixes recently merged

This PR updates rustc's LLVM submodule to include new AVR-specific
fixes recently merged on the Rust LLVM 'rustc/10.0-2020-05-05' branch.

All of these cherry-picked commits exist in upstream LLVM and were
cherry-picked into Rust's LLVM fork in commit 6c040dd86ed.

Relates to rust-lang/llvm-project#66

```
  |- 6c040dd86ed Merge pull request #66 from dylanmckay/avr-pick-upstream-llvm-fixes
    |- 12dfdd3aed7 [AVR] Rewrite the function calling convention.
    |- 118ac53f12b [AVR] Don't adjust for instruction size
    |- bc27c282e13 [AVR] Fix miscompilation of zext + add
    |- cfbe205a7e8 [AVR] Remove faulty stack pushing behavior
    |- 143e1469e96 [AVR] Fix stack size in functions with a frame pointer
    |- 6b2445d841e [LLVM][AVR] Support for R_AVR_6 fixup
    |- 93ee4da19cf [AVR]  Fix I/O instructions on XMEGA
    |- 962c2415ffb [AVR] Do not place functions in .progmem.data
    |- 65b8b170aef [AVR] Do not use divmod calls for bigger integers
    |- 93a3b595d1c [AVR] Generalize the previous interrupt bugfix to signal
    |- handlers too
    |- cc4286349b4 [AVR] Respect the 'interrupt' function attribute
    |- 954d0a92205 [AVR] Fix reads of uninitialized variables from constructor of AVRSubtarget
    |- 1c0ddae73c9 [AVR] Fix read of uninitialized variable AVRSubtarget:::ELFArch
    |- 0ed0823fe60 [AVR] Fix incorrect register state for LDRdPtr
    |- 96075fc433d [AVR] Don't adjust addresses by 2 for absolute values
    |- 6dfc55ba53b [AVR] Use correct register class for mul instructions
```

These changes include both correctness fixes and LLVM assertion error
fixes. Once all of these commits have been cherry-picked, all of the
LLVM plumbing for rust-lang/master to compile the AVR blink program will
be in place. Once this commit is merged, only PR #73270 will
be blocking successful compilation and emission of the AVR LED blink program.

Emscripten's SDK recently bumped the version of NodeJS they shipped, but
our Dockerfile for the wasm32 builder hardcoded the version number. This
will cause consistent CI failures once the currently cached image is
rebuilt (either due to a change or due to the cache expiring).

This commit fixes the problem by finding the latest version of NodeJS in
the Emscripten SDK and symlinking it to a "latest" directory, which is
then added to the PATH.

update Miri

Fixes #73773
Cc @rust-lang/miri r? @ghost

bootstrap: Configurable musl libdir

Make it possible to customize the location of musl libdir using
musl-libdir in config.toml, e.g., to use lib64 instead of lib.

And final part!!!

Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
    - Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Removed unnecessary casts back and forth between u8 and u32
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.

There were a few instances of this pattern:

```rust
while index < vec.len() {
    let item = &vec[index];
    // ...
}
```

These can be indexed at once:

```rust
while let Some(item) = vec.get(index) {
    // ...
}
```

Particularly in `ObligationForest::process_obligations`, this mitigates
a codegen regression found with LLVM 11 (#73526).

…chenkov

Serialize all foreign `SourceFile`s into proc-macro crate metadata

Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.

However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.

This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.

Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.

Does not yet make its constness stable, though. Use of
`Location::caller` in const contexts is still gated by
`#![feature(const_caller_location)]`.

…erive macros

…crum

Revert "ci: allow gating gha on everything but macOS"

The macOS issue on GHA's side seems to be fixed, so this is not needed anymore.

r? @Mark-Simulacrum

We do not test cross-compilation here as the PR builder lacks a sufficiently
recent LLVM to cross-compile to 32-bit linux. Once we bump the minimum LLVM
version to LLVM 9, this can use normal 32-bit linux.

Added detailed error code explanation for issue E0687 in Rust compiler.

Added proper error explanation for issue E0687 in the Rust compiler.
Error Code E0687

Sub Part of Issue #61137

r? @GuillaumeGomez

Bring net/parser.rs up to modern up to date with modern rust patterns

The current implementation of IP address parsing is very unidiomatic; it's full of `if` / `return` / `is_some` / `is_none` instead of `?`, `loop` with manual index tracking; etc. Went through and did and cleanup to try to bring it in line with modern sensibilities.

The obvious concern with making changes like this is "make sure you understand why it's written that way before changing it". Looking through the commit history for this file, there are several much smaller commits that make similar changes (For instance, 3024c14, 4f3ab49, 79f8764), and there don't seem to be any commits in the history that indicate that this lack of idiomaticity is related to specific performance needs (ie, there aren't any commits that replace a `for` loop with a `loop` and a manual index count). In fact, the basic shape of the file is essentially unchanged from its initial commit back in 2015.

Made the following changes throughout the IP address parser:
- Replaced all uses of `is_some()` / `is_none()` with `?`.
- "Upgraded" loops wherever possible; ie, replace `while` with `for`, etc.
    - Removed all cases of manual index tracking / incrementing.
- Renamed several single-character variables with more expressive names.
- Replaced several manual control flow segments with equivalent adapters (such as `Option::filter`).
- Removed `read_seq_3`; replaced with simple sequences of `?`.
- Parser now reslices its state when consuming, rather than carrying a separate state and index variable.
- `read_digit` now uses `char::to_digit`.
- Added comments throughout, especially in the complex IPv6 parsing logic.
- Added comprehensive local unit tests for the parser to validate these changes.

Stabilize `#[track_caller]`.

# Stabilization Report

RFC: [2091]
Tracking issue: #47809

## Summary

From the [rustc-dev-guide chapter][dev-guide]:

> Take this example program:

```rust
fn main() {
    let foo: Option<()> = None;
    foo.unwrap(); // this should produce a useful panic message!
}
```

> Prior to Rust 1.42, panics like this `unwrap()` printed a location in libcore:

```
$ rustc +1.41.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value',...core\macros\mod.rs:15:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
```

> As of 1.42, we get a much more helpful message:

```
$ rustc +1.42.0 example.rs; example.exe
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

> These error messages are achieved through a combination of changes to `panic!` internals to make use of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard library which propagate caller information.

The attribute adds an implicit caller location argument to the ABI of annotated functions, but does not affect the type or MIR of the function. We implement the feature entirely in codegen and in the const evaluator.

## Bottom Line

This PR stabilizes the use of `#[track_caller]` everywhere, including traits and extern blocks. It also stabilizes `core::panic::Location::caller`, although the use of that function in a const context remains gated by `#![feature(const_caller_location)]`.

The implementation for the feature already changed the output of panic messages for a number of std functions, as described in the [1.42 release announcement]. The attribute's use in `Index` and `IndexMut` traits is visible to users since 1.44.

## Tests

All of the tests for this feature live under [src/test/ui/rfc-2091-track-caller][tests] in the repo.

Noteworthy cases:

* [use of attr in std]
  * validates user-facing benefit of the feature
* [trait attribute inheritance]
  * covers subtle behavior designed during implementation and not RFC'd
* [const/codegen equivalence]
  * this was the result of a suspected edge case and investigation
* [diverging function support]
  * covers an unresolved question from the RFC
* [fn pointers and shims]
  * covers important potential sources of unsoundness

## Documentation

The rustc-dev-guide now has a chapter on [Implicit Caller Location][dev-guide].

I have an [open PR to the reference][attr-reference-pr] documenting the attribute.

The intrinsic's [wrapper] includes some examples as well.

## Implementation History

* 2019-10-02: [`#[track_caller]` feature gate (RFC 2091 1/N) #65037](#65037)
  * Picked up the patch that @ayosec had started on the feature gate.
* 2019-10-13: [Add `Instance::resolve_for_fn_ptr` (RFC 2091 #2/N) #65182](#65182)
* 2019-10-20: ~~[WIP Add MIR argument for #[track_caller] (RFC 2091 3/N) #65258](#65258
  * Abandoned approach to send location as a MIR argument.
* 2019-10-28: [`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N) #65664](#65664)
* 2019-12-07: [Implement #[track_caller] attribute. (RFC 2091 4/N) #65881](#65881)
* 2020-01-04: [libstd uses `core::panic::Location` where possible. #67137](#67137)
* 2020-01-08: [`Option::{expect,unwrap}` and `Result::{expect, expect_err, unwrap, unwrap_err}` have `#[track_caller]` #67887](#67887)
* 2020-01-20: [Fix #[track_caller] and function pointers #68302](#68302) (fixed #68178)
* 2020-03-23: [#[track_caller] in traits #69251](#69251)
* 2020-03-24: [#[track_caller] on core::ops::{Index, IndexMut}. #70234](#70234)
* 2020-04-08 [Support `#[track_caller]` on functions in `extern "Rust" { ... }` #70916](#70916)

## Unresolveds

### From the RFC

> Currently the RFC simply prohibit applying #[track_caller] to trait methods as a future-proofing
> measure.

**Resolved.** See the dev-guide documentation and the tests section above.

> Diverging functions should be supported.

**Resolved.** See the tests section above.

> The closure foo::{{closure}} should inherit most attributes applied to the function foo, ...

**Resolved.** This unknown was related to specifics of the implementation which were made irrelevant by the final implementation.

### Binary Size

I [instrumented track_caller to use custom sections][measure-size] in a local build and discovered relatively minor binary size usage for the feature overall. I'm leaving the issue open to discuss whether we want to upstream custom section support.

There's an [open issue to discuss mitigation strategies][mitigate-size]. Some decisions remain about the "right" strategies to reduce size without overly constraining the compiler implementation. I'd be excited to see someone carry that work forward but my opinion is that we shouldn't block stabilization on implementing compiler flags for redaction.

### Specialization

There's an [open issue][specialization] on the semantics of the attribute in specialization chains. I'm inclined to move forward with stabilization without an exact resolution here given that specialization is itself unstable, but I also think it should be an easy question to resolve.

### Location only points to the start of a call span

#69977 was resolved by #73182, and the next step should probably be to [extend `Location` with a notion of the end of a call](#73554).

### Regression of std's panic messages

#70963 should be resolved by serializing span hygeine to crate metadata: #68686.

[2091]: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
[dev-guide]: https://rustc-dev-guide.rust-lang.org/codegen/implicit-caller-location.html
[specialization]: #70293
[measure-size]: #70579
[mitigate-size]: #70580
[attr-reference-pr]: rust-lang/reference#742
[wrapper]: https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.caller
[tests]: https://github.com/rust-lang/rust/tree/master/src/test/ui/rfc-2091-track-caller
[const/codegen equivalence]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/caller-location-fnptr-rt-ctfe-equiv.rs
[diverging function support]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/diverging-caller-location.rs
[use of attr in std]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/std-panic-locations.rs
[fn pointers and shims]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-fn-ptr-with-arg.rs
[trait attribute inheritance]: https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2091-track-caller/tracked-trait-impls.rs
[1.42 release announcement]: https://blog.rust-lang.org/2020/03/12/Rust-1.42.html#useful-line-numbers-in-option-and-result-panic-messages

impl From<char> for String

This allows us to write

````rust
fn char_to_string() -> String {
    'a'.into()
}
````

which was not possible before.

remove rustdoc warnings

Fix sentence structure

Fixed grammar and sentence structure on appropriate instances.

Update Box::from_raw example to generalize better

I know very little about rust, so I saw the example here
```
use std::alloc::{alloc, Layout};

unsafe {
    let ptr = alloc(Layout::new::<i32>()) as *mut i32;
    *ptr = 5;
    let x = Box::from_raw(ptr);
}
```
and tried to generalize it by writing,
```
    let layout = Layout::new::<T>();
    let new_obj = unsafe {
        let ptr = alloc(layout) as *mut T;
        *ptr = obj;
        Box::from_raw(ptr)
    };
```
for some more complicated `T`, which ended up crashing with SIGSEGV,
because it tried to `drop_in_place` the previous object in `ptr` which is
of course garbage. I think that changing this example to use `.write` instead
would be a good idea to suggest the correct generalization. It is also more
consistent with other documentation items in this file, which use `.write`.
I also added a comment to explain it, but I'm not too attached to that,
and can see it being too verbose in this place.

stop taking references in Relate

Adds a `Copy` bound to `Relate` and changes the type signatures to `T` from `&T`. While the `Copy` bound is not strictly necessary (i.e. the `Clone` bound of `TypeRelation` would be good enough), we don't need non `Copy` types and it simplifies the implementation.

Removes the afaict unused impls for `Vec<ty::PolyExistentialProjection<'tcx>>`, `Rc<T>` and `Box<T>`. If they end up being relevant again the bound of `Relate` can be reduced to `T: Clone`.

This also changes signature of `Binder::skip_binder` to `fn skip_binder(self) -> T`.

`TypeError::ProjectionBoundsLength` was never used and is also removed in this PR.

r? @nikomatsakis maybe 🤔 feel free to reassign

Document the static keyword

Partial fix of #34601.

This documents the `static` keyword. It's basically a simplified version of the reference with more examples.

@rustbot modify labels: T-doc,C-enhancement

…ertodt

Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other

I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other.

I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.