Auto merge of #32496 - Manishearth:rollup, r=Manishearth

Rollup of 11 pull requests

- Successful merges: #32131, #32199, #32257, #32325, #32435, #32447, #32448, #32456, #32469, #32476, #32482
- Failed merges: #32240

Fixup #32476

Rollup merge of #32482 - nikomatsakis:erase-via-visitor, r=nagisa

use new visitor to erase regions

r? @nagisa

Rollup merge of #32476 - diwic:63-null-thread-name, r=alexcrichton

Fix unsound behaviour with null characters in thread names (issue #32475)

Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.

This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.

This could potentially be a breaking change for architectures who don't
support thread names.

Rollup merge of #32469 - nikomatsakis:shared-cgu, r=eddyb

make available monomorphizations shared by CGU

The current setup means that all generics are local to a codegen-unit,
which means massive duplication.

Rollup merge of #32456 - bluss:str-zero, r=alexcrichton

Hardcode accepting 0 as a valid str char boundary

If we check explicitly for index == 0, that removes the need to read the
byte at index 0, so it avoids a trip to the string's memory, and it
optimizes out the slicing index' bounds check whenever it is (a constant) zero.

Rollup merge of #32448 - sfackler:time-augmented-assignment, r=alexcrichton

Add augmented assignment operator impls for time types

r? @alexcrichton

Rollup merge of #32447 - nodakai:dots-in-err-idx, r=Manishearth

Remove ungrammatical dots from the error index.

They were probably meant as a shorthand for omitted code.

Part of #32446 but there should be a separate fix for the issue.

Rollup merge of #32435 - nrc:fix-err-recover, r=nikomatsakis

Some fixes for error recovery in the compiler

Rollup merge of #32257 - alexcrichton:fix-status-stdin, r=aturon

std: Fix inheriting stdin on status()

This regression was accidentally introduced in #31618, and it's just flipping a
boolean!

Closes #32254

Rollup merge of #32199 - nikomatsakis:limiting-constants-in-patterns-2, r=pnkfelix

Restrict constants in patterns

This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects:

1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`.
2. Structs and enums must derive `Eq` to be usable within a match.

This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement
`Eq`. Something like the following:

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*):

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`):

```rust
match foo {
    c if c == SOME_CONST => ...
}
```

Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC #1445 for more details.

cc https://github.com/rust-lang/rust/issues/31434

r? @pnkfelix

Rollup merge of #32131 - petrochenkov:prim, r=eddyb

resolve: Minimize hacks in name resolution of primitive types

When resolving the first unqualified segment in a path with `n` segments and `n - 1` associated item segments, e.g. (`a` or `a::assoc` or `a::assoc::assoc` etc) try to resolve `a` without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve `a` as a primitive type as a fallback.

This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names.

Furthermore, if names of primitive types are [put into prelude](https://github.com/petrochenkov/rust/tree/prim2) (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like `use prelude::v1::*; use usize;` in libcore/libstd, I'd better wait for proper glob shadowing before doing it.
I wish the `no_prelude` attribute were unstable as intended :(

cc @jseyfried @arielb1
r? @eddyb

Auto merge of #32293 - nikomatsakis:incr-comp-def-path-munging, r=alexcrichton

Revamp symbol names for impls (and make them deterministic, etc)

This builds on @michaelwoerister's epic PR #31539 (note that his PR never landed, so I just incorporated it into this one). The main change here is that we remove the "name" from `DefPathData` for impls, since that name is synthetic and not sufficiently predictable for incr comp. However, just doing that would cause bad symbol names since those are based on the `DefPath`. Therefore, I introduce a new mechanism for getting symbol names (and also paths for user display) called `item_path`. This is kind of simplistic for now (based on strings) but I expect to expand it later to support richer types, hopefully generating C++-mangled names that gdb etc can understand. Along the way I cleaned up how we track the path that leads to an extern crate.

There is still some cleanup left undone here. Notably, I didn't remove the impl names altogether -- that would probably make sense. I also didn't try to remove the `item_symbols` vector. Mostly I want to unblock my other incr. comp. work. =)

r? @eddyb
cc @eddyb @alexcrichton @michaelwoerister

remove link-guard test

Auto merge of #32167 - jseyfried:refactor_prelude, r=nikomatsakis

resolve: Refactor how the prelude is handled

This PR refactors how the prelude is handled in `resolve`.

Instead of importing names from the prelude into each module's `resolutions`, this PR adds a new field `prelude: RefCell<Option<Module>>` to `ModuleS` that is set during import resolution but used only when resolving in a lexical scope (i.e. the scope of an initial segment of a relative path).

r? @nikomatsakis

Add and use `resolve_name_in_lexical_scope` and
exclude the prelude from `resolve_name(.., allow_private_imports = true)`.

Refactor away `NameResolution::result`

Refactor away DefModifiers::PRELUDE

Refactor how the prelude is handled

Refactor away resolve_imports::Shadowable and rename shadowable -> is_prelude

change test to be specific for msvc

fix error message

fix cargo.toml for new dependency

Rebase over my PR

Update backtrace test for FIXME on windows

Drive-by fix for unnecessary `&mut`

document test, don't use grep

test for immediate symbol name hashing

include the immediate type in the symbol name hash

the intention is to give some simple protection like link-guards
but not impede ability to upgrade dylib in place

Revert "workarounds to make link guards work on windows"

This reverts commit b52004d202ddfffa100d4963216e1673a0be0b95.

rip out link guards

As discussed in
https://github.com/rust-lang/rust/pull/32293#issuecomment-200597130,
adding link guards are a heuristic that is causing undue complications:

- the link guards inject extra public symbols, which is not always OK.
- link guards as implemented could be a non-trivial performance hit,
  because no attempt is made to "de-duplicate" the dependency graph,
  so at worst you have O(N!) calls to the link guard functions.

Nonetheless, link guards are very helpful in detecting errors, so it may
be worth adding them back in some modified form in the future.

workarounds to make link guards work on windows

Link guards cause problems in some specific scenarios on windows because
they force libcore to be instantiated, since we do not GC functions
effectively on windows.

The changes here are two:

1. disable core for rsbegin/rsend
2. make panic_fmt an extern fn for smallest-hello-world so that it
   is not marked as "internal" for LLVM

renumber error from E0522 to E0523

another name was added in the meantime

check only that symbol names are deterministic

Full binary reproducible builds are not possible on all platforms
because linker injects a certain amount of randomness, apparently. Or,
at minimum, they don't work reliably yet.

Remove static linking hack since we are now passing absolute paths

Fix accursed issue-4264.pp

Correections due to refactoring .

pacify the merciless tidy: s/E0521/E0522

Gah. I always find it confusing that make tidy gives me the highest error
code, but not the **next** error code.

renumber diagnostic to avoid conflict

specialization nabbed E0520

remove unused variable in compiletest

unit-test symbol-names and item-paths

refactor item-paths in diagnostics, symbol names

This change has a few parts. We introduce a new `item_path` module for
constructing item paths. The job of this module is basically to make
nice, user-readable paths -- but these paths are not necessarily 100%
unique. They meant to help a *human* find code, but not necessarily a
compute. These paths are used to drive `item_path_str` but also symbol
names.

Because the paths are not unique, we also modify the symbol name hash to
include the full `DefPath`, whereas before it included only those
aspects of the def-path that were not included in the "informative"
symbol name.

Eventually, I'd like to make the item-path infrastructure a bit more
declarative.  Right now it's based purely on strings. In particular, for
impls, we should supply the raw types to the `ItemPathBuffer`, so that
symbol names can be encoded using the C++ encoding scheme for better
integration with tooling.

add krate_attrs accessor

makes better edges in dep graph

track the extern-crate def-id rather than path

We used to track, for each crate, a path that led to the extern-crate
that imported it. Instead of that, track the def-id of the extern crate,
along with a bit more information, and derive the path on the fly.

fallout: update codegen-units tests

refactor DefPathData variants

In particular, remove the name from the Impl, since that name is
synthesized and is not predictable (it tends to break incr. comp.).

Also rename the variants to be a bit more uniform and remove some
distinctions that we were not really taking advantage of anywhere.

store krate information more uniformly

make DefPath store krate and enable uniform access to crate_name/crate_disambiguator

track def-id for inlined items

Add a "link-guard" to avoid accidentally linking to a wrong dylib at runtime.

We want to prevent compiling something against one version
of a dynamic library and then, at runtime accidentally
using a different version of the dynamic library. With the
old symbol-naming scheme this could not happen because every
symbol had the SVH in it and you'd get an error by the
dynamic linker when using the wrong version of a dylib. With
the new naming scheme this isn't the case any more, so this
patch adds the "link-guard" to prevent this error case.

This is implemented as follows:

- In every crate that we compile, we emit a function called
  "__rustc_link_guard_<crate-name>_<crate-svh>"
- The body of this function contains calls to the
  "__rustc_link_guard" functions of all dependencies.
- An executable contains a call to it's own
  "__rustc_link_guard" function.

As a consequence the "__rustc_link_guard" function call graph
mirrors the crate graph and the dynamic linker will fail if a
wrong dylib is loaded somewhere because its
"__rustc_link_guard" function will contain a different SVH in
its name.

Remove old symbol naming code.

Make the compiler emit an error if the crate graph contains two crates with the same crate-name and crate-salt but different SVHs.

Salt test crates in buildsystem.

Add a test to verify that we have reproducible compiler builds.

Use new symbol names for items of various kinds.

Use new symbol naming scheme for object shims.

Use new symbol naming scheme for fn-once-shims.

Use new symbol naming scheme for fn-pointer-shims.

Make drop glue use new symbol naming scheme.

Make closures use stable symbol names.

Make monomorphized functions use stable symbol names.

Make the definite name of the local crate available in the tcx.

Compute a salt from arguments passed via -Cmetadata.

Make library paths passed by compiletest tool absolute.

Otherwise, changing the current working directory can mess up runtime linking.

Make CrateStore::crate_name() return an InternedString to avoid unnecessary allocations.

Add missing entries for enum variants in trans::CrateContext::external_srcs.

CrateStore: Allow for custom def_id_to_string mappings in encode_type().

Auto merge of #32407 - alexcrichton:netbsd-gcc-s-link, r=aturon

std: Link to gcc_s on NetBSD

Currently the nightlies we're producing fail when linking some C code into a
Rust application with the error message:

    libgcc_s.so.1: error adding symbols: DSO missing from command line

By linking `gcc_s` instead of `gcc` this error goes away. I haven't tested this
on NetBSD itself, but should help get the Linux cross-compile image moreso up
and working!

use new visitor to erase regions

check for both partialeq and eq

Auto merge of #31908 - jseyfried:disallow_shadowed_traits, r=nikomatsakis

Disallow methods from traits that are not in scope

This PR only allows a trait method to be used if the trait is in scope (fixes #31379).
This is a [breaking-change]. For example, the following would break:
```rust
mod foo {
    pub trait T { fn f(&self) {} }
    impl T for () {}
}

mod bar { pub use foo::T; }

fn main() {
    pub use bar::*;
    struct T; // This shadows the trait `T`,
    ().f() // making this an error.
}
```
r? @nikomatsakis

new tests for RFC #1445

fallout in existing tests

suppress duplicate lints

issue a future-compat lint for constants of invalid type

This is a [breaking-change]: according to RFC #1445, constants used as
patterns must be of a type that *derives* `Eq`. If you encounter a
problem, you are most likely using a constant in an expression where the
type of the constant is some struct that does not currently implement
`Eq`. Something like the following:

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

The easiest and most future compatible fix is to annotate the type in
question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is
not enough, it must be *derived*):

```rust
struct SomeType { ... }
const SOME_CONST: SomeType = ...;

match foo {
    SOME_CONST => ...
}
```

Another good option is to rewrite the match arm to use an `if`
condition (this is also particularly good for floating point types,
which implement `PartialEq` but not `Eq`):

```rust
match foo {
    c if c == SOME_CONST => ...
}
```

Finally, a third alternative is to tag the type with
`#[structural_match]`; but this is not recommended, as the attribute is
never expected to be stabilized. Please see RFC #1445 for more details.

do not overwrite spans as eagerly

this was required to preserve the span from
the #[structural_match] attribute -- but honestly
I am not 100% sure if it makes sense.

modify #[deriving(Eq)] to emit #[structural_match]

to careful use of the span from deriving, we
can permit it in stable code if it derives from
deriving (not-even-a-pun intended)

make `const_expr_to_pat` fallible (but never have it actually fail)

Auto merge of #32428 - nikomatsakis:scopes-in-mir, r=nagisa

Scopes in mir

This PR adds scopes to MIR. There is a tree of scopes (each represented by a `ScopeId`). Every statement, variable, and terminator now has an associated scope and span.  It also adds a `-Z dump-mir` switch one can use to conveniently examine the MIR as optimizations proceed.

The intention is two-fold. First, to support MIR debug-info. This PR does not attempt to modify trans to make use of the scope information, however.

Second, in a more temporary capacity, to support the goal of moving regionck and borowck into the MIR. To that end, the PR also constructs a "scope auxiliary" table storing the extent of each span (this is kept separate from the main MIR, since it contains node-ids) and the dom/post-dom of the region in the graph where the scope occurs. When we move to non-lexical lifetimes, I expect this auxiliary information to be discarded, but that is still some ways in the future (requires, at minimum, an RFC, and there are some thorny details to work out -- though I've got an in-progress draft).

Right now, I'm just dropping this auxiliary information after it is constructed. I was debating for some time whether to add some sort of sanity tests, but decided to just open this PR instead, because I couldn't figure out what such a test would look like (and we don't have independent tests for this today beyond the regionck and borrowck tests).

I'd prefer not to store the auxiliary data into any kind of "per-fn" map. Rather, I'd prefer that we do regionck/borrowck/whatever-else immediately after construction -- that is, we build the MIR for fn X and immediately thereafter do extended correctness checking on it. This will reduce peak memory usage and also ensure that the auxiliary data doesn't exist once optimizations begin. It also clarifies the transition point where static checks are complete and MIR can be more freely optimized.

cc @rust-lang/compiler @nagisa

Fix unsound behaviour with null characters in thread names (issue #32475)

Previously, the thread name (&str) was converted to a CString in the
new thread, but outside unwind::try, causing a panic to continue into FFI.

This patch changes that behaviour, so that the panic instead happens
in the parent thread (where panic infrastructure is properly set up),
not the new thread.

This could potentially be a breaking change for architectures who don't
support thread names.

Signed-off-by: David Henningsson <diwic@ubuntu.com>

Auto merge of #32396 - nodakai:range-contains, r=alexcrichton

Add core::ops::Range*::contains() as per rust-lang/rust#32311

Cleanup

+ Fix a comment and add a test based on it

Lift the restriction on reusing names of primitive types

Introduce name resolution fallback for primitive types

Auto merge of #32346 - nikomatsakis:no-erased-regions, r=eddyb

Remove `ErasedRegions` from substs

This commit removes the `ErasedRegions` enum from `Substs`. Instead, in trans, we just generate a vector of `ReStatic` of suitable length. The goal is both general cleanup and to help pave the way for a glorious future where erasure is used in type check.

r? @eddyb

One concern: might be nice to do some profiling. Not sure the best way to do that. Perhaps I'll investigate running nrc's test suite locally.

make available monomorphizations shared by CGU

The current setup means that all generics are local to a codegen-unit,
which means massive duplication.

remove `empty_substs_for_node_id`

remove ErasedRegions from substitutions

This hack has long since outlived its usefulness; the transition to
trans passing around full substitutions is basically done. Instead of
`ErasedRegions`, just supply substitutions with a suitable number of
`'static` entries, and invoke `erase_regions` when needed (the latter of
which we already do).

rewrite foreign types lint not to trawl the HIR

It no longer reads from `ast_ty_to_ty_cache`, which was very wrong. It
also correctly handles higher-ranked regions.

Auto merge of #32465 - steveklabnik:rollup, r=steveklabnik

Rollup of 6 pull requests

- Successful merges: #32276, #32416, #32452, #32459, #32462, #32464
- Failed merges:

Rollup merge of #32464 - GuillaumeGomez:patch-6, r=steveklabnik

Improve some Option code example

Part of #29366.

r? @steveklabnik

Rollup merge of #32462 - tclfs:patch-1, r=steveklabnik

Docs: some tiny corrections

TNT->`tnt`
firecracker->`firecracker`

Rollup merge of #32459 - nrc:json-err-text, r=nikomatsakis

Include source text in JSON errors

Rollup merge of #32452 - GuillaumeGomez:patch-5, r=steveklabnik

Add code examples for libstd/time

Fixes #29379.

r? @steveklabnik

Rollup merge of #32416 - GuillaumeGomez:patch-3, r=steveklabnik

Add doc example to clone trait

Fixes #29346.

r? @steveklabnik

Rollup merge of #32276 - brson:doc, r=alexcrichton

doc: Stdin is not writable

pacify the merciless tidy

Improve some Option code example

rework MIR visitor

We now visit more things (e.g., types) and also follow a deliberate
style designed to reduce omissions.

Docs: some tiny corrections

TNT->`tnt`
firecracker->`firecracker`

Auto merge of #32219 - brson:lints, r=alexcrichton

Make warnings of renamed and removed lints themselves lints

This adds the `renamed_and_removed_lints` warning, defaulting
to the warning level.

Fixes #31141