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`
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
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.
Rename tests/ui/unique to tests/ui/box/unit
fixes https://github.com/rust-lang/rust/issues/109878
Since tests/ui/box already exists, I have temporarily named it boxed-box, but if another name sounds better, please let me know.
Initial support for loongarch64-unknown-linux-gnu
Hi, We hope to add a new port in rust for LoongArch.
LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).
Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.
Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html
Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
Update browser-ui-test version
This update add the support for expressions, so we can now do this:
```
assert: 1 > 2 && ["a"] != ["b", "c"]
```
It also improved commands naming and updated puppeteer version.
r? `@notriddle`
Migrate most of `rustc_builtin_macros` to diagnostic impls
cc #100717
This is a couple of days work, but I decided to stop for now before the PR becomes too big. There's around 50 unresolved failures when `rustc::untranslatable_diagnostic` is denied, which I'll finish addressing once this PR goes thtough
A couple of outputs have changed, but in all instances I think the changes are an improvement/are more consistent with other diagnostics (although I'm happy to revert any which seem worse)
rustc_metadata: Filter encoded data more aggressively using `DefKind`
I focused on data that contains spans, because spans are expensive to encode/decode/hash, but also touched `should_encode_visibility` too.
One incorrect use of impl visibility in diagnostics is also replaced with trait visibility.
These don't optimize with debug assertions. For one of them, this
is due to the new alignment checks, for the other I'm not sure
what specifically blocks it.
this test was added for rust 0.4 and doesn't test anything specific.
The repro originally relied on extern functions which are now just
ordinary methods. It's also a run pass test even though `main` has
been commented out.
Rollup of 8 pull requests
Successful merges:
- #109527 (Set up standard library path substitution in rust-gdb and gdbgui)
- #109752 (Stall auto trait assembly in new solver for int/float vars)
- #109860 (Add support for RISC-V relax target feature)
- #109923 (Update `error [E0449]: unnecessary visibility qualifier` to be more clear)
- #110070 (The `wrapping_neg` example for unsigned types shouldn't use `i8`)
- #110146 (fix(doc): do not parse inline when output is json for external crate)
- #110147 (Add regression test for #104916)
- #110149 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #104916Closes#104916
I haven't tested if it still passes with debug assertions enabled so it'd be better to wait for CI to be green.
r? compiler-errors
Update `error [E0449]: unnecessary visibility qualifier` to be more clear
This updates the error message `error[E0449]: unnecessary visibility qualifier` by clearly indicating that visibility qualifiers already inherit their visibility from a parent item. The error message previously implied that the qualifiers were permitted, which is not the case anymore.
Resolves#109822.
We store argument indexes on VarDebugInfo. Unlike the previous method of
relying on the variable index to know whether a variable is an argument,
this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope.
When a function gets inlined, the arguments to the inner function will
no longer be in the outermost scope. What we care about though is
whether they were in the outermost scope prior to inlining, which we
know by whether we assigned an argument index.
Add suggestion to remove `derive()` if invoked macro is non-derive
Adds to the existing `expected derive macro, found {}` error message:
```
help: remove the surrounding "derive()":
--> $DIR/macro-path-prelude-fail-4.rs:1:3
|
LL | #[derive(inline)]
| ^^^^^^^ ^
```
This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`?
Closes#109589
Fix a couple ICEs in the new `CastKind::Transmute` code
Check the sizes of the immediates, rather than the overall types, when deciding whether we can convert types without going through memory.
Fixes#110005Fixes#109992Fixes#110032
cc `@matthiaskrgr`
Migrate remainder of rustc_ty_utils to `SessionDiagnostic`
This moves the remaining errors in `rust_ty_utils` to `SessionsDiagnostic`.
r? ``@davidtwco``
Instantiate instead of erasing binder when probing param methods
Fixes#108836
There is a really old comment saying that a `WhereClauseCandidate` probe candidate "should not contain any inference variables", but I'm not really confident that that comment applies anymore. In contrast, other candidates that we assemble during method probe contain inference variables in their substitutions (e.g. `InherentImplCandidate`)...
Since this change is made only to support a nightly feature, I'm happy to gate the new behavior behind this feature flag or discuss it further.
r? types
Better diagnostic when pattern matching tuple structs
Fixes#108284
When trying to pattern match a tuple struct we might get a flawed error message if there are missing fields. E.g.
```
let x = Foo(100, 200);
if let Foo { 0: bar } = x { ... }
```
Produces this error:
```
error[E0769]: tuple variant `Foo` written as struct variant
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^
|
help: use the tuple variant pattern syntax instead
|
5 | if let Foo(_, _) = x {
| ~~~~~~
```
Which doesn't highlight that we can still use the struct syntax but we need to fill missing fields. This pr changes this error to:
```
error[E0027]: pattern does not mention field `1`
--> hello.rs:5:12
|
5 | if let Foo { 0: foo } = x {
| ^^^^^^^^^^^^^^ missing field `1`
|
help: include the missing field in the pattern
|
5 | if let Foo { 0: foo, 1: _ } = x {
| ~~~~~~~~
help: if you don't care about this missing field, you can explicitly ignore it
|
5 | if let Foo { 0: foo, .. } = x {
| ~~~~~~
```
Suggest defining const parameter when appropriate
Helps a bit with #91119.
Following #105523's lead, I use placeholder `/* Type */` instead of `_` in the suggestion.
It should be easier for newcomers to parse.
`@rustbot` label A-diagnostics
r? diagnostics
Enforce that `PointerLike` requires a pointer-like ABI
At least temporarily, let's ban coercing things that are pointer-sized and pointer-aligned but *not* `Abi::Scalar(..)` into `dyn*`. See: https://github.com/rust-lang/rust/pull/104694#discussion_r1142522073
This can be lifted in the future if we decie that we *want* to be able to coerce something `repr(C)` into a `dyn*`, but we'll have to figure out what to do with Miri and codegen...
r? compiler
Add ability to transmute (somewhat) with generic consts in arrays
Previously if the expression contained generic consts and did not have a directly equivalent type, transmuting the type in this way was forbidden, despite the two sizes being identical. Instead, we should be able to lazily tell if the two consts are identical, and if so allow them to be transmuted.
This is done by normalizing the forms of expressions into sorted order of multiplied terms, which is not generic over all expressions, but should handle most cases.
This allows for some _basic_ transmutations between types that are equivalent in size without requiring additional stack space at runtime.
I only see one other location at which `SizeSkeleton` is being used, and it checks for equality so this shouldn't affect anywhere else that I can tell.
See [this Stackoverflow post](https://stackoverflow.com/questions/73085012/transmute-nested-const-generic-array-rust) for what was previously necessary to convert between types. This PR makes converting nested `T -> [T; 1]` transmutes possible, and `[uB*2; N] -> [uB; N * 2]` possible as well.
I'm not sure whether this is something that would be wanted, and if it is it definitely should not be insta-stable, so I'd add a feature gate.
More descriptive error when qself path doesnt have a trait on the RHS of `as`
`<Ty as Enum>::Assoc` should report that `Enum` is a trait. Main question is whether to eagerly report the error, or raise it with `return Err(..)` -- i'll note that in an inline comment though.
cc `@GuillaumeGomez` who said this came up at a Paris Rust meetup.
r? `@petrochenkov`
Inline try_from and try_into
To avoid link time dependency between core and compiler-builtins, when using opt-level that implicitly enables -Zshare-generics.
While compiler-builtins should be compiled with -Zshare-generics disabled, the -Zbuild-std does not ensure this at the moment.
r? `@bjorn3`
Refactor unwind in MIR
This makes unwinding from current `Option<BasicBlock>` into
```rust
enum UnwindAction {
Continue,
Cleanup(BasicBlock),
Unreachable,
Terminate,
}
```
cc `@JakobDegen` `@RalfJung` `@Amanieu`
migrate rustc_macros to syn 2.0
WIP at this point since I need to work on migrating the code that heavily uses `NestedMeta` for parsing. Perhaps a full refactor would be nice..
Label `non_exhaustive` attribute on privacy errors from non-local items
Label when an ADT is `non_exhaustive` and we get a privacy error, help with confusion in a case like this:
```rust
#[non_exhaustive]
pub struct Foo;
// other crate
let x = Foo;
//~^ ERROR unit struct `Foo` is private
```
diagnostics: account for self type when looking for source of unsolved type variable
Fixes#109905.
When searching for the source of an unsolved infer var inside of a list of generic args, we look through the `tcx.generics_of(…).own_substs(…)` which *skips* the self type if present. However, the computed `argument_index` is later[^1] used to index into `tcx.generics_of(…).params` which may still contain the self type. In such case, we are off by one when indexing into the parameters.
From now on, we account for this immediately after calling `own_substs` which keeps things local.
This also fixes the wrong output in the preexisting UI test `inference/need_type_info/concrete-impl.rs` which was overlooked. It used to claim that the *type of type parameter `Self`* couldn't be inferred in `<Struct as Ambiguous<_>>::method()` which of course isn't true: `Self` equals `Struct` here, `A` couldn't be inferred.
`@rustbot` label A-diagnostics
[^1]: f98a271814/compiler/rustc_infer/src/infer/error_reporting/need_type_info.rs (L471)
Implement support for `GeneratorWitnessMIR` in new solver
r? ```@cjgillot```
I mostly want this to cut down the number of failing UI tests when running the UI test suite with `--compare-mode=next-solver`, but there doesn't seem like much reason to block implementing this since it adds minimal complexity to the existing structural traits impl in the new solver.
If others are against adding this for some reason, then maybe we should just make `GeneratorWitnessMIR` return `NoSolution` for these traits. Anything but an ICE please 😸🧊
Check pattern refutability on THIR
The current `check_match` query is based on HIR, but partially re-lowers HIR into THIR.
This PR proposed to use the results of the `thir_body` query to check matches, instead of re-building THIR.
Most of the diagnostic changes are spans getting shorter, or commas/semicolons not getting removed.
This PR degrades the diagnostic for confusing constants in patterns (`let A = foo()` where `A` resolves to a `const A` somewhere): it does not point ot the definition of `const A` any more.
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes#105777
r? `@eholk`
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
Tweak debug outputs to make debugging new solver easier
1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs.
For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output).
For canonicalized things, I typically care more about what is *being* canonicalized.
For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not...
2. Add some more debug and instrument calls to functions to add more structure to tracing lines.
r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
Allow `transmute`s to produce `OperandValue`s instead of needing `alloca`s
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
Do not suppress temporary_cstring_as_ptr in macros.
There isn't really a reason to skip the lint when part of the expression comes from an expansion.
Fixes https://github.com/rust-lang/rust/issues/94694
