Automatic Rustup #3147
Merged
Automatic Rustup #3147
Conversation
This file contains hidden or 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
Uplift `ClauseKind` and `PredicateKind` into `rustc_type_ir` Uplift `ClauseKind` and `PredicateKind` into `rustc_type_ir`. Blocked on #116951 r? `@ghost`
Modernize rustc_builtin_macros generics helpers - Rustfmt-compatible formatting for the code snippets in comments - Eliminate an _"Extra scope required"_ obsoleted by NLL
Refactor type visitor walking r? `@petrochenkov` pulling out the uncontroversial parts of rust-lang/rust#113671
stack_overflow: get_stackp using MAP_STACK flag on dragonflybsd too.
Miri subtree update r? `@ghost`
Add test for 113326 Closes #113326 Bisecting points to #113636 as the fix
Intern `LocalDefId` list from `opaque_types_defined_by` query r? oli-obk
Rollup of 7 pull requests Successful merges: - #116801 (Add test for 113326) - #117133 (Merge `impl_wf_inference` (`check_mod_impl_wf`) check into coherence checking) - #117136 (Intern `LocalDefId` list from `opaque_types_defined_by` query) - #117150 (Update cargo) - #117158 (Update THIR unused_unsafe lint) - #117160 (Fix typo in test comment) - #117168 (Fix some coroutine sentences that don't make sense anymore.) r? `@ghost` `@rustbot` modify labels: rollup
This keeps track of usage of internal features, and changes the message to instead tell them that using internal features is not supported. See MCP 620.
Remap Cargo dependencies to /rust/deps :warning: **This doesn't affect user-compiled programs, it only affects building the Rust compiler itself.** :warning: Right now, `rust.remap-debuginfo = true` doesn't completely remap all paths: while LLVM and rustc sources are properly remapped (respectively to `/rust/llvm` and `/rust/$commit`), Cargo dependencies still use absolute paths from the Cargo home. This never affected builds from CI much, because `CARGO_HOME=/cargo` in CI, so users see paths like this included in the precompiled binaries and libraries: ``` /cargo/registry/src/index.crates.io-6f17d22bba15001f/gimli-0.26.2/src/read/line.rs ``` Builds outside CI don't have remapping though, and it's confusing that the config flag doesn't fully do what it advertises. This PR fixes it by adding remapping for dependencies too. *All registries's* source directory are remapped to `/rust/deps`, to account for multiple registries being able to contain crates.io crates (sparse index vs git, and source replacement mirrors). This results in paths like this being included: ``` /rust/deps/gimli-0.26.2/src/read/line.rs ```
…eywiser Stop telling people to submit bugs for internal feature ICEs This keeps track of usage of internal features, and changes the message to instead tell them that using internal features is not supported. I thought about several ways to do this but now used the explicit threading of an `Arc<AtomicBool>` through `Session`. This is not exactly incremental-safe, but this is fine, as this is set during macro expansion, which is pre-incremental, and also only affects the output of ICEs, at which point incremental correctness doesn't matter much anyways. See [MCP 620.](rust-lang/compiler-team#596) 
Mark .rmeta files as /SAFESEH on x86 Windows. Chrome links .rlibs with /WHOLEARCHIVE or -Wl,--whole-archive to prevent the linker from discarding static initializers. This works well, except on Windows x86, where lld complains: error: /safeseh: lib.rmeta is not compatible with SEH The fix is simply to mark the .rmeta as SAFESEH aware. This is trivially true, since the metadata file does not contain any executable code.
Store #[stable] attribute's `since` value in structured form Followup to rust-lang/rust#116773 (review). Prior to this PR, if you wrote an improper `since` version in a `stable` attribute, such as `#[stable(feature = "foo", since = "wat.0")]`, rustc would emit a diagnostic saying **_'since' must be a Rust version number, such as "1.31.0"_** and then throw out the whole `stable` attribute as if it weren't there. This strategy had 2 problems, both fixed in this PR: 1. If there was also a `#[deprecated]` attribute on the same item, rustc would want to enforce that the stabilization version is older than the deprecation version. This involved reparsing the `stable` attribute's `since` version, with a diagnostic **_invalid stability version found_** if it failed to parse. Of course this diagnostic was unreachable because an invalid `since` version would have already caused the `stable` attribute to be thrown out. This PR deletes that unreachable diagnostic. 2. By throwing out the `stable` attribute when `since` is invalid, you'd end up with a second diagnostic saying **_function has missing stability attribute_** even though your function is not missing a stability attribute. This PR preserves the `stable` attribute even when `since` cannot be parsed, avoiding the misleading second diagnostic. Followups I plan to try next: - Do the same for the `since` value of `#[deprecated]`. - See whether it makes sense to also preserve `stable` and/or `unstable` attributes when they contain an invalid `feature`. What redundant/misleading diagnostics can this eliminate? What problems arise from not having a usable feature name for some API, in the situation that we're already failing compilation, so not concerned about anything that happens in downstream code?
…Kobzol Prepare the `bootstrap` tool for the new check-cfg syntax This PR prepare the `bootstrap` tool for the [new check-cfg syntax](rust-lang/rust#111072) as well as the according [changes to Cargo](rust-lang/cargo#12845). ~~Note that while the new syntax can technically available on stage > 2, we actually cannot use it since we need a cargo version that supports the new syntax which won't happen until the next beta bump (if I understand everything correctly).~~ r? bootstrap
…lcnr
Rework negative coherence to properly consider impls that only partly overlap
This PR implements a modified negative coherence that handles impls that only have partial overlap.
It does this by:
1. taking both impl trait refs, instantiating them with infer vars
2. equating both trait refs
3. taking the equated trait ref (which represents the two impls' intersection), and resolving any vars
4. plugging all remaining infer vars with placeholder types
these placeholder-plugged trait refs can then be used normally with the new trait solver, since we no longer have to worry about the issue with infer vars in param-envs.
We use the **new trait solver** to reason correctly about unnormalized trait refs (due to deferred projection equality), since this avoid having to normalize anything under param-envs with infer vars in them.
This PR then additionally:
* removes the `FnPtr` knowable hack by implementing proper negative `FnPtr` trait bounds for rigid types.
---
An example:
Consider these two partially overlapping impls:
```
impl<T, U> PartialEq<&U> for &T where T: PartialEq<U> {}
impl<F> PartialEq<F> for F where F: FnPtr {}
```
Under the old algorithm, we would take one of these impls and replace it with infer vars, then try unifying it with the other impl under identity substitutions. This is not possible in either direction, since it either sets `T = U`, or tries to equate `F = &?0`.
Under the new algorithm, we try to unify `?0: PartialEq<?0>` with `&?1: PartialEq<&?2>`. This gives us `?0 = &?1 = &?2` and thus `?1 = ?2`. The intersection of these two trait refs therefore looks like: `&?1: PartialEq<&?1>`. After plugging this with placeholders, we get a trait ref that looks like `&!0: PartialEq<&!0>`, with the first impl having substs `?T = ?U = !0` and the second having substs `?F = &!0`[^1].
Then we can take the param-env from the first impl, and try to prove the negated where clause of the second.
We know that `&!0: !FnPtr` never holds, since it's a rigid type that is also not a fn ptr, we successfully detect that these impls may never overlap.
[^1]: For the purposes of this example, I just ignored lifetimes, since it doesn't really matter.
Never consider raw pointer casts to be trival HIR typeck tries to figure out which casts are trivial by doing them as coercions and seeing whether this works. Since HIR typeck is oblivious of lifetimes, this doesn't work for pointer casts that only change the lifetime of the pointee, which are, as borrowck will tell you, not trivial. This change makes it so that raw pointer casts are never considered trivial. This also incidentally fixes the "trivial cast" lint false positive on the same code. Unfortunately, "trivial cast" lints are now never emitted on raw pointer casts, even if they truly are trivial. This could be fixed by also doing the lint in borrowck for raw pointers specifically. fixes #113257
…, r=oli-obk Deny providing explicit effect params r? `@oli-obk` cc rust-lang/rust#110395
Centralize command running in boostrap (part one) This PR tries to consolidate the various `run, try_run, run_quiet, run_quiet_delaying_failure, run_delaying_failure` etc. methods on `Builder`. This PR only touches command execution which doesn't produce output that would be later read by bootstrap, and it also only refactors spawning of commands that happens after a builder is created (commands executed during download & git submodule checkout are left as-is, for now). The `run_cmd` method is quite meaty, but I expect that it will be changing rapidly soon, so I considered it easy to kept everything in a single method, and only after things settle down a bit, then maybe again split it up a bit. I still kept the original shortcut methods like `run_quiet_delaying_failure`, but they now only delegate to `run_cmd`. I tried to keep the original behavior (or as close to it as possible) for all the various commands, but it is a giant mess, so there may be some deviations. Notably, `cmd.output()` is now always called, instead of just `status()`, which was called previously in some situations. Apart from the refactored methods, there is also `Config::try_run`, `check_run`, methods that run commands that produce output, oh my… that's left for follow-up PRs :) The driving goal of this (and following) refactors is to centralize command execution in bootstrap on a single place, to make command mocking feasible. r? `@onur-ozkan`
Only emit one error per unsized binding, instead of one per usage Fix #56607.
Allow target specs to use an LLD flavor, and self-contained linking components This PR allows: - target specs to use an LLD linker-flavor: this is needed to switch `x86_64-unknown-linux-gnu` to using LLD, and is currently not possible because the current flavor json serialization fails to roundtrip on the modern linker-flavors. This can e.g. be seen in rust-lang/rust#115622 (comment) which explains where an `Lld::Yes` is ultimately deserialized into an `Lld::No`. - target specs to declare self-contained linking components: this is needed to switch `x86_64-unknown-linux-gnu` to using `rust-lld` - adds an end-to-end test of a custom target json simulating `x86_64-unknown-linux-gnu` being switched to using `rust-lld` - disables codegen backends from participating because they don't support `-Zgcc-ld=lld` which is the basis of mcp510. r? `@petrochenkov:` if the approach discussed rust-lang/rust#115622 (comment) and on zulip would work for you: basically, see if we can emit only modern linker flavors in the json specs, but accept both old and new flavors while reading them, to fix the roundtrip issue. The backwards compatible `LinkSelfContainedDefault` variants are still serialized and deserialized in `crt-objects-fallback`, while the spec equivalent of e.g. `-Clink-self-contained=+linker` is serialized into a different json object (with future-proofing to incorporate `crt-objects-fallback` in the future). --- I've been test-driving this in rust-lang/rust#113382 to test actually switching `x86_64-unknown-linux-gnu` to `rust-lld` (and fix what needs to be fixed in CI, bootstrap, etc), and it seems to work fine.
…r=dtolnay Stabilize `[const_]pointer_byte_offsets` Closes #96283 Awaiting FCP completion: rust-lang/rust#96283 (comment) r? libs-api
… r=ehuss feat(docs): add cargo-pgo to PGO documentation 📝 fixes #114995
…i-obk Stash and cancel cycle errors for auto trait leakage in opaques We don't need to emit a traditional cycle error when we have a selection error that explains what's going on but in more detail. We may want to augment this error to actually point out the cycle, now that the cycle error is not being emitted. We could do that by storing the set of opaques that was in the `CyclePlaceholder` that gets returned from `type_of_opaque`. r? `@oli-obk` cc `@estebank` #117235
Create a new ConstantKind variant (ZeroSized) for StableMIR ZeroSized constants can be represented as `mir::Const::Val` even if their layout is not yet known. In those cases, CrateItem::body() was crashing when trying to convert a `ConstValue::ZeroSized` into its stable counterpart `ConstantKind::Allocated`. Instead, we now map `ConstValue::ZeroSized` into a new variant: `ConstantKind::ZeroSized`. **Note:** I didn't add any new test here since we already have covering tests in our project repository which I manually confirmed that will fix the issue.
Rollup of 6 pull requests Successful merges: - #114998 (feat(docs): add cargo-pgo to PGO documentation 📝) - #116868 (Tweak suggestion span for outer attr and point at item following invalid inner attr) - #117240 (Fix documentation typo in std::iter::Iterator::collect_into) - #117241 (Stash and cancel cycle errors for auto trait leakage in opaques) - #117262 (Create a new ConstantKind variant (ZeroSized) for StableMIR) - #117266 (replace transmute by raw pointer cast) r? `@ghost` `@rustbot` modify labels: rollup
Suggest assoc fn `new` when trying to build tuple struct with private fields Fix #22488.
Lint overlapping ranges as a separate pass This reworks the [`overlapping_range_endpoints`](https://doc.rust-lang.org/beta/nightly-rustc/rustc_lint_defs/builtin/static.OVERLAPPING_RANGE_ENDPOINTS.html) lint. My motivations are: - It was annoying to have this lint entangled with the exhaustiveness algorithm, especially wrt librarification; - This makes the lint behave consistently. Here's the consistency story. Take the following matches: ```rust match (0u8, true) { (0..=10, true) => {} (10..20, true) => {} (10..20, false) => {} _ => {} } match (true, 0u8) { (true, 0..=10) => {} (true, 10..20) => {} (false, 10..20) => {} _ => {} } ``` There are two semantically consistent options: option 1 we lint all overlaps between the ranges, option 2 we only lint the overlaps that could actually occur (i.e. the ones with `true`). Option 1 is what this PR does. Option 2 is possible but would require the exhaustiveness algorithm to track more things for the sake of the lint. The status quo is that we're inconsistent between the two. Option 1 generates more false postives, but I prefer it from a maintainer's perspective. I do think the difference is minimal; cases where the difference is observable seem rare. This PR adds a separate pass, so this will have a perf impact. Let's see how bad, it looked ok locally.
Only call `mir_const_qualif` if absolutely necessary Pull the perf change out of rust-lang/rust#113617 This should not have any impact on behaviour (if it does, we'll see an ICE)
Remove `rustc_symbol_mangling/messages.ftl`. It contains a single message that (a) doesn't contain any natural language, and (b) is only used in tests. r? `@davidtwco`
…rrors Properly restore snapshot when failing to recover parsing ternary If the recovery parsed an expression, then failed to eat a `:`, it would return `false` without restoring the snapshot. Fix this by always restoring the snapshot when returning `false`. Draft for now because I'd like to try and improve this recovery further. Fixes #117208
Fix ICE: Restrict param constraint suggestion When encountering an associated item with a type param that could be constrained, do not look at the parent item if the type param comes from the associated item. Fix #117209, fix #89868.
…, r=workingjubilee,RalfJung NVPTX: Allow PassMode::Direct for ptx kernels for now Upgrading the nvptx toolchain to the newest nightly makes it hit the assert that links to rust-lang/rust#115666 It seems like most targets get around this by using `PassMode::Indirect`. That is impossible for the kernel as it's not a normal call, but instead the arguments are copied from CPU to GPU and the passed pointer would be invalid when it reached the GPU. I also made an experiment with `PassMode::Cast` but at least the most simple version of this broke the assembly API tests. I added fixing the pass mode in my unofficial tracking issue list (I do not have the necessary permissions to update to official one). rust-lang/rust#38788 (comment) Since the ptx_abi is currently unstable and have been working with `PassMode::Direct` for more than a year now, the steps above is hopefully sufficient to enable it as an exception until I can prioritize to fix it. I'm currently looking at steps to enable the CI for nvptx64 again and would prefer to finish that first.
Hide internal methods from documentation The two methods here are perma-unstable and only made public for technical reasons. There is no reason to show them in documentation. `@rustbot` label +A-docs
fix miri target information for Test step self-explanatory r? RalfJung
Allow partially moved values in match
This PR attempts to unify the behaviour between `let _ = PLACE`, `let _: TY = PLACE;` and `match PLACE { _ => {} }`.
The logical conclusion is that the `match` version should not check for uninitialised places nor check that borrows are still live.
The `match PLACE {}` case is handled by keeping a `FakeRead` in the unreachable fallback case to verify that `PLACE` has a legal value.
Schematically, `match PLACE { arms }` in surface rust becomes in MIR:
```rust
PlaceMention(PLACE)
match PLACE {
// Decision tree for the explicit arms
arms,
// An extra fallback arm
_ => {
FakeRead(ForMatchedPlace, PLACE);
unreachable
}
}
```
`match *borrow { _ => {} }` continues to check that `*borrow` is live, but does not read the value.
`match *borrow {}` both checks that `*borrow` is live, and fake-reads the value.
Continuation of ~rust-lang/rust#102256 ~rust-lang/rust#104844
Fixes rust-lang/rust#99180 rust-lang/rust#53114
Rollup of 7 pull requests Successful merges: - #116834 (Remove `rustc_symbol_mangling/messages.ftl`.) - #117212 (Properly restore snapshot when failing to recover parsing ternary) - #117246 (Fix ICE: Restrict param constraint suggestion) - #117247 (NVPTX: Allow PassMode::Direct for ptx kernels for now) - #117270 (Hide internal methods from documentation) - #117281 (std::thread : add SAFETY comment) - #117287 (fix miri target information for Test step) r? `@ghost` `@rustbot` modify labels: rollup
…meGomez rustdoc: use JS to inline target type impl docs into alias Preview docs: - https://notriddle.com/rustdoc-html-demo-5/js-trait-alias/std/io/type.Result.html - https://notriddle.com/rustdoc-html-demo-5/js-trait-alias-compiler/rustc_middle/ty/type.PolyTraitRef.html This pull request also includes a bug fix for trait alias inlining across crates. This means more documentation is generated, and is why ripgrep runs slower (it's a thin wrapper on top of the `grep` crate, so 5% of its docs are now the Result type). - Before, built with rustdoc 1.75.0-nightly (aa1a71e9e 2023-10-26), Result type alias method docs are missing: http://notriddle.com/rustdoc-html-demo-5/ripgrep-js-nightly/rg/type.Result.html - After, built with this branch, all the methods on Result are shown: http://notriddle.com/rustdoc-html-demo-5/ripgrep-js-trait-alias/rg/type.Result.html *Review note: This is mostly just reverting rust-lang/rust#115201. The last commit has the new work in it.* Fixes #115718 This is an attempt to balance three problems, each of which would be violated by a simpler implementation: - A type alias should show all the `impl` blocks for the target type, and vice versa, if they're applicable. If nothing was done, and rustdoc continues to match them up in HIR, this would not work. - Copying the target type's docs into its aliases' HTML pages directly causes far too much redundant HTML text to be generated when a crate has large numbers of methods and large numbers of type aliases. - Using JavaScript exclusively for type alias impl docs would be a functional regression, and could make some docs very hard to find for non-JS readers. - Making sure that only applicable docs are show in the resulting page requires a type checkers. Do not reimplement the type checker in JavaScript. So, to make it work, rustdoc stashes these type-alias-inlined docs in a JSONP "database-lite". The file is generated in `write_shared.rs`, included in a `<script>` tag added in `print_item.rs`, and `main.js` takes care of patching the additional docs into the DOM. The format of `trait.impl` and `type.impl` JS files are superficially similar. Each line, except the JSONP wrapper itself, belongs to a crate, and they are otherwise separate (rustdoc should be idempotent). The "meat" of the file is HTML strings, so the frontend code is very simple. Links are relative to the doc root, though, so the frontend needs to fix that up, and inlined docs can reuse these files. However, there are a few differences, caused by the sophisticated features that type aliases have. Consider this crate graph: ```text --------------------------------- | crate A: struct Foo<T> | | type Bar = Foo<i32> | | impl X for Foo<i8> | | impl Y for Foo<i32> | --------------------------------- | ---------------------------------- | crate B: type Baz = A::Foo<i8> | | type Xyy = A::Foo<i8> | | impl Z for Xyy | ---------------------------------- ``` The type.impl/A/struct.Foo.js JS file has a structure kinda like this: ```js JSONP({ "A": [["impl Y for Foo<i32>", "Y", "A::Bar"]], "B": [["impl X for Foo<i8>", "X", "B::Baz", "B::Xyy"], ["impl Z for Xyy", "Z", "B::Baz"]], }); ``` When the type.impl file is loaded, only the current crate's docs are actually used. The main reason to bundle them together is that there's enough duplication in them for DEFLATE to remove the redundancy. The contents of a crate are a list of impl blocks, themselves represented as lists. The first item in the sublist is the HTML block, the second item is the name of the trait (which goes in the sidebar), and all others are the names of type aliases that successfully match. This way: - There's no need to generate these files for types that have no aliases in the current crate. If a dependent crate makes a type alias, it'll take care of generating its own docs. - There's no need to reimplement parts of the type checker in JavaScript. The Rust backend does the checking, and includes its results in the file. - Docs defined directly on the type alias are dropped directly in the HTML by `render_assoc_items`, and are accessible without JavaScript. The JSONP file will not list impl items that are known to be part of the main HTML file already. [JSONP]: https://en.wikipedia.org/wiki/JSONP
Avoid unnecessary builds/rebuilds of `rust-demangler` This is a combination of two loosely-related changes: - Don't build `rust-demangler` as a dependency of `tests/run-make`, because after #112300 none of the remaining run-make tests actually use it. (If future run-make tests ever do need the demangler, it'll be easy to add it back.) - For `tests/run-coverage`, build the demangler with the stage 0 compiler instead of the current-stage compiler. This avoids having to uselessly rebuild the demangler after modifying and rebuilding the compiler itself.
Member
|
@bors r+ |
Contributor
Contributor
Contributor
|
☀️ Test successful - checks-actions |
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.