…markers

Fix #116252.

Add a few utility functions as well and extend most `mir` and `ty`
ADTs to implement `PartialEq` and `Eq`.

…brary

Some more coroutine renamings

a few places where `gen_` names leaked through but should be coroutine.

r? oli-obk

Store #[deprecated] attribute's `since` value in parsed form

This PR implements the first followup bullet listed in rust-lang/rust#117148 (comment).

We centralize error handling to the attribute parsing code in `compiler/rustc_attr/src/builtin.rs`, and thereby remove some awkward error codepaths from later phases of compilation that had to make sense of these #\[deprecated\] attributes, namely `compiler/rustc_passes/src/stability.rs` and `compiler/rustc_middle/src/middle/stability.rs`.

These checks should be cheap, so there's little reason for them to be
debug-only.

Historically, these errors existed so that the coverage debug code could dump
additional information before reporting a compiler bug. That debug code was
removed by #115962, so we can now simplify these methods by making them panic
when they detect a bug.

…nvocation arguments into the macro

…imd, as these always go together.

Some codegen cleanups around SIMD checks

See rust-lang/rust#115933 (comment) for the reason.

This PR essentially just deduplicates code by moving it into a macro

When encountering unclosed delimiters during lexing, check for diff markers

Fix #116252.

Also consider TAIT to be uncomputable if the MIR body is tainted

Not totally sure if this is the best solution. We could, alternatively, look at the hir typeck results and try to take a type from there instead of just falling back to type error, inferring `u8` instead of `{type error}`. Not certain it really matters, though.

Happy to iterate on this.

Fixes #117413

r? ``@oli-obk`` cc ``@Nadrieril``

coverage: Replace impossible `coverage::Error` with assertions

Historically, these errors existed so that the coverage debug code could dump additional information before reporting a compiler bug. That debug code was removed by #115962, so we can now simplify these methods by making them panic immediately when they detect a bug.

Do not ICE on constant evaluation failure in GVN.

Fixes rust-lang/rust#117362

Rollup of 5 pull requests

Successful merges:

 - #116267 (Some codegen cleanups around SIMD checks)
 - #116712 (When encountering unclosed delimiters during lexing, check for diff markers)
 - #117416 (Also consider TAIT to be uncomputable if the MIR body is tainted)
 - #117421 (coverage: Replace impossible `coverage::Error` with assertions)
 - #117438 (Do not ICE on constant evaluation failure in GVN.)

r? `@ghost`
`@rustbot` modify labels: rollup

Use derivative for `Clone`/`PartialOrd`/`Ord`/`Hash` in `rustc_type_ir`

This uses `derivative` to derive `Clone`/`PartialOrd`/`Ord`/`Hash` for types in `rustc_type_ir`. This doesn't derive `PartialEq`/`Eq` yet, because I have no idea why those are generating slower implementations from derivative.

Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec
struct used in various system calls represents this as a number of seconds and
a number of nanoseconds. Nanoseconds are required to be between 0 and
999_999_999, because the portion outside that range should be represented in
the seconds field; if nanoseconds were larger than 999_999_999, the seconds
field should go up instead.

Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems
that support times before the epoch, that's seconds=-86400, one day before the
epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other
words, a tenth of a second after one minute before the epoch.  On most UNIX
systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS
bug is that it returns seconds=-59, nanoseconds=-900_000_000.

While that's in some sense an accurate description of the time (59.9 seconds
before the epoch), that violates the invariant of the timespec data structure:
nanoseconds must be between 0 and 999999999. This causes this assertion in the
Rust standard library.

So, on macOS, if we get a Timespec value with seconds less than or equal to
zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add
1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then
convert.  The resulting timespec value is still accepted by macOS, and when fed
back into the OS, produces the same results. (If you set a file's mtime with
that timestamp, then read it back, you get back the one with negative
nanoseconds again.)

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

Accept less invalid Rust in rustdoc

pulled out of rust-lang/rust#117213 where this change was already approved

This only affects rustdoc, and has up to [20% perf regressions in rustdoc](rust-lang/rust#117213 (comment)). These are unavoidable, as we are simply doing more checks now, but it's part of the longer term plan of making rustdoc more resistant to ICEs by only accepting valid Rust code.

…llaumeGomez

rustdoc: Document lack of object safety on affected traits

Closes #85138

I saw the issue didn't have any recent activity, if there is another MR for it I missed it.

I want the issue to move forward so here is my proposition.

It takes some space just before the "Implementors" section and only if the trait is **not** object
safe since it is the only case where special care must be taken in some cases and this has the
benefit of avoiding generation of HTML in (I hope) the common case.

Turn const_caller_location from a query to a hook

blocked on rust-lang/rust#117317

cc `@RalfJung`

Add a stable MIR visitor

This change also adds a few utility functions as well and extend most `mir` and `ty` ADTs to implement `PartialEq` and `Eq`.

Fixes rust-lang/project-stable-mir#32

r? `@oli-obk`

prepopulate opaque ty storage before using it

doesn't have any significant impact rn afaict, as we freely define new opaque types during MIR typeck.

It will be relevant with #117278 and once we stop allowing the definition of new opaques in MIR typeck

r? `@compiler-errors`

Add support for pre-unix-epoch file dates on Apple platforms (#108277)

Please note that even though the assertion being hit is the same on MacOS and thus similar to what's described in #108277, on MacOS it's possible to convert the numbers such that they are valid, don't hit the assertion and are round-trippable.
Doing so effectively fixes the issue on Apple platforms.

This PR does not attempt to harden other platforms against negative nanoseconds, which can happen for many reasons including mild filesystem corruption.

----

Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec
struct used in various system calls represents this as a number of seconds and
a number of nanoseconds. Nanoseconds are required to be between 0 and
999_999_999, because the portion outside that range should be represented in
the seconds field; if nanoseconds were larger than 999_999_999, the seconds
field should go up instead.

Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems
that support times before the epoch, that's seconds=-86400, one day before the
epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other
words, a tenth of a second after one minute before the epoch.  On most UNIX
systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS
bug is that it returns seconds=-59, nanoseconds=-900_000_000.

While that's in some sense an accurate description of the time (59.9 seconds
before the epoch), that violates the invariant of the timespec data structure:
nanoseconds must be between 0 and 999999999. This causes this assertion in the
Rust standard library.

So, on macOS, if we get a Timespec value with seconds less than or equal to
zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add
1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then
convert.  The resulting timespec value is still accepted by macOS, and when fed
back into the OS, produces the same results. (If you set a file's mtime with
that timestamp, then read it back, you get back the one with negative
nanoseconds again.)

Co-authored-by: Josh Triplett <josh@joshtriplett.org>

Update cargo

7 commits in 708383d620e183a9ece69b8fe930c411d83dee27..b4d18d4bd3db6d872892f6c87c51a02999b80802
2023-10-27 21:09:26 +0000 to 2023-10-31 18:19:10 +0000
- refactor(toml): Cleanup noticed on the way to rust-lang/cargo#12801 (rust-lang/cargo#12902)
- feat(trim-paths): set env `CARGO_TRIM_PATHS` for build scripts (rust-lang/cargo#12900)
- feat: implement RFC 3127 `-Ztrim-paths` (rust-lang/cargo#12625)
- docs: clarify config to use vendored source is printed to stdout (rust-lang/cargo#12893)
- Improve the margin calculation for the search command's UI (rust-lang/cargo#12890)
- Add new packages to [workspace.members] automatically (rust-lang/cargo#12779)
- refactor(toml): Decouple parsing from interning system (rust-lang/cargo#12881)

r? ghost

Rollup of 5 pull requests

Successful merges:

 - #113241 (rustdoc: Document lack of object safety on affected traits)
 - #117388 (Turn const_caller_location from a query to a hook)
 - #117417 (Add a stable MIR visitor)
 - #117439 (prepopulate opaque ty storage before using it)
 - #117451 (Add support for pre-unix-epoch file dates on Apple platforms (#108277))

r? `@ghost`
`@rustbot` modify labels: rollup

Replace switch to unreachable by assume statements

`UnreachablePropagation` currently keeps some switch terminators alive in order to ensure codegen can infer the inequalities on the discriminants.

This PR proposes to encode those inequalities as `Assume` statements.

This allows to simplify MIR further by removing some useless terminators.

This commit is generated by `ferrocene/tools/pull-upstream/pull.sh`.
The list of excluded files is defined in `.gitattributes`.

There were added in 50ca5ef