Strengthen state tracking in const-prop
Some/many of the changes are replicated between both the const-prop lint and the const-prop optimization.
Behaviour changes:
- const-prop opt does not give a span to propagated values. This was useless as that span's primary purpose is to diagnose evaluation failure in codegen.
- we remove the `OnlyPropagateInto` mode. It was only used for function arguments, which are better modeled by a write before entry.
- the tracking of assignments and discriminants make clearer that we do nothing in `NoPropagation` mode or on indirect places.
Rollup of 8 pull requests
Successful merges:
- #108651 (Forbid the use of `#[target_feature]` on `main`)
- #109009 (rustdoc: use restricted Damerau-Levenshtein distance for search)
- #109026 (Introduce `Rc::into_inner`, as a parallel to `Arc::into_inner`)
- #109029 (Gate usages of `dyn*` and const closures in macros)
- #109031 (Rename `config.toml.example` to `config.example.toml`)
- #109032 (Use `TyCtxt::trait_solver_next` in some places)
- #109047 (typo)
- #109052 (Add eslint check for rustdoc-gui tester)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Rename `config.toml.example` to `config.example.toml`
This had bothered me for a while as it leads to bad (missing) syntax highlighting in most editors I've used, and `@jyn514` suggested I just make the change and that the compatibility concerns I had don't really matter.
I suspect it will be a contentious one, so will not be offended if the outcome of this is to close the PR.
Gate usages of `dyn*` and const closures in macros
We silently accepted `dyn*` and const closures in macros as long as they didn't expand to anything containing these experimental features, unlike other gated features such as `for<'a>` binders on closures, etc. Let's not do that, to make sure nobody begins relying on this.
Introduce `Rc::into_inner`, as a parallel to `Arc::into_inner`
Unlike `Arc`, `Rc` doesn't have the same race condition to avoid, but
maintaining an equivalent API still makes it easier to work with both
`Rc` and `Arc`.
rustdoc: use restricted Damerau-Levenshtein distance for search
Based on https://github.com/rust-lang/rust/pull/108200, for the same rationale.
> This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a restricted implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
Before this change, searching [`prinltn!`] listed `print!` first, followed by `println!`. With this change, `println!` matches more closely.
[`prinltn!`]: https://doc.rust-lang.org/nightly/std/?search=prinltn!
Check that a query has not completed and is not executing before starting it
This fixes a race in the query system where we only checked if the query was currently executing, but not if it was already completed, causing queries to re-execute.
r? `@cjgillot`
Ensure value is on the on-disk cache before returning from `ensure()`.
The current logic for `ensure()` a query just checks that the node is green in the dependency graph.
However, a lot of places use `ensure()` to prevent the query from being called later. This is the case before stealing a query result.
If the query is actually green but the value is not available in the on-disk cache, `ensure` would return, but a subsequent call to the full query would run the code, and attempt to read from a stolen value.
This PR conforms the query system to the usage by checking whether the queried value is loadable from disk before returning.
Sadly, I can't manage to craft a proper test...
Should fix all instances of "attempted to read from stolen value".
Rollup of 9 pull requests
Successful merges:
- #108726 (tidy: enforce comment blocks to have an even number of backticks)
- #108797 (Allow binary files to go through the `FileLoader`)
- #108841 (Add suggestion to diagnostic when user has array but trait wants slice. (rebased))
- #108984 (bootstrap: document tidy)
- #109013 (Give proper error message when tcx wasn't passed to decoder)
- #109017 (remove duplicated calls to sort_string)
- #109018 (Expand on the allocator comment in `rustc-main`)
- #109028 (Add eslint checks for rustdoc-js tester)
- #109034 (Commit some tests for the new solver + lazy norm)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Commit some tests for the new solver + lazy norm
Also consolidate `typeck/lazy-norm` into `traits/new-solver`, since it's not really useful to maintain a distinction, like when a test really is due to "lazy norm" or "the new solver" (usually both!)
Give proper error message when tcx wasn't passed to decoder
I hit this yesterday and found it very confusing, even though the solution to the problem is very simple.
bootstrap: document tidy
Enable documentation of tidy, as suggested in #106803. Jyn mentioned they should probably be added to `doc.rust-lang.org`, how should that be done?
Add suggestion to diagnostic when user has array but trait wants slice. (rebased)
Rebase of #91314, except for change to multipart suggestion
Resolves#90528
r? ``@compiler-errors`` since you requested the multipart suggestion
Allow binary files to go through the `FileLoader`
I'd like for `include_bytes!` to go through the `FileLoader` in an out-of-tree `rustc_driver` wrapper, and I can't find a reason it's not already done. It seems like most folks providing a custom `FileLoader` would want this too, so I added it.
I can solve my problem in other ways if there's a strong reason not to do it, but it seems simple and harmless.
