Handle discriminant in DataflowConstProp
cc ``@jachris``
r? ``@JakobDegen``
This PR attempts to extend the DataflowConstProp pass to handle propagation of discriminants. We handle this by adding 2 new variants to `TrackElem`: `TrackElem::Variant` for enum variants and `TrackElem::Discriminant` for the enum discriminant pseudo-place.
The difficulty is that the enum discriminant and enum variants may alias each another. This is the issue of the `Option<NonZeroUsize>` test, which is the equivalent of https://github.com/rust-lang/unsafe-code-guidelines/issues/84 with a direct write.
To handle that, we generalize the flood process to flood all the potentially aliasing places. In particular:
- any write to `(PLACE as Variant)`, either direct or through a projection, floods `(PLACE as OtherVariant)` for all other variants and `discriminant(PLACE)`;
- `SetDiscriminant(PLACE)` floods `(PLACE as Variant)` for each variant.
This implies that flooding is not hierarchical any more, and that an assignment to a non-tracked place may need to flood a tracked place. This is handled by `for_each_aliasing_place` which generalizes `preorder_invoke`.
As we deaggregate enums by putting `SetDiscriminant` last, this allows to propagate the value of the discriminant.
This refactor will allow to make https://github.com/rust-lang/rust/pull/107009 able to handle discriminants too.
Suggest the correct array length on mismatch
Fixes#107156
I wasn't able to find a way to get the `Span` for the actual array size unfortunately, so this suggestion can't be applied automatically.
``@rustbot`` label +A-diagnostics
rework min_choice algorithm of member constraints
See [this comment](https://github.com/rust-lang/rust/pull/105300#issuecomment-1384312743) for the description of the new algorithm.
Fixes#63033Fixes#104639
This uses a more general algorithm than #89056 that doesn't treat `'static` as a special case. It thus accepts more code. For example:
```rust
async fn test2<'s>(_: &'s u8, _: &'_ &'s u8, _: &'_ &'s u8) {}
```
I claim it's more correct as well because it fixes#104639.
cc ``@nikomatsakis`` ``@lqd`` ``@tmandry`` ``@eholk`` ``@chenyukang`` ``@oli-obk``
r? types
interpret: rename Pointer::from_addr → from_addr_invalid
This function corresponds to `ptr::invalid` in the standard library; the previous name was not clear enough IMO.
Use derive attributes for uninteresting traversals
It appears that visiting and folding was implemented on `BitMatrix` solely so that the derive macros could be used on `GeneratorLayout`, however such implementation would not necessarily be correct for other uses (if there were any). Adding attributes to the derive macro is more correct and potentially more generally useful.
r? ``@oli-obk``
Refactor refcounted structural_impls via functors
The mapping of values in refcounted types can be extracted as a functor, simplifying the implementations in the type library (whose structural folding impls now all use such functors). This functor could also prove more generally useful elsewhere.
add an unstable `#[rustc_coinductive]` attribute
useful to test coinduction, especially in the new solver.
as this attribute should remain permanently unstable I don't think this needs any official approval. cc ``@rust-lang/types``
had to weaken the check for stable query results in the solver to prevent an ICE if there's a coinductive cycle with constraints.
r? ``@compiler-errors``
Store metrics from `metrics.json` to CI PGO timer
With this change, we'll be able to easily see how long does it take to compile LLVM vs `rustc`.
r? ```@Mark-Simulacrum```
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
Rollup of 10 pull requests
Successful merges:
- #103478 ( Suggest fix for misplaced generic params on fn item #103366 )
- #107739 (Check for overflow in evaluate_canonical_goal)
- #108003 (Avoid ICE when the generic_span is empty)
- #108016 ("Basic usage" is redundant for there is just one example)
- #108023 (Shrink size of array benchmarks)
- #108024 (add message to update Cargo.toml when x is changed)
- #108025 (rustdoc: add more tooltips to intra-doc links)
- #108029 (s/eval_usize/eval_target_usize/ for clarity)
- #108035 (Avoid using a dead email address as the main email address)
- #108038 (Remove needless supertrait constraints from Interner projections)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove needless supertrait constraints from Interner projections
These associated types are already all constrained to implement `Ord`, so specifically requiring its supertraits `Eq`, `PartialEq` and `PartialOrd` is superfluous.
Avoid using a dead email address as the main email address
This caused highfive to welcome me as a new contributor on every PR, because it couldn't find any commits of mine.
Suggest fix for misplaced generic params on fn item #103366fixes#103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
This commit makes intra-doc link tooltips consistent with generated
links in function signatures and item tables, with the format
`itemtype foo::bar::baz`. This way, you can tell if a link points at
a trait or a type (for example) by mousing over it.
See also fce944d4e7
Update cargo
10 commits in 82c3bb79e3a19a5164e33819ef81bfc2c984bc56..39c13e67a5962466cc7253d41bc1099bbcb224c3 2023-02-04 22:52:16 +0000 to 2023-02-12 02:01:08 +0000
- chore: Update to toml v0.6, toml_edit v0.18 (rust-lang/cargo#11618)
- doc: more doc comments and intra-doc links (rust-lang/cargo#11703)
- Deny warnings in CI, not locally (rust-lang/cargo#11699)
- add comment to lto.rs (rust-lang/cargo#11701)
- Re-export cargo_new::NewProjectKind as public (rust-lang/cargo#11700)
- Add '-C' flag for changing current dir before build (rust-lang/cargo#10952)
- `-Zrustdoc-scrape-example` must fail with bad build script (rust-lang/cargo#11694)
- Update CHANGELOG for 1.68 backports (rust-lang/cargo#11690)
- Update 1password to the version 2 CLI (rust-lang/cargo#11692)
- chore: autolabel more for `A-*` (rust-lang/cargo#11679)
r? `@ghost`
Rollup of 8 pull requests
Successful merges:
- #107902 (fix: improve the suggestion on future not awaited)
- #107913 (Update broken link in cargo style guide)
- #107942 (Tighter spans for bad inherent `impl` self types)
- #107948 (Allow shortcuts to directories to be used for ./x.py fmt)
- #107971 (Clearly document intentional UB in mir-opt tests)
- #107985 (Added another error to be processed in fallback)
- #108002 (Update books)
- #108013 (rustdoc: use a string with one-character codes for search index types)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Added another error to be processed in fallback
This pull request addresses the problem of Rust not being able to read file/directory metadata because the current user doesn't have permission to read the file and are thus inaccessible.
One particular example is `System Volume Information`. But any example can be made by having a file/directory, which the current user can't access even though the system does allow to view the metadata, which is handled by the fallback.
The fallback exists to get the metadata but it was limited to one error type. Having added ERROR_ACCESS_DENIED per Chris Denton's suggestion, file/directory properties are now properly read.
Solution suggested by Chris Denton https://github.com/nushell/nushell/issues/6857#issuecomment-1426847135
Clearly document intentional UB in mir-opt tests
All of the changed mir-opt test input files did not pass Miri. Now they do.
r? `@cjgillot` because there's a CopyProp test in here that I do not fully understand
