attempt at solving issue 116539 #1
Draft
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
Move subtyper below reveal_all and change reveal_all In previous attempt rust-lang#116378 we tried to handle `Opaque` in few different places, but this isn't necessary, after moving subtyper below reveal_all and calling `super_place` on reveal_all, issues cease to exist. r? ``@oli-obk`` Fixes rust-lang#116332 Fixes rust-lang#116265 Fixes rust-lang#116383 Fixes rust-lang#116333
…cs, r=compiler-errors,estebank Add a note to duplicate diagnostics Helps explain why there may be a difference between manual testing and the test suite output and highlights them as something to potentially look into For existing duplicate diagnostics I just blessed them other than a few files that had other `NOTE` annotations in
Do not assert that hidden types don't have erased regions. cc rust-lang#116306 `args` can have erased regions. In the linked issue, this is reached by computing whether a large type is `Freeze` to compute its ABI. I do not have a minimized test to include.
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#116220 (stabilize `Option::as_`(`mut_`)`slice`) - rust-lang#116288 (Add Span to various smir types) - rust-lang#116415 (Move subtyper below reveal_all and change reveal_all) - rust-lang#116428 (Add a note to duplicate diagnostics) - rust-lang#116452 (Do not assert that hidden types don't have erased regions.) r? `@ghost` `@rustbot` modify labels: rollup
The `rustc_span::FileName` enum already differentiates between real files and "fake" files such as `<anon>`. We do not need to artificially forbid real file names from ending in `>`.
Cranelift doesn't support any 32bit target yet and this helps with keeping everything in sync.
Also stop changing the frame pointer on x86_64. This confuses unwinders.
Riscv support is not currently being tested so it is likely broken. Removing it may avoid confusion in the future.
…er-errors Remove is global hack In attempt to fix rust-lang#114057 we found several issues with how compiler computes layouts, this change removes `is_global` from `and` to stop impl from being shadowed. In depth conversation can be read here https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Getting.20different.20types.20from.20almost.20same.20inputs This is a fix candidate opened for performance run. r? `@lcnr`
Currently the test passes with the LLVM backend as the codegen unit partitioning logic happens to place both the global_asm!() and the function which calls the function defined by the global_asm!() in the same CGU. With the Cranelift backend it breaks however as it will place all assembly in separate codegen units to be passed to an external linker.
Support inline asm on AArch64
Generalizes the small dominators approach from rust-lang#107449.
The optimization is now part of the general implementation.
Update dependencies
I.e. `maybe_uninit_slice` and `new_uninit`. Also sort the remaining features and remove an ugly, low-value comment.
`serialize.rs` has the `Encodable`/`Decodable` impls for lots of basic types, including `Vec`. `collection_impls` has it for lots of collection types. The distinction isn't really meaningful, and it's simpler to have them all in a single file.
By performal initial span extraction in a separate free function, we can remove some accidental complexity from the main generator code.
This enum was mainly needed to track the precise origin of a span in MIR, for debug printing purposes. Since the old debug code was removed in rust-lang#115962, we can replace it with just the span itself.
Suggest labeling block if `break` is in bare block Fix rust-lang#103982.
Instead of defining a named struct, we can use `std::iter::from_fn` and store intermediate state in a closure.
This function already has access to the MIR body, so instead of taking a reference to a terminator, it's simpler and easier to pass in a basic block index. There is no need to box the returned iterator if we instead add appropriate lifetime captures, since `short_circuit_preorder` is now generic over the type of iterator it expects. We can also greatly simplify the function's implementation by observing that the only difference between its two cases is whether we take all of a BB's successors, or just the first one.
…=matthewjasper Improve handling of assertion failures with very long conditions It's not perfectly clear what the best behaviour is here, but I think this is an improvement. r? `@matthewjasper` cc `@m-ou-se`
coverage: Separate initial span extraction from span processing One of the main subtasks of coverage instrumentation is looking through MIR to determine a list of source code spans that require coverage counters. That task is in turn subdivided into a few main steps: - Getting the initial spans from MIR statements/terminators - Processing the list of spans to merge or truncate nearby spans as necessary - Grouping the processed spans by their corresponding coverage graph node --- This PR enforces a firmer separation between the first two steps (span extraction and span processing), which ends up slightly simplifying both steps, since they don't need to deal with state that is only meaningful for the other step. --- `@rustbot` label +A-code-coverage
miri: make NaN generation non-deterministic This implements the [LLVM semantics for NaN generation](https://llvm.org/docs/LangRef.html#behavior-of-floating-point-nan-values). I will soon submit an RFC to make this also officially the Rust semantics, but it has been our de-facto semantics for a long time so there's no reason Miri has to wait for that RFC. This PR just better aligns Miri with codegen. This PR does that just for the operations that have MIR primitives; a future PR will adjust the intrinsics.
use env variable to control thread ids in rustc_log Currently, when parallel rustc is enabled, even if the number of threads is 1, the thread ID will be included before all the logs. E.g. `WARN rustc_mir_build::thir::pattern::const_to_pat ...` => `2:rustcWARN rustc_mir_build::thir::pattern::const_to_pat ...` This makes the logs confusing and results in inconsistent UI test results for serial and parallel rustc. Therefore I think we should let users decide whether thread id information is needed through explicit control.
coverage: Unbox and simplify `bcb_filtered_successors` This is a small cleanup in the coverage instrumentor's graph-building code. --- This function already has access to the MIR body, so instead of taking a reference to a terminator, it's simpler and easier to pass in a basic block index. There is no need to box the returned iterator if we instead add appropriate lifetime captures, and make `short_circuit_preorder` generic over the type of iterator it expects. We can also greatly simplify the function's implementation by observing that the only difference between its two cases is whether we take all of a BB's successors, or just the first one. --- `@rustbot` label +A-code-coverage
-Zmir-enable-passes: document that this may enable unsound passes also add some comments explaining why MIR opts are marked as unsound
…errors reorder files in solve r? `@compiler-errors`
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#116586 (use env variable to control thread ids in rustc_log) - rust-lang#116589 (coverage: Unbox and simplify `bcb_filtered_successors`) - rust-lang#116595 (-Zmir-enable-passes: document that this may enable unsound passes) - rust-lang#116596 (reorder files in solve) r? `@ghost` `@rustbot` modify labels: rollup
…ate-search, r=GuillaumeGomez rustdoc-search: add impl disambiguator to duplicate assoc items Preview (to see the difference, click the link and pay attention to the specific function that comes up): | Before | After | |--|--| | [`simd<i64>, simd<i64> -> simd<i64>`](https://doc.rust-lang.org/nightly/std/?search=simd%3Ci64%3E%2C%20simd%3Ci64%3E%20-%3E%20simd%3Ci64%3E) | [`simd<i64>, simd<i64> -> simd<i64>`](https://notriddle.com/rustdoc-demo-html-3/impl-disambiguate-search/std/index.html?search=simd%3Ci64%3E%2C%20simd%3Ci64%3E%20-%3E%20simd%3Ci64%3E) | | [`cow, vec -> bool`](https://doc.rust-lang.org/nightly/std/?search=cow%2C%20vec%20-%3E%20bool) | [`cow, vec -> bool`](https://notriddle.com/rustdoc-demo-html-3/impl-disambiguate-search/std/index.html?search=cow%2C%20vec%20-%3E%20bool) Helps with rust-lang#90929 This changes the search results, specifically, when there's more than one impl with an associated item with the same name. For example, the search queries `simd<i8> -> simd<i8>` and `simd<i64> -> simd<i64>` don't link to the same function, but most of the functions have the same names. This change should probably be FCP-ed, especially since it adds a new anchor link format for `main.js` to handle, so that URLs like `struct.Vec.html#impl-AsMut<[T]>-for-Vec<T,+A>/method.as_mut` redirect to `struct.Vec.html#method.as_mut-2`. It's a strange design, but there are a few reasons for it: * I'd like to avoid making the HTML bigger. Obviously, fixing this bug is going to add at least a little more data to the search index, but adding more HTML penalises viewers for the benefit of searchers. * Breaking `struct.Vec.html#method.len` would also be a disappointment. On the other hand: * The path-style anchors might be less prone to link rot than the numbered anchors. It's definitely less likely to have URLs that appear to "work", but silently point at the wrong thing. * This commit arranges the path-style anchor to redirect to the numbered anchor. Nothing stops rustdoc from doing the opposite, making path-style anchors the default and redirecting the "legacy" numbered ones. ### The bug On the "Before" links, this example search calls for `i64`:  But if I click any of the results, I get `f64` instead.  The PR fixes this problem by adding enough information to the search result `href` to disambiguate methods with different types but the same name. More detailed description of the problem at: rust-lang#109422 (comment) > When a struct/enum/union has multiple impls with different type parameters, it can have multiple methods that have the same name, but which are on different impls. Besides Simd, [Any](https://doc.rust-lang.org/nightly/std/any/trait.Any.html?search=any%3A%3Adowncast) also demonstrates this pattern. It has three methods named `downcast`, on three different impls. > > When that happens, it presents a challenge in linking to the method. Normally we link like `#method.foo`. When there are multiple `foo`, we number them like `#method.foo`, `#method.foo-1`, `#method.foo-2`, etc. > > It also presents a challenge for our search code. Currently we store all the variants in the index, but don’t have any way to generate unambiguous URLs in the results page, or to distinguish them in the SERP. > > To fix this, we need three things: > > 1. A fragment format that fully specifies the impl type parameters when needed to disambiguate (`#impl-SimdOrd-for-Simd<i64,+LANES>/method.simd_max`) > 2. A search index that stores methods with enough information to disambiguate the impl they were on. > 3. A search results interface that can display multiple methods on the same type with the same name, when appropriate OR a disambiguation landing section on item pages? > > For reviewers: it can be hard to see the new fragment format in action since it immediately gets rewritten to the numbered form.
…n, r=petrochenkov On type error of closure call argument, point at earlier calls that affected inference Mitigate part of rust-lang#71209. When we encounter a type error on a specific argument of a closure call argument, where the closure's definition doesn't have a type specified, look for other calls of the closure to try and find the specific call that cased that argument to be inferred of the expected type. ``` error[E0308]: mismatched types --> $DIR/unboxed-closures-type-mismatch.rs:30:18 | LL | identity(1u16); | -------- ^^^^ expected `u8`, found `u16` | | | arguments to this function are incorrect | note: expected because the closure was earlier called with an argument of type `u8` --> $DIR/unboxed-closures-type-mismatch.rs:29:18 | LL | identity(1u8); | -------- ^^^ expected because this argument is of type `u8` | | | in this closure call note: closure parameter defined here --> $DIR/unboxed-closures-type-mismatch.rs:28:25 | LL | let identity = |x| x; | ^ help: change the type of the numeric literal from `u16` to `u8` | LL | identity(1u8); | ~~ ```
…i-obk add test for const-eval error in dead code during monomorphization
Update docs for mips target tier demotion. These mips targets were demoted in rust-lang#113274, but the documentation was not updated. I have also elected to document this in the release notes for 1.72 because I think that should have been included.
…manieu Mark `new_in` as `const` for BTree collections Discussed in and closes rust-lang/wg-allocators#118
In smir use `FxIndexMap` to store indexed ids Previously we used `vec` for storing indexed types, which is fine for small cases but will lead to huge performance issues when we use `smir` for real world cases. Addresses rust-lang/project-stable-mir#35 r? ``@oli-obk``
Update books ## rust-lang/reference 2 commits in 5262e1c3b43a2c489df8f6717683a44c7a2260fd..142b2ed77d33f37a9973772bd95e6144ed9dce43 2023-10-07 19:41:21 UTC to 2023-09-26 12:26:35 UTC - replace 'UB on raw ptr deref' with UB on place projection/access (rust-lang/reference#1387) - docs: Fix links to ECMA standards in `attributes.md` (rust-lang/reference#1408) ## rust-lang/rust-by-example 11 commits in c954202c1e1720cba5628f99543cc01188c7d6fc..8eb3a01ab74c567b7174784892fb807f2c632d6b 2023-09-26 12:38:17 UTC to 2023-09-26 12:29:10 UTC - fixed a typo in the lifetime.md (rust-lang/rust-by-example#1737) - Misleading textual statement in HOF (rust-lang/rust-by-example#1731) - Equalize title from respective file with title in SUMMARY.md (rust-lang/rust-by-example#1738) - Added explanation for compiling and executing match_args.rs. (rust-lang/rust-by-example#1739) - Wrapped long lines and put #[doc] in backquotes. (rust-lang/rust-by-example#1740) - Update read_lines example to flatten iterator (rust-lang/rust-by-example#1742) - Update while_let.md: address inconsistent use of fn main between 2 co… (rust-lang/rust-by-example#1744) - [TRIVIAL] Remove confusing `also` (rust-lang/rust-by-example#1746) - Fix and extend the explanation of outer vs inner attributes. (rust-lang/rust-by-example#1748) - Fix uncorresponded back quote (rust-lang/rust-by-example#1749) - Fix format in constants.md (rust-lang/rust-by-example#1741) ## rust-lang/rustc-dev-guide 3 commits in a13b7c2..b98af7d 2023-10-05 19:48:35 UTC to 2023-09-27 22:57:27 UTC - update new trait solver docs (rust-lang/rustc-dev-guide#1802) - update rustc_driver examples (rust-lang/rustc-dev-guide#1803) - test headers: fix `compile-flags` example (rust-lang/rustc-dev-guide#1800)
…llaumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#109422 (rustdoc-search: add impl disambiguator to duplicate assoc items) - rust-lang#116250 (On type error of closure call argument, point at earlier calls that affected inference) - rust-lang#116444 (add test for const-eval error in dead code during monomorphization) - rust-lang#116503 (Update docs for mips target tier demotion.) - rust-lang#116559 (Mark `new_in` as `const` for BTree collections) - rust-lang#116560 (In smir use `FxIndexMap` to store indexed ids) - rust-lang#116574 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
Also consider call and yield as MIR SSA. The SSA analysis on MIR only considered `Assign` statements as defining a SSA local. This PR adds assignments as part of a `Call` or `Yield` terminator in that category. This mainly allows to perform CopyProp on a call return place. The only subtlety is in the dominance property: the assignment is only complete at the beginning of the target block.
drahnr
force-pushed
the
bernhard-issue_116539
branch
from
10a1f5b to
6bd7b71
Compare
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.
WIP