Automated pull from upstream master
#78
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…markers Fix #116252.
Add a few utility functions as well and extend most `mir` and `ty` ADTs to implement `PartialEq` and `Eq`.
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.
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`.
github-actions
bot
added
automation
There were added in 50ca5ef
|
Build succeeded:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR pulls the following changes from the upstream repository:
Clone/PartialOrd/Ord/Hashinrustc_type_irrust-lang/rust#117407coverage::Errorwith assertions rust-lang/rust#117421sincevalue in parsed form rust-lang/rust#117377