Fixes the desktop scrolling weirdness mentioned in
https://github.com/rust-lang/rust/pull/98775#issuecomment-1182575603
As described in the MDN page for this property:
* The current Firefox ESR is 102, and the first Firefox version
to support this feature is 59.
* The current Chrome version 112, and the first version to support
this is 63.
* Edge is described as having a minor bug in `none` mode, but we
use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to
add this feature, and is also the oldest version we officially
support.
This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.
Custom MIR: Support `BinOp::Offset`
Since offset doesn't have an infix operator, a new function `Offset` is added which is lowered to `Rvalue::BinaryOp(BinOp::Offset, ..)`
r? ```@oli-obk``` or ```@tmiasko``` or ```@JakobDegen```
Fix transmute intrinsic mir validation ICE
I stumbled across this at work, the minimal reproducer is included as a test which ICEs before this change.
I'm not 100% sure this is the right fix, but it matches what we do in `mir_assign_valid_types` so seems reasonable at least.
fixes#110151
r? `@lcnr` since they've been keeping the relevant logic correct, cc `@scottmcm`
Instead of repeating the same logic by walking HIR during metadata encoding.
The only difference is that we are no longer encoding `macro_rules` items, but we never currently need them as a part of this list.
They can be encoded separately if this need ever arises.
`module_reexports` is also un-querified, because I don't see any reasons to make it a query, only overhead.
incr.comp.: Make sure dependencies are recorded when feeding queries during eval-always queries.
This PR makes sure we don't drop dependency edges when feeding queries during an eval-always query.
Background: During eval-always queries, no dependencies are recorded because the system knows to unconditionally re-evaluate them regardless of any actual dependencies. This works fine for these queries themselves but leads to a problem when feeding other queries: When queries are fed, we set up their dependency edges by copying the current set of dependencies of the feeding query. But because this set is empty for eval-always queries, we record no edges at all -- which has the effect that the fed query instances always look "green" to the system, although they should always be "red".
The fix is to explicitly add a dependency on the artificial "always red" dep-node when feeding during eval-always queries.
Fixes https://github.com/rust-lang/rust/issues/108481
Maybe also fixes issue https://github.com/rust-lang/rust/issues/88488.
cc `@jyn514`
r? `@cjgillot` or `@oli-obk`
Adds a link to the relevant part of The Rust Reference in the eror
message, and suggests a possible fix (replacing the fragment specifier
with :tt in the macro definition).
Fixes typos in the original message.
Signed-off-by: Lena Milizé <me@lvmn.org>
Split implied and super predicate queries, then allow elaborator to filter only supertraits
Split the `super_predicates_of` query into a new `implied_predicates_of` query. The former now only returns the *real* supertraits of a trait alias, and the latter now returns the implied predicates (which include all of the `where` clauses of the trait alias). The behavior of these queries is identical for regular traits.
Now that the two queries are split, we can add a new filter method to the elaborator, `filter_only_self()`, which can be used in instances that we need only the *supertrait* predicates, such as during the elaboration used in closure signature deduction. This toggles the usage of `super_predicates_of` instead of `implied_predicates_of` during elaboration of a trait predicate.
This supersedes #104745, and fixes the four independent bugs identified in that PR.
Fixes#104719Fixes#106238Fixes#110023Fixes#109514
r? types
- require `TypeErrCtxt` to always result in an error
- move `resolve_regions_and_report_errors` to the `ObligationCtxt`
- merge `process_registered_region_obligations` into `resolve_regions`
rustdoc: remove redundant expandSection code from main.js
This functionality is already tested in `hash-item-expansion.goml`, and was implemented twice:
* First, in code that ran at load time and at hash change: 917cdd295d2eed213c135d6f984c650f016ee3d6
* Later, the hash change event handler was itself run at load time, and the code handling both cases diverged in implementation, though their behavior still matches pretty well: f66a331335f3ac931afabca6f927a9d7dc17db3e
Support safe transmute in new solver
Basically copies the same implementation as the old solver, but instead of looking for param types, we look for type or const placeholders.
Fix `x test ui --target foo` when download-rustc is enabled
Previously, we would never build the target std, only the host std:
```
; x t tests/ui/attributes --target wasm32-unknown-unknown
Building bootstrap
Finished dev [unoptimized] target(s) in 0.02s
Building stage0 library artifacts (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.08s
Building tool compiletest (stage0)
Finished release [optimized] target(s) in 0.09s
Check compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu -> wasm32-unknown-unknown)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { depth: 0, inner: Io { path: Some("/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/wasm32-unknown-unknown/lib"), err: Os { code: 2, kind: NotFound, message: "No such file or directory" } } }', src/tools/compiletest/src/main.rs:842:31
```
Helps with https://github.com/rust-lang/rust/issues/81930.
