| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Make `ty::Error` implement all auto traits
I have no idea what's up with the crashes test I fixed--I really don't want to look into it since it has to do something with borrowck and multiple layers of opaques. I think the underlying idea of allowing error types to implement all auto traits is justified though.
Fixes #134796
Fixes #131050
r? lcnr
|
|
Add a compiler intrinsic to back `bigint_helper_methods`
cc https://github.com/rust-lang/rust/issues/85532
This adds a new `carrying_mul_add` intrinsic, to implement `wide_mul` and `carrying_mul`.
It has fallback MIR for all types -- including `u128`, which isn't currently supported on nightly -- so that it'll continue to work on all backends, including CTFE.
Then it's overridden in `cg_llvm` to use wider intermediate types, including `i256` for `u128::carrying_mul`.
|
|
|
|
r=GuillaumeGomez
rustdoc: use shorter paths as preferred canonical paths
This is a solution to [the `std::sync::poison` linking problem](https://github.com/rust-lang/rust/pull/134692#issuecomment-2560373308), and, in general, makes intra-doc links shorter and clearer.
> Done. This helped with the search, but not with the things like `MutexGuard`'s doc's reference to `Mutex::lock` being converted to the absolute (unstable) `std::sync::poison::Mutex` path.
cc `@tgross35`
r? `@GuillaumeGomez`
|
|
Spruce up the docs of several queries related to the type/trait system and const eval
- Editorial
- Proper rustdoc summary/synopsis line by making use of extra paragraphs: Leads to better rendered output on module pages, in search result lists and overall, too
- Use rustdoc warning blocks for admonitions of the form "do not call / avoid calling this query directly"
- Use intra-doc links of the form ``[`Self::$query`]`` to cross-link queries. Indeed, such links are generally a bit brittle due to the existence of `TyCtxtFeed` which only contains a subset of queries. Therefore the docs of `feedable` queries cannot cross-link to non-`feedable` ones. I'd say it's fine to use intra-doc links despite the potential/unlikely occasional future breakage (if a query with the aforementioned characteristics becomes `feedable`). `Self::` is nicer than `TyCtxt::` (which would be more stable) since it accounts for other contexts like `TyCtxt{Feed,At,Ensure{,WithValue}}`
- Informative
- Generally add, flesh out and correct some doc comments
- Add *Panic* sections (to a few selected queries only). The lists of panics aren't necessarily exhaustive and focus on the more "obvious" or "important" panics.
- Where applicable add a paragraph calling attention to the relevant [`#[rustc_*]` TEST attribute](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes)
The one non-doc change (it's internal and not observable):
Be even more defensive in `query constness`'s impl (spiritual follow-up to #134122) (see self review comment).
Fixes #133494.
r\? **any**(compiler-errors, oli-obk)
|
|
compiletest: Remove the `-test` suffix from normalize directives
This suffix was an artifact of using the same condition-checking engine as the `ignore-*` and `only-*` directives, but in practice we have only 2 tests that legitimately use a condition, and both of them only care about 32-bit vs 64-bit.
This PR detaches `normalize-*` directives from the condition checker, and replaces it with a much simpler system of four explicit `NormalizeKind` values. It then takes advantage of that simplicity to get rid of the `-test` suffix.
---
Addresses one of the points of #126372.
The new name-checking code is a bit quaint, but I think it's a definite improvement over the status quo.
---
The corresponding dev-guide update is https://github.com/rust-lang/rustc-dev-guide/pull/2172.
r? jieyouxu
|
|
const eval
|
|
|
|
[macro_metavar_expr_concat] Fix #128346
Fix #128346
Fix #131393
The syntax is invalid in both issues so I guess that theoretically the compiler should have aborted early.
This PR tries to fix a local problem but let me know if there are better options.
cc `@petrochenkov` if you are interested
|
|
|
|
|
|
This is a solution to the `std::sync::poison` linking problem,
and, in general, makes intra-doc links shorter and clearer.
|
|
|
|
Add more `begin_panic` normalizations to panic backtrace tests
Since #123244, these tests have started failing locally on some systems (#133997) due to minor variations in how `begin_panic` is printed in the backtrace.
The variation appears to occur on macOS when `rust.debuginfo-level = "line-tables-only"` is set, which is the default in `config.compiler.toml`. It does not occur when the debuginfo level is set to 1.
The variation doesn't seem relevant to these tests, so this PR simply adds another custom normalization rule to account for the variation.
---
Will conflict with #134759.
|
|
Account for removal of multiline span in suggestion
When highlighting the removed parts of a suggestion, properly account for spans that cover more than one line.
Fix #134485.
|
|
r=wesleywiser
Migrate `incr-add-rust-src-component` to rmake
This PR partially supersedes #128562, and ports the Makefile-based `tests/run-make/incr-add-rust-src-component` to use rmake.rs infra.
Part of #121876.
This run-make test is a regression test for https://github.com/rust-lang/rust/issues/70924. It (tries to) checks that if we add the `rust-src` component in between two incremental compiles, that the compiler doesn't ICE on the second invocation.
- Original issue:https://github.com/rust-lang/rust/issues/70924
- Fix PR: https://github.com/rust-lang/rust/pull/72767
- PR adding this regression test: https://github.com/rust-lang/rust/pull/72952
However, the Makefile version of this used `$SYSROOT/lib/rustlib/src/rust/src/libstd/lib.rs`, but that actually got moved around and reorganized over the years. As of Dec 2024, the `rust-src` component is more like (specific for our purposes):
```
$SYSROOT/lib/rustlib/src/rust/
library/std/src/lib.rs
src/
```
However, this run-make test is ancient and it exercises incr-comp system logic. I'm not sure if this test would actually catch the original regression.
This PR was co-authored with `@Oneirical.`
r? incremental
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: x86_64-msvc
try-job: aarch64-apple
|
|
When highlighting the removed parts of a suggestion, properly account for spans that cover more than one line.
Fix #134485.
|
|
fix default-backtrace-ice test
when running `tests/ui/panics/default-backtrace-ice.rs locally it gave this error:
```
failures:
---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ----
Saved the actual stderr to "/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/test/ui/panics/default-backtrace-ice/default-backtrace-ice.stderr"
diff of stderr:
7
8 aborting due to `-Z treat-err-as-bug=1`
9 stack backtrace:
- (end_short_backtrace)
- (begin_short_backtrace)
- (end_short_backtrace)
- (begin_short_backtrace)
+ [... omitted 22 frames ...]
+
```
(note that you must *not* use --bless; we previously did not have an error annotation to verify it was a full backtrace instead of a short backtrace.)
this is a regression from setting RUST_BACKTRACE=1 by default in https://github.com/rust-lang/rust/pull/134743. we need to turn off the new behavior when running UI tests so that they reflect our dist compiler. normally that's done by checking `sess.unstable_opts.ui_testing`, but this happens extremely early in the compiler before we've expanded arg files. do an extremely simple hack that doesn't work in all cases - we don't need it to work in all cases, only when running UI tests.
cc https://github.com/rust-lang/rust/pull/129658#issuecomment-2561988081
r? `@jieyouxu`
|
|
|
|
when running `tests/ui/panics/default-backtrace-ice.rs locally it gave this error:
```
failures:
---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ----
Saved the actual stderr to "/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/test/ui/panics/default-backtrace-ice/default-backtrace-ice.stderr"
diff of stderr:
7
8 aborting due to `-Z treat-err-as-bug=1`
9 stack backtrace:
- (end_short_backtrace)
- (begin_short_backtrace)
- (end_short_backtrace)
- (begin_short_backtrace)
+ [... omitted 22 frames ...]
+
```
this is a regression from setting RUST_BACKTRACE=1 by default. we need to turn off the new behavior when running UI tests so that they reflect our dist compiler. normally that's done by checking `sess.unstable_opts.ui_testing`, but this happens extremely early in the compiler before we've expanded arg files. do an extremely simple hack that doesn't work in all cases - we don't need it to work in all cases, only when running UI tests.
|
|
Run `tests/ui/backtrace/std-backtrace.rs` on MSVC.
The original PR which disabled these, https://github.com/rust-lang/rust/pull/62897, only mentions them being broken on i686. ~~let's still make sure the rest of windows is supported.~~ Let's see if we can enable this for msvc now (32-bit and 64-bit).
r? `@jieyouxu`
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
try-job: dist-x86_64-msvc
try-job: dist-i686-msvc
|
|
The original PR which disabled these only mentions them being broken on
i686 msvc. Let's try to see if we can reenable this test for msvc (both
32-bit and 64-bit).
|
|
Update `#[coverage(..)]` attribute error messages to match the current implementation
The allowed positions for `#[coverage(..)]` attributes were expanded by #126721, but the corresponding error messages were never updated to reflect the new behaviour.
Part of #134749.
|
|
|
|
|
|
Some of these cases are also implicitly checked by other tests, but it's
helpful to also explicitly list them in the main test.
|
|
|
|
Actually print all the relevant parts of a coroutine in verbose mode
I need to actually see these components, idk why we weren't printing them :)
|
|
Consider arm to diverge if guard diverges
This is not a fix for #134734, but I discovered it when I was gauging how difficult it would be to fix that. It does fix a really old test though :>
r? `@WaffleLapkin` or reassign
|
|
|
|
|
|
chore: fix typos
Fix some typos, thank you very much.
|
|
Bump `stdarch`
This bumps `stdarch` to https://github.com/rust-lang/stdarch/commit/684de0d6fef708cae08214fef9643dd9ec7296e1 to get in https://github.com/rust-lang/stdarch/pull/1677 (tracked in https://github.com/rust-lang/rust/issues/133908).
From the [commit history](https://github.com/rust-lang/stdarch/compare/e5e00aab0a8c8fa35fb7865e88fa82366f615c53...684de0d6fef708cae08214fef9643dd9ec7296e1) I deduced that there shouldn't be any changes to Rust necessary.
From past PRs I'm assuming that bumping `stdarch` like this is fine, but please let me know if this is somehow inappropriate or requires something more to be done!
try-job: arm-android
try-job: armhf-gnu
|
|
|
|
|
|
|
|
Fix some typos
|
|
Signed-off-by: fudancoder <fudancoder@icloud.com.>
|
|
Rollup of 5 pull requests
Successful merges:
- #134638 (Fix effect predicates from item bounds in old solver)
- #134662 (Fix safety docs for `dyn Any + Send {+ Sync}`)
- #134689 (core: fix const ptr::swap_nonoverlapping when there are pointers at odd offsets)
- #134699 (Belay new reviews for workingjubilee)
- #134701 (Correctly note item kind in `NonConstFunctionCall` error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Correctly note item kind in `NonConstFunctionCall` error message
Don't just call everything a "`fn`". This is more consistent with the error message we give for conditionally-const items, which do note the item's def kind.
r? fmease, this is a prerequisite for making those `~const PartialEq` error messages better. Re-roll if you're busy or don't want to review this.
|
|
core: fix const ptr::swap_nonoverlapping when there are pointers at odd offsets
Ensure that the pointer gets swapped correctly even if it is not stored at an aligned offset. This rules out implementations that copy things in a `usize` loop -- so our implementation needs to be adjusted to avoid such a loop when running in const context.
Part of https://github.com/rust-lang/rust/issues/133668
|
|
Fix effect predicates from item bounds in old solver
r? lcnr
|
|
Begin to implement type system layer of unsafe binders
Mostly TODOs, but there's a lot of match arms that are basically just noops so I wanted to split these out before I put up the MIR lowering/projection part of this logic.
r? oli-obk
Tracking:
- https://github.com/rust-lang/rust/issues/130516
|
|
|
|
|
|
offsets in the type
|
|
Clean up a few rmake tests
Now I'm aware it's a bit late to start participating in the Advent of Tests, but here are a few cleanups in the rmake tests to put under the 🎄 anyways. A handful of unused imports, some warnings, and a couple typos.
r? `@jieyouxu` 🎅
|
|
opt-dist: propagate channel info to bootstrap
Fixes #133503.
Previously, `tests/ui/bootstrap/rustc_bootstap.rs` [sic] failed during [beta bump](https://github.com/rust-lang/rust/pull/133447#issuecomment-2501298794) in opt-dist tests. This is because:
- `opt-dist` tried to run `./x test` against beta-channel dist `rustc` through `bootstrap`.
- The dist build produced during the beta bump produces a `rustc` which correctly thinks that it is a beta compiler based on `src/ci/channel` info.
- `opt-dist` tries to run `./x test` on the beta `rustc` from the dist build, but without specifying channel through a synthetic `config.toml`, so `bootstrap` tells `compiletest` that we're on the `nightly` channel (by default).
- Now there's a channel mismatch: `compiletest` believes the `rustc` under test is a *nightly* rustc, but the `rustc` under test actually considers itself a *beta* rustc. This means that `//@ only-nightly` will be satisfied yet the test will fail as the *beta* rustc is not a *nightly* rustc.
This PR:
- Fixes the test failure during beta bump (i.e. #133503) by having `opt-dist` faithfully report the channel of the dist `rustc` being tested (i.e. "beta" in a beta bump PR). This will properly make the test be ignored during beta bump as the `rustc` under test is not a *nightly* rustc.
- Fixes the test name `rustc_bootstap.rs` -> `rustc_bootstrap.rs`. No more stapping.
- Slightly adjusts the doc comment in the test to make it more clear.
I ran a try-job against the beta branch (explicitly running the opt-dist tests by modifying the job definition) with these changes in #134131, and it appears that the try-job was [successful](https://github.com/rust-lang/rust/pull/134131#issuecomment-2555492215). The two commits in this PR are cherry-picked from #134131, with the test commit slightly modified (to also adjust the test comments).
r? `@Kobzol` (or compiler or bootstrap or infra I guess?)
|
|
|
