Pull all the upstream work on rust standard library plus fix the mutex problem with asyncify #9
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
…mpiler-errors Rollup of 9 pull requests Successful merges: - rust-lang#119208 (coverage: Hoist some complex code out of the main span refinement loop) - rust-lang#119216 (Use diagnostic namespace in stdlib) - rust-lang#119414 (bootstrap: Move -Clto= setting from Rustc::run to rustc_cargo) - rust-lang#119420 (Handle ForeignItem as TAIT scope.) - rust-lang#119468 (rustdoc-search: tighter encoding for f index) - rust-lang#119628 (remove duplicate test) - rust-lang#119638 (fix cyle error when suggesting to use associated function instead of constructor) - rust-lang#119640 (library: Fix warnings in rtstartup) - rust-lang#119642 (library: Fix a symlink test failing on Windows) r? `@ghost` `@rustbot` modify labels: rollup
Update cargo 10 commits in add15366eaf3f3eb84717d3b8b71902ca36a7c84..2ce45605d9db521b5fd6c1211ce8de6055fdb24e 2024-01-02 03:24:42 +0000 to 2024-01-04 18:04:13 +0000 - feat(embedded): Add prefix-char frontmatter syntax support (rust-lang/cargo#13247) - Update dependency handlebars to v5 for mdman. (rust-lang/cargo#13249) - Deprecate rustc plugin support in cargo (rust-lang/cargo#13248) - feat(embedded): Add multiple experimental manifest syntaxes (rust-lang/cargo#13241) - chore: update auto labels (rust-lang/cargo#13244) - test: support publish package with a `public` field. (rust-lang/cargo#13245) - `cargo fix`: Call rustc fewer times. (rust-lang/cargo#13243) - chore: tracing be compat with rustc_log (rust-lang/cargo#13239) - chore(deps): update compatible (rust-lang/cargo#13227) - Contrib: Fix team HackMD links (rust-lang/cargo#13237) r? ghost
…r=wesleywiser Avoid specialization in the metadata serialization code With the exception of a perf-only specialization for byte slices and byte vectors. This uses the same trick of introducing a new trait and having the Encodable and Decodable derives add a bound to it as used for TyEncoder/TyDecoder. The new code is clearer about which encoder/decoder uses which impl and it reduces the dependency of rustc on specialization, making it easier to remove support for specialization entirely or turn it into a construct that is only allowed for perf optimizations if we decide to do this.
The bootstrap bump has happened, so the bootstrap compiler now contains the new diagnotic.
Two small bitset optimisations
rustc_span: Optimize syntax context comparisons Including comparisons with root context. - `eq_ctxt` doesn't require retrieving full `SpanData`, or taking the span interner lock twice. - Checking `SyntaxContext` for "rootness" is cheaper than extracting a full outer `ExpnData` for it and checking *it* for rootness. The internal lint for `eq_ctxt` is also tweaked to detect `a.ctxt() != b.ctxt()` in addition to `a.ctxt() == b.ctxt()`.
Automatic Rustup
This cuts down on the amount of data we need to ship and users need to keep on disk for each Rust toolchain. As noted in the added comment, there's not much going on in these executables, so the added benefit of symbols and debuginfo isn't large, while the cost is not insignificant. This takes each of the binaries (we store 4 identical copies under different names) from 3.7MB to 384KB.
…GuillaumeGomez rustdoc: search for tuples and unit by type with `()` This feature extends rustdoc to support the syntax that most users will naturally attempt to use to search for tuples. Part of rust-lang#60485 Function signature searches already support tuples and unit. The explicit name `primitive:tuple` and `primitive:unit` can be used to match a tuple or unit, while `()` will match either one. It also follows the direction set by the actual language for parens as a group, so `(u8,)` will only match a tuple, while `(u8)` will match a plain, unwrapped byte—thanks to loose search semantics, it will also match the tuple. ## Preview * [`option<t>, option<u> -> (t, u)`](<https://notriddle.com/rustdoc-html-demo-5/tuple-unit/std/index.html?search=option%3Ct%3E%2C option%3Cu%3E -%3E (t%2C u)>) * [`[t] -> (t,)`](<https://notriddle.com/rustdoc-html-demo-5/tuple-unit/std/index.html?search=[t] -%3E (t%2C)>) * [`(ipaddr,) -> socketaddr`](<https://notriddle.com/rustdoc-html-demo-5/tuple-unit/std/index.html?search=(ipaddr%2C) -%3E socketaddr>) ## Motivation When type-based search was first landed, it was directly [described as incomplete][a comment]. [a comment]: rust-lang#23289 (comment) Filling out the missing functionality is going to mean adding support for more of Rust's [type expression] syntax, such as tuples (in this PR), references, raw pointers, function pointers, and closures. [type expression]: https://doc.rust-lang.org/reference/types.html#type-expressions There does seem to be demand for this sort of thing, such as [this Discord message](https://discord.com/channels/442252698964721669/443150878111694848/1042145740065099796) expressing regret at rustdoc not supporting tuples in search queries. ## Reference description (from the Rustdoc book) <table> <thead> <tr> <th>Shorthand</th> <th>Explicit names</th> </tr> </thead> <tbody> <tr><td colspan="2">Before this PR</td></tr> <tr> <td><code>[]</code></td> <td><code>primitive:slice</code> and/or <code>primitive:array</code></td> </tr> <tr> <td><code>[T]</code></td> <td><code>primitive:slice<T></code> and/or <code>primitive:array<T></code></td> </tr> <tr> <td><code>!</code></td> <td><code>primitive:never</code></td> </tr> <tr><td colspan="2">After this PR</td></tr> <tr> <td><code>()</code></td> <td><code>primitive:unit</code> and/or <code>primitive:tuple</code></td> </tr> <tr> <td><code>(T)</code></td> <td><code>T</code></td> </tr> <tr> <td><code>(T,)</code></td> <td><code>primitive:tuple<T></code></td> </tr> </tbody> </table> A single type expression wrapped in parens is the same as that type expression, since parens act as the grouping operator. If they're empty, though, they will match both `unit` and `tuple`, and if there's more than one type (or a trailing or leading comma) it is the same as `primitive:tuple<...>`. However, since items can be left out of the query, `(T)` will still return results for types that match tuples, even though it also matches the type on its own. That is, `(u32)` matches `(u32,)` for the exact same reason that it also matches `Result<u32, Error>`. ## Future direction The [type expression grammar](https://doc.rust-lang.org/reference/types.html#type-expressions) from the Reference is given below: <pre><code>Syntax Type : TypeNoBounds | <a href="https://doc.rust-lang.org/reference/types/impl-trait.html">ImplTraitType</a> | <a href="https://doc.rust-lang.org/reference/types/trait-object.html">TraitObjectType</a> <br> TypeNoBounds : <a href="https://doc.rust-lang.org/reference/types.html#parenthesized-types">ParenthesizedType</a> | <a href="https://doc.rust-lang.org/reference/types/impl-trait.html">ImplTraitTypeOneBound</a> | <a href="https://doc.rust-lang.org/reference/types/trait-object.html">TraitObjectTypeOneBound</a> | <a href="https://doc.rust-lang.org/reference/paths.html#paths-in-types">TypePath</a> | <a href="https://doc.rust-lang.org/reference/types/tuple.html#tuple-types">TupleType</a> | <a href="https://doc.rust-lang.org/reference/types/never.html">NeverType</a> | <a href="https://doc.rust-lang.org/reference/types/pointer.html#raw-pointers-const-and-mut">RawPointerType</a> | <a href="https://doc.rust-lang.org/reference/types/pointer.html#shared-references-">ReferenceType</a> | <a href="https://doc.rust-lang.org/reference/types/array.html">ArrayType</a> | <a href="https://doc.rust-lang.org/reference/types/slice.html">SliceType</a> | <a href="https://doc.rust-lang.org/reference/types/inferred.html">InferredType</a> | <a href="https://doc.rust-lang.org/reference/paths.html#qualified-paths">QualifiedPathInType</a> | <a href="https://doc.rust-lang.org/reference/types/function-pointer.html">BareFunctionType</a> | <a href="https://doc.rust-lang.org/reference/macros.html#macro-invocation">MacroInvocation</a> </code></pre> ImplTraitType and TraitObjectType (and ImplTraitTypeOneBound and TraitObjectTypeOneBound) are not yet implemented. They would mostly desugar to `trait:`, similarly to how `!` desugars to `primitive:never`. ParenthesizedType and TuplePath are added in this PR. TypePath is already implemented (except const generics, which is not planned, and function-like trait syntax, which is planned as part of closure support). NeverType is already implemented. RawPointerType and ReferenceType require parsing and fixes to the search index to store this information, but otherwise their behavior seems simple enough. Just like tuples and slices, `&T` would be equivalent to `primitive:reference<T>`, `&mut T` would be equivalent to `primitive:reference<keyword:mut, T>`, `*T` would be equivalent to `primitive:pointer<T>`, `*mut T` would be equivalent to `primitive:pointer<keyword:mut, T>`, and `*const T` would be equivalent to `primitive:pointer<keyword:const, T>`. Lifetime generics support is not planned, because lifetime subtyping seems too complicated. ArrayType is subsumed by SliceType right now. Implementing const generics is not planned, because it seems like it would require a lot of implementation complexity for not much gain. InferredType isn't really covered right now. Its semantics in a search context are not obvious. QualifiedPathInType is not implemented, and it is not planned. I would need a use case to justify it, and act as a guide for what the exact semantics should be. BareFunctionType is not implemented. Along with function-like trait syntax, which is formally considered a TypePath, it's the biggest missing feature to be able to do structured searches over generic APIs like `Option`. MacroInvocation is not parsed (macro names are, but they don't mean the same thing here at all). Those are gone by the time Rustdoc sees the source code.
…8472 merge core_panic feature into panic_internals I don't know why those are two separate features, but it does not seem intentional. This merge is useful because with rust-lang#118123, panic_internals is recognized as an internal feature, but core_panic is not -- but core_panic definitely should be internal.
…staged, r=Mark-Simulacrum
pass allow-{dirty,staged} to clippy
Support of Clippy's `--allow-dirty` and `--allow-staged` flags on bootstrap.
Resolves rust-lang#119483
…ble, r=cjgillot rustc_mir_transform: Make DestinationPropagation stable for queries By using `FxIndexMap` instead of `FxHashMap`, so that the order of visiting of locals is deterministic. We also need to bless `copy_propagation_arg.foo.DestinationPropagation.panic*.diff`. Do not review the diff of the diff. Instead look at the diff files before and after this commit. Both before and after this commit, 3 statements are replaced with nop. It's just that due to change in ordering, different statements are replaced. But the net result is the same. In other words, compare this diff (before fix): * https://github.com/rust-lang/rust/blob/090d5eac722000906cc00d991f2bf052b0e388c3/tests/mir-opt/dest-prop/copy_propagation_arg.foo.DestinationPropagation.panic-unwind.diff With this diff (after fix): * https://github.com/rust-lang/rust/blob/f603babd63a607e155609dc0277806e559626ea0/tests/mir-opt/dest-prop/copy_propagation_arg.foo.DestinationPropagation.panic-unwind.diff and you can see that both before and after the fix, we replace 3 statements with `nop`s. I find it _slightly_ surprising that the test this PR affects did not previously fail spuriously due to the indeterminism of `FxHashMap`, but I guess in can be explained with the predictability of small `FxHashMap`s with `usize` (`Local`) keys, or something along those lines. This should fix [this](rust-lang#119252 (comment)) comment, but I wanted to make a separate PR for this fix for a simpler development and review process. Part of rust-lang#84447 which is E-help-wanted. r? `@cjgillot` who is reviewer for the highly related PR rust-lang#119252.
Fixed ambiguity in hint.rs Needle and haystack are actually not the same, they remain constant.
…rrors rustc_span: More consistent span combination operations Also add more tests for using `tt` in addition to `ident`, and some other minor tweaks, see individual commits. This is a part of rust-lang#119412 that doesn't yet add side tables for metavariable spans.
…t_support, r=petrochenkov compiler: update Fuchsia sanitizer support.
…monster-mess, r=WaffleLapkin Remove ignore-stage1 that was added when changing error count msg The bootstrap bump has happened, so the bootstrap compiler now contains the new diagnostic. this was added in rust-lang#118138
…, r=Kobzol Strip lld-wrapper binaries This cuts down on the amount of data we need to ship and users need to keep on disk for each Rust toolchain. As noted in the added comment, there's not much going on in these executables, so the added benefit of symbols and debuginfo isn't large, while the cost is not insignificant. This takes each of the binaries (we store 4 identical copies under different names) from 3.7MB to 384KB.
…e_userspace_types_send, r=Nilstrieb,dtolnay Making `User<T>` and `User<[T]>` `Send` All `User` types in SGX point to owned memory in userspace. Special care is always needed when accessing this memory as it must be assumed that an attacker is always able to change its content. Therefore, we can also easily transfer this memory between thread boundaries. cc: ``@mzohreva`` ``@vn971`` ``@belalH`` ``@jethrogb``
…=Nilstrieb,dtolnay chore: Bump compiler_builtins Actually closes rust-lang#118079.
…er-errors Add support for shell argfiles Closes rust-lang/compiler-team#684
…ion, r=fee1-dead `~const` trait and projection bounds do not imply their non-const counterparts This PR removes the hack where we install a non-const trait and projection bound for every `const_trait` and `~const` projection bound we have in the AST. It ends up messing up more things than it fixes, see words below. Fixes rust-lang#119718 cc `@fmease` `@fee1-dead` `@oli-obk` r? fee1-dead or one of y'all i don't care --- My understanding is that this hack was added to support the following code: ```rust pub trait Owo<X = <Self as Uwu>::T> {} #[const_trait] pub trait Uwu: Owo {} ``` Which is concretely lifted from in the `FromResidual` and `Try` traits. Since within the param-env of `trait Uwu`, we only know that `Self: ~const Uwu` and not `Self: Uwu`, the projection `<Self as Uwu>::T` is not satsifyable. This causes problems such as rust-lang#119718, since instantiations of `FnDef` types coming from `const fn` really do **only** implement one of `FnOnce` or `const FnOnce`! --- In the long-term, I believe that such code should really look something more like: ```rust #[const_trait] pub trait Owo<X = <Self as ~const Uwu>::T> {} #[const_trait] pub trait Uwu: Owo {} ``` ... and that we should introduce some sort of `<T as ~const Foo>::Bar` bound syntax, since due to the fact that `~const` bounds can be present in item bounds, e.g. ```rust #[const_trait] trait Foo { type Bar: ~const Destruct; } ``` It's easy to see that `<T as Foo>::Bar` and `<T as ~const Foo>::Bar` (or `<T as const Foo>::Bar`) can be distinct types with distinct item bounds! **Admission**: I know I've said before that I don't like `~const` projection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.
core: panic: fix broken link
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#118241 (Making `User<T>` and `User<[T]>` `Send`) - rust-lang#118645 (chore: Bump compiler_builtins) - rust-lang#118680 (Add support for shell argfiles) - rust-lang#119721 (`~const` trait and projection bounds do not imply their non-const counterparts) - rust-lang#119768 (core: panic: fix broken link) r? `@ghost` `@rustbot` modify labels: rollup
…=the8472 A more efficient slice comparison implementation for T: !BytewiseEq (This is a follow up PR on rust-lang#113654) This PR changes the implementation for `[T]` slice comparison when `T: !BytewiseEq`. The previous implementation using zip was not optimized properly by the compiler, which didn't leverage the fact that both length were equal. Performance improvements are for example 20% when testing that `[Some(0_u64); 4096].as_slice() == [Some(0_u64); 4096].as_slice()`.
…g-point exceptions
…=matthewjasper Avoid silencing relevant follow-up errors r? `@matthewjasper` This PR only adds new errors to tests that are already failing and fixes one ICE. Several tests were changed to not emit new errors. I believe all of them were faulty tests, and not explicitly testing for the code that had new errors.
Update cargo 14 commits in 2ce45605d9db521b5fd6c1211ce8de6055fdb24e..3e428a38a34e820a461d2cc082e726d3bda71bcb 2024-01-04 18:04:13 +0000 to 2024-01-09 20:46:36 +0000 - refactor: replace `iter_join` with `itertools::join` (rust-lang/cargo#13275) - docs(unstable): doc comments for items and fields (rust-lang/cargo#13274) - crates-io: Set `Content-Type: application/json` only for requests with a body payload (rust-lang/cargo#13264) - fix: only inherit workspace package table if the new package is a member (rust-lang/cargo#13261) - feat(cli): add colors to `-Zhelp` console output (rust-lang/cargo#13269) - chore(deps): update msrv (rust-lang/cargo#13266) - refactor(toml): Make it more obvious to update package-dependent fields (rust-lang/cargo#13267) - chore(ci): Fix MSRV:3 updates (rust-lang/cargo#13268) - chore(ci): Shot-in-the-dark fix for MSRV updating (rust-lang/cargo#13265) - fix: set OUT_DIR for all units with build scripts (rust-lang/cargo#13204) - fix(manifest): Provide unused key warnings for lints table (rust-lang/cargo#13262) - test(manifest): Verify we warn on unused workspace.package fields (rust-lang/cargo#13263) - docs(changelog): Call out cargo-new lockfile change (rust-lang/cargo#13260) - chore: Add dependency dashboard (rust-lang/cargo#13255) r? ghost
…mpiler-errors Explain base expression for struct update syntax Fixes rust-lang#106890 `@rustbot` label +A-diagnostics
…t-def-gen-args, r=GuillaumeGomez rustdoc: offset generic args of cross-crate trait object types when cleaning Fixes rust-lang#119529. This PR contains several refactorings apart from the bug fix. Best reviewed commit by commit. r? GuillaumeGomez
Fix an ICE that occurs after an error has already been reported fixes rust-lang#117491 cc `@jswrenn`
rint intrinsics: caution against actually trying to check for floating-point exceptions
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#106893 (Explain base expression for struct update syntax) - rust-lang#119769 (rustdoc: offset generic args of cross-crate trait object types when cleaning) - rust-lang#119772 (Fix an ICE that occurs after an error has already been reported) - rust-lang#119782 (rint intrinsics: caution against actually trying to check for floating-point exceptions) r? `@ghost` `@rustbot` modify labels: rollup
|
This is likely a better attempt than #11 - anything blocking this to be reviewed now? 😁 |
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.
No description provided.