| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
remove duplicated calls to sort_string
`with_forced_trimmed_paths!` was removed in https://github.com/rust-lang/rust/commit/62ba3e70a1f01d801d068b84a097e38bd82a8c6e, and this lines became dups.
|
|
tidy: enforce comment blocks to have an even number of backticks
After PR #108694, most unmatched backticks in `compiler/` comments have been eliminated. This PR adds a tidy lint to ensure no new unmatched backticks are added, and either addresses the lint in the remaining instances it found, or allows it.
Very often, backtick containing sections wrap around lines, for example:
```Rust
// This function takes a tuple `(Vec<String>,
// Box<[u8]>)` and transforms it into `Vec<u8>`.
```
The lint is implemented to work on top of blocks, counting each line with a `//` into a block, and counting if there are an odd or even number of backticks in the entire block, instead of looking at just a single line.
|
|
Avoid unnecessary hashing
I noticed some stable hashing being done in a non-incremental build. It turns out that some of this is necessary to compute the crate hash, but some of it is not. Removing the unnecessary hashing is a perf win.
r? `@cjgillot`
|
|
Simplify message paths
This makes it easier to open the messages file. Right now I have to first click on the `locales` dir to open it, and then on the `en-US.ftl` file. `Cargo.toml` and `build.rs` files are also in the top level, and I think there should not be more than one file, so a directory isn't really needed. The [chosen strategy for pontoon adoption](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/pontoon.20and.20next.20steps) is out of tree. Even if this descision is changed in the future, the `messages.ftl` approach is also compatible with non-english translations living in-tree, as long as the non-english translations don't live in the `compiler/rustc_foo/` directories but in different ones. That would also be helpful for grepability purposes.
The commit was the result of automated changes:
```
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
```
r? `@davidtwco`
|
|
Make RPITITs simple cases work when using lower_impl_trait_in_trait_to_assoc_ty
r? `@compiler-errors`
It's probably best reviewed commit by commit.
|
|
|
|
|
|
This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
|
|
|
|
Querify register_tools and post-expansion early lints
The 2 extra queries correspond to code that happen before and after macro expansion, and don't need the resolver to exist.
|
|
Place size limits on query keys and values
This just prevents these from growing accidentally too large. I'm not sure if there's an easy way to also print the actual size too.
|
|
Implement goal caching with the new solver
Maybe it's wrong, idk. Opening mostly for first impressions before I go to sleep.
r? ``@lcnr,`` cc ``@cjgillot``
|
|
|
|
|
|
|
|
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes #108781
|
|
Emit alias-eq when equating numeric var and projection
This doesn't fix everything having to do with projections and infer vars, but it does fix a common case I saw in HIR typeck.
r? `@lcnr`
|
|
Introduce a no-op `PlaceMention` statement for `let _ =`.
Fixes https://github.com/rust-lang/rust/issues/54003
Fixes https://github.com/rust-lang/rust/issues/80059
Split from https://github.com/rust-lang/rust/pull/101500
This PR introduces a new `PlaceMention` statement dedicated to matches that neither introduce bindings nor ascribe types. Without this, all traces of the match would vanish from MIR, making it impossible to diagnose unsafety or use in #101500.
This allows to mark `let _ = <unsafe union access or dereference>` as requiring an unsafe block.
Nominating for lang team, as this introduces an extra error.
|
|
|
|
|
|
|
|
|
|
Place binder correctly for arbitrary trait bound suggestion
suggest `for<'a> &'a T: Trait` instead of `&'a T: for<'a> T`.
|
|
Remove DropAndReplace terminator
#107844 made DropAndReplace unused, let's remove it completely from the codebase.
|
|
always resolve to universal regions if possible
`RegionConstraintCollector::opportunistic_resolve_var`, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated `'static == '1 == '2`, it doesn't resolve `'1` or `'2` to `'static`. Now it does!
Addresses review comment https://github.com/rust-lang/rust/pull/107376#discussion_r1093233687.
r? `@lcnr`
|
|
In case a variable is unified with two universal regions from different
universes, use the one with the lower universe as it has a higher chance
of being compatible with the variable.
|
|
|
|
Do not implement HashStable for HashSet (MCP 533)
This PR removes all occurrences of `HashSet` in query results, replacing it either with `FxIndexSet` or with `UnordSet`, and then removes the `HashStable` implementation of `HashSet`. This is part of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533), that is, removing the `HashStable` implementations of all collection types with unstable iteration order.
The changes are mostly mechanical. The only place where additional sorting is happening is in Miri's override implementation of the `exported_symbols` query.
|
|
The crate hash is needed:
- if debug assertions are enabled, or
- if incr. comp. is enabled, or
- if metadata is being generated, or
- if `-C instrumentation-coverage` is enabled.
This commit avoids computing the crate hash when these conditions are
all false, such as when doing a release build of a binary crate.
It uses `Option` to store the hashes when needed, rather than
computing them on demand, because some of them are needed in multiple
places and computing them on demand would make compilation slower.
The commit also removes `Owner::hash_without_bodies`. There is no
benefit to pre-computing that one, it can just be done in the normal
fashion.
|
|
PR 107844 made DropAndReplace unused, let's remove it completely
from the codebase.
|
|
fix multiple issues when promoting type-test subject
Multiple interdependent fixes. See linked issues for a short description of each.
When Promoting a type-test `T: 'a` from within the closure back to its parent function, there are a couple pre-existing bugs and limitations. They were exposed by the recent changes to opaque types because the type-test subject (`T`) is no longer a simple ParamTy.
Commit 1:
Fixes #108635
Fixes #107426
Commit 2:
Fixes #108639
Commit 3:
Fixes #107516
|
|
|
|
|
|
|
|
sess.opts.unstable_opts
|
|
|
|
|
|
Improve documentation and argument naming of some TyCtxt methods
I got bit by this recently so better prevent others to end up the same as me.
|
|
|
|
rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
|
|
Rollup of 6 pull requests
Successful merges:
- #108298 (Fix ICE: check if snippet is `)`)
- #108405 (Lazily compute crate name for consider_optimizing)
- #108656 (Rustdoc search: Emit an error for unclosed generic)
- #108660 (Remove ne implementations from strings)
- #108669 (Allow checking whether a type allows being uninitialized)
- #108727 (rustc_expand: make proc-macro derive error translatable)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Allow checking whether a type allows being uninitialized
This is useful for clippy ([rust-lang/clippy#10407](https://github.com/rust-lang/rust-clippy/issues/10407)) and for the future `MaybeUninit::assume_init` panics (#100423).
|
|
r=WaffleLapkin
Lazily compute crate name for consider_optimizing
The extra query is unnecessary in the common case of not having fuel.
|
|
Remove `NormalizationError::ConstantKind`
No longer in use by `TryNormalizeAfterErasingRegionsFolder` (as of #102355 / e8150fa60cc445de7a57db634deb0668880be593 it seems). It's making `LayoutError`, etc. kinda large -- that was noticed by `@zoxc.`
|
|
|
|
|
