Change to link to "Contributing to Rust" chapter of `rustc` Dev Guide, primarily on the basis that the GitHub "first contribution" Issue "pop-up" says "Be sure to review the [contributing guidelines] and [code of conduct]" and links to this file.

When/if the guide/"Getting Started" section gets revised to not be `rustc`-specific the linked section can be changed.

In the meantime this prevents leading first time contributors into a confusing cul de sac.

Signed-off-by: wcampbell <wcampbell1995@gmail.com>

Signed-off-by: wcampbell <wcampbell1995@gmail.com>

Today, given a static like `static mut FOO: usize = 1`, rustdoc would
emit `static mut  FOO: usize = 1`, as it emits both the mutability kw
with a space and reserves a space after the mutability kw. This patch
fixes that misformatting.

This patch also adds some tests for emit of other statics, as I could
not find an existing test devoted to statics.

…tics

…versions

…d O notations to be italicized

… them opaque

This deconfuses the comparison of floats, that currently mixed ranges
and non-ranges.

This makes it consistent with std::panic!("message"), which also throws
a &str, not a String.

It now throws a &str instead of a String.

Writing any fmt::Arguments would trigger the inclusion of usize
formatting and padding code in the resulting binary, because indexing
used in fmt::write would generate code using panic_bounds_check, which
prints the index and length.

These bounds checks are not necessary, as fmt::Arguments never contains
any out-of-bounds indexes.

This change replaces them with unsafe get_unchecked, to reduce the
amount of generated code, which is especially important for embedded
targets.

Since having enabled the download-ci-llvm option,
and having rebased on top of f05b47c,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.

This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.

An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.

It checks that fmt::write by itself doesn't pull in any panicking or
or display code.

Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.

To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.

This issue was accidentally fixed recently, probably by rust-lang#70743

…oli-obk

[mir-opt] Allow debuginfo to be generated for a constant or a Place

Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.

To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.

Link to "Contributing to Rust" rather than "Getting Started".

Change to link to "Contributing to Rust" chapter of `rustc` Dev Guide, primarily on the basis that:

 * The GitHub "first contribution" Issue "pop-up" says "Be sure to review the [contributing guidelines] and [code of conduct]" and links to this file.

 * The "Bug Report" section _seems_ to restrict itself to if "a compiler error message [told] you to come here".

 * The previous content of `CONTRIBUTING.md` now lives in the "Contributing to Rust" chapter.

When/if the guide/"Getting Started" section gets revised to not be `rustc`-specific, the choice of linked chapter could be updated.

In the meantime this prevents leading first time contributors into a confusing cul de sac.

_[I wasn't planning to make a PR for this until discussion in rust-lang#77215 concluded but the discovery that the "first issue" pop-up also links to this document IMO makes it a higher priority to make the link useful sooner rather than later.]_

Related issues:

 * rust-lang#77215

 * rust-lang/rustc-dev-guide#775 (comment)

… r=jonas-schievink

Mark `repr128` as `incomplete_features`

As mentioned in rust-lang#56071 and noticed in rust-lang#77457, `repr(u128)` and `repr(i128)` do not work properly due to lack of LLVM support. We should thus warn users trying to use the feature that they may encounter ICEs when using it.

Closes rust-lang#77457.

…, r=m-ou-se

Cleanup network tests

Some cleanup for network related tests

…n514

Avoid extraneous space between visibility kw and ident for statics

Today, given a static like `static mut FOO: usize = 1`, rustdoc would
emit `static mut  FOO: usize = 1`, as it emits both the mutability kw
with a space and reserves a space after the mutability kw. This patch
fixes that misformatting.

This patch also adds some tests for emit of other statics, as I could
not find an existing test devoted to statics.

…tency, r=m-ou-se

Doc formating consistency between slice sort and sort_unstable, and big O notation consistency

Updated documentation for slice sorting methods to be consistent between stable and unstable versions, which just ended up being minor formatting differences.

I also went through and updated any doc comments with big O notation to be consistent with rust-lang#74010 by italicizing them rather than having them in a code block.

…-panic-str, r=RalfJung

Fix const core::panic!(non_literal_str).

Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.

This fixes the issue mentioned here: rust-lang#51999 (comment)

r? @RalfJung

@rustbot modify labels: +A-const-eval

…, r=varkor

Cleanup constant matching in exhaustiveness checking

This supercedes rust-lang#77390. I made the `Opaque` constructor work.
I have opened two issues rust-lang#78071 and rust-lang#78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.

I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.

EDIT: I accidentally fixed rust-lang#78071

…t, r=petrochenkov

Make inline const work in range patterns

Fixes rust-lang#78108 which is a follow up of rust-lang#77124

r? @petrochenkov

…as-str, r=Amanieu

Throw core::panic!("message") as &str instead of String.

This makes `core::panic!("message")` consistent with `std::panic!("message")`, which throws a `&str` and not a `String`.

This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String`, which includes compiler-generated panics such as the panics generated for `mem::zeroed()`.

---

Demonstration:

```rust
use std::panic;
use std::any::Any;

fn main() {
    panic::set_hook(Box::new(|panic_info| check(panic_info.payload())));

    check(&*panic::catch_unwind(|| core::panic!("core")).unwrap_err());
    check(&*panic::catch_unwind(|| std::panic!("std")).unwrap_err());
}

fn check(msg: &(dyn Any + Send)) {
    if let Some(s) = msg.downcast_ref::<String>() {
        println!("Got a String: {:?}", s);
    } else if let Some(s) = msg.downcast_ref::<&str>() {
        println!("Got a &str: {:?}", s);
    }
}
```

Before:
```
Got a String: "core"
Got a String: "core"
Got a &str: "std"
Got a &str: "std"
```

After:
```
Got a &str: "core"
Got a &str: "core"
Got a &str: "std"
Got a &str: "std"
```

…bounds-check, r=dtolnay

Avoid panic_bounds_check in fmt::write.

Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary, because indexing used in fmt::write would generate code using panic_bounds_check, which prints the index and length.

These bounds checks are not necessary, as fmt::Arguments never contains any out-of-bounds indexes.

This change replaces them with unsafe get_unchecked, to reduce the amount of generated code, which is especially important for embedded targets.

---

Demonstration of the size of and the symbols in a 'hello world' no_std binary:

<details>
<summary>Source code</summary>

```rust
#![feature(lang_items)]
#![feature(start)]
#![no_std]

use core::fmt;
use core::fmt::Write;

#[link(name = "c")]
extern "C" {
    #[allow(improper_ctypes)]
    fn write(fd: i32, s: &str) -> isize;
    fn exit(code: i32) -> !;
}

struct Stdout;

impl fmt::Write for Stdout {
    fn write_str(&mut self, s: &str) -> fmt::Result {
        unsafe { write(1, s) };
        Ok(())
    }
}

#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
    let _ = writeln!(Stdout, "Hello World");
    0
}

#[lang = "eh_personality"]
fn eh_personality() {}

#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
    unsafe { exit(1) };
}
```
</details>

Before:
```
   text	   data	    bss	    dec	    hex	filename
   6059	    736	      8	   6803	   1a93	before
```
```
0000000000001e00 T <T as core::any::Any>::type_id
0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT
0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for u64>::fmt
0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for usize>::fmt
0000000000001370 T core::fmt::write
0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix
0000000000001660 T core::fmt::Formatter::pad_integral
0000000000001350 T core::ops::function::FnOnce::call_once
0000000000001b80 t core::ptr::drop_in_place
0000000000001120 t core::ptr::drop_in_place
0000000000001c50 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001c90 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001b90 T core::panicking::panic_bounds_check
0000000000001c10 T core::panicking::panic_fmt
0000000000001130 t <&mut W as core::fmt::Write>::write_char
0000000000001200 t <&mut W as core::fmt::Write>::write_fmt
0000000000001250 t <&mut W as core::fmt::Write>::write_str
```

After:
```
   text	   data	    bss	    dec	    hex	filename
   3068	    600	      8	   3676	    e5c	after
```
```
0000000000001360 T core::fmt::write
0000000000001340 T core::ops::function::FnOnce::call_once
0000000000001120 t core::ptr::drop_in_place
0000000000001620 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001660 t core::iter::adapters::zip::Zip<A,B>::new
0000000000001130 t <&mut W as core::fmt::Write>::write_char
0000000000001200 t <&mut W as core::fmt::Write>::write_fmt
0000000000001250 t <&mut W as core::fmt::Write>::write_str
```

…=Mark-Simulacrum

Sync LLVM submodule if it has been initialized

Since having enabled the download-ci-llvm option,
and having rebased on top of rust-lang#76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.

This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.

An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.