| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't refer to 'local binding' in extern macro.
When it comes from a macro expansion, the user has no clue what 'local binding' the compiler is talking about, if they don't know the expansion of the macro. Better to just say 'temporary value'.
|
|
Don't refer to 'this tail expression' in expansion.
The user has no clue what the compiler is talking about when it says "this tail expression". It is an implementation detail of the macro that it uses a block with tail expression.
|
|
Rageking8:fix-incorrect-use-of-recommend-over-recommended, r=lqd
Fix incorrect use of "recommend" over "recommended"
Spotted this typo in rust-lang/rust#141554, but it has since been merged.
r? `@Noratrieb`
|
|
r=workingjubilee
Change `tag_field` to `FieldIdx` in `Variants::Multiple`
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
This is a first part of pulling smaller pieces out of rust-lang/rust#138759, so
r? workingjubilee
|
|
Visit the ident in `PreciseCapturingNonLifetimeArg`.
It's currently skipped, presumably by accident.
r? `@BoxyUwU`
|
|
Ensure query keys are printed with reduced queries
Using `-Z query-dep-graph` and debug assertions leads to an ICE that was originally discovered in rust-lang/rust#141700:
> This isn't an incremental bug per se, but instead a bug that has to do with debug printing query keys when debug assertions and `-Z query-dep-graph` is enabled. We end up printing a const (b/c we're using generic const args here) whose debug printing for -Z query-dep-graph requires invoking the same query cyclically 😃
>
> I've pushed a commit which should fix this.
This isn't related to the standard library changes, but instead b/c it seems to be the first usage of `feature(adt_const_params)` in the standard library that ends up being triggered in incremental tests.
r? oli-obk
|
|
Triagebot: Remove `assign.users_on_vacation`
It's been superseded by triagebot's [review queue tracking](https://forge.rust-lang.org/triagebot/review-queue-tracking.html), more specifically *rotation mode*.
r? Kobzol or triagebot
|
|
Run wfcheck in one big loop instead of per module
Maybe we can merge this big loop in the future with the `par_hir_body_owners` call below and run typeck only on items that didn't fail wfcheck. For now let's just see if perf likes it, as it by itself should be beneficial to parallel rustc
|
|
Use non-2015 edition paths in tests that do not test for their resolution
This allows for testing these tests on editions other than 2015
Follow up to https://github.com/rust-lang/rust/pull/141888
|
|
r=oli-obk
Fix for async drop inside async gen fn
Return value (for yield) is corrected for async drop inside async gen function.
In CFG, when internal async drop future is polled and returned `Poll<()>::Pending`, then async gen resume function returns `Poll<(OptRet)>::Pending`.
Fixes rust-lang/rust#140530
|
|
Add link to correct documentation in htmldocck.py
|
|
redesign stage 0 std follow-ups part2
Fixes three bugs:
1. `x check` fails when run on rustdoc without `download-rustc` enabled. (1st commit)
2. `x check` fails when run on the compiler with `download-rustc` enabled. (2nd commit)
3. `x test library` fails with `download-rustc` enabled. (3rd commit)
Fixes rust-lang/rust#142018 (case 1)
Fixes https://github.com/rust-lang/rust/issues/141983 (case 3)
|
|
The user has no clue what tail expression the compiler is talking
about: it is an implementation detail of the macro that it uses a block
with tail expression.
|
|
The user has no clue what 'local binding' the compiler is talking about,
if they don't know the expansion of the macro.
|
|
|
|
Fix typo in src/etc/htmldocck.py
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Change documentation link to the correct section in src/etc/htmldocck.py
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Remove all top-level docs from htmldocck.py
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#136687 (Improve the documentation of `Display` and `FromStr`, and their interactions)
- rust-lang/rust#137306 (Remove `i128` and `u128` from `improper_ctypes_definitions`)
- rust-lang/rust#138699 (build dist for x86_64-pc-solaris and sparcv9-sun-solaris)
- rust-lang/rust#141250 (add s390x z17 target features)
- rust-lang/rust#141467 (make `OsString::new` and `PathBuf::new` unstably const)
- rust-lang/rust#141871 (index: add method for checking range on DenseBitSet)
- rust-lang/rust#141888 (Use non-2015 edition paths in tests that do not test for their resolution)
- rust-lang/rust#142000 (bootstrap: don't symlink source dir into stage0 sysroot)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
|
|
bootstrap: don't symlink source dir into stage0 sysroot
In StdLink::run we subsequently recursively copy the initial sysroot lib directory into the stage0-sysroot lib directory. If the initial sysroot is a toolchain that includes the `rust-src` component (in lib/rustlib/src/rust), if we add this symlink, that recursive copy will overwrite the repo sources with the toolchain's sources.
Fixes https://github.com/rust-lang/rust/issues/141991
|
|
r=compiler-errors
Use non-2015 edition paths in tests that do not test for their resolution
This allows for testing these tests on editions other than 2015
|
|
index: add method for checking range on DenseBitSet
Micro-optimisation that Miri benefits from with the new isolated allocator for native-libs mode. Also possibly just a useful method to have on `DenseBitSet`
|
|
make `OsString::new` and `PathBuf::new` unstably const
Since #129041, `String::into_bytes` is `const`, which allows making `OsString::new` and `PathBuf::new` unstably const now.
Not sure what the exact process for this is; does it need an ACP?
|
|
add s390x z17 target features
tracking issue: https://github.com/rust-lang/rust/issues/130869
earlier target features were added in https://github.com/rust-lang/rust/pull/135630, and https://github.com/rust-lang/rust/issues/135413#issuecomment-2886439455 has some extra context on these new features.
r? ``@ghost``
cc ``@uweigand``
|
|
build dist for x86_64-pc-solaris and sparcv9-sun-solaris
try-job: dist-sparcv9-solaris
try-job: dist-x86_64-solaris
try-job: dist-various-2
try-job: dist-x86_64-illumos
|
|
r=traviscross,workingjubilee
Remove `i128` and `u128` from `improper_ctypes_definitions`
Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:
* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at https://github.com/rust-lang/compiler-team/issues/683, implemented at https://github.com/rust-lang/rust/pull/116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at https://github.com/rust-lang/rust/pull/132422, https://github.com/rust-lang/rust/pull/132741, https://github.com/rust-lang/rust/pull/134115.
* LLVM version of the above: done in LLVM 20 https://github.com/llvm/llvm-project/issues/102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at https://github.com/rust-lang/rust/pull/134290.
At https://github.com/rust-lang/lang-team/issues/255#issuecomment-2088855084, the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.
`repr(i128)` was added to this lint in https://github.com/rust-lang/rust/pull/138282, but is also removed here.
Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.
Closes: https://github.com/rust-lang/rust/issues/134288
[1]: https://github.com/rust-lang/rust/issues/54341
[2]: https://github.com/rust-lang/rust/issues/128950
|
|
r=Amanieu
Improve the documentation of `Display` and `FromStr`, and their interactions
In particular:
- `Display` is not necessarily lossless
- The output of `Display` might not be parseable by `FromStr`, and might
not produce the same value if it is.
- Calling `.parse()` on the output of `Display` is usually a mistake
unless a type's documented output and input formats match.
- The input formats accepted by `FromStr` depend on the type.
This documentation adds no API surface area and makes no guarantees about stability. To the best of my knowledge, everything it says is already established to be true. As such, I don't think it needs an FCP.
|
|
Rework `collect_and_apply` to not rely on size hint for optimization
I saw that we have quite a few `collect_and_apply` calls for N=3-7 (N=7 corresponding to cumulative 99% of nalgebra's calls). Didn't perf locally, but also this is super low-pri, so let's see what rust-timer says.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
In StdLink::run we subsequently recursively copy the initial sysroot
lib directory into the stage0-sysroot lib directory. If the initial
sysroot is a toolchain that includes the `rust-src` component (in
lib/rustlib/src/rust), if we add this symlink, that recursive copy
will overwrite the repo sources with the toolchain's sources.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
It's currently skipped, presumably by accident.
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#137725 (Add `iter` macro)
- rust-lang/rust#141455 (std: abort the process on failure to allocate a TLS key)
- rust-lang/rust#141569 (Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`)
- rust-lang/rust#141698 (Use the informative error as the main const eval error message)
- rust-lang/rust#141925 (Remove bootstrap cfgs from library/)
- rust-lang/rust#141943 (Remove pre-expansion AST stats.)
- rust-lang/rust#141945 (Remove `Path::is_ident`.)
- rust-lang/rust#141957 (Add missing `dyn` keywords to tests that do not test for them Part 2)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
- Drop "usually a mistake"
- Add phrasing from `FromStr` about round-tripping, and about how the
inability to round-trip may surprise users.
|
|
- Drop the phrasing "usually a mistake".
- Mention that `Display` may not be lossless.
- Drop a misplaced parenthetical about round-tripping that didn't fit
the paragraph it was in.
|
|
|
|
In particular:
- `Display` is not necessarily lossless
- The output of `Display` might not be parseable by `FromStr`, and might
not produce the same value if it is.
- Calling `.parse()` on the output of `Display` is usually a mistake
unless a type's documented output and input formats match.
- The input formats accepted by `FromStr` depend on the type.
|
|
|
|
|
|
Add missing `dyn` keywords to tests that do not test for them Part 2
Some more tests that were found
|
|
Remove `Path::is_ident`.
It checks that a path has a single segment that matches the given symbol, and that there are zero generic arguments. It has a single use.
We also have `impl PartialEq<Symbol> for Path` which does exactly the same thing *except* it doesn't check for zero generic arguments, which seems like an oversight. It has numerous uses.
This commit removes `Path::is_ident`, adds a test for zero generic arguments to `PartialEq<Symbol> for Path`, and changes the single use of `is_ident` to instead use `==`.
r? `@wesleywiser`
|
|
r=compiler-errors
Remove pre-expansion AST stats.
They're very little value, because they only measure the top-level `main.rs` or `lib.rs` file. (Other `.rs` files don't get read and parsed until expansion occurs.)
I saw an example recently where the pre-expansion AST was 3KB in size and the post-expansion AST was 66MB.
I kept the "POST EXPANSION" in the output header, I think that's useful information to avoid possible confusion about when the measurement happens.
r? `@davidtwco`
|
|
Remove bootstrap cfgs from library/
These `cfg(bootstrap)` are always false now that rust-lang/rust#119899 has landed, and likewise `cfg(not(bootstrap))` is always true. Therefore, we don't need to wait for the usual stage0 bump to clean these up.
|
|
Use the informative error as the main const eval error message
r? `@RalfJung`
I only did the minimal changes necessary to the const eval error machinery. I'd prefer not to mix test changes with refactorings 😆
|
|
Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`
Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).
Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`
target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
"entry-abi": "C",
"entry-abi": "win64",
"entry-abi": "aapcs",
```
|
|
std: abort the process on failure to allocate a TLS key
The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.
|
|
r=compiler-errors,traviscross
Add `iter` macro
See related discussion in https://rust-lang.zulipchat.com/#narrow/channel/481571-t-lang.2Fgen/topic/iter!.20macro/near/500784563
very little error case testing so far, but the success path works.
There is also no `IterFn` trait yet, as T-lang didn't consider it something urgently needed I think we can implement it in follow-up PRs.
r? lang for the tests, `@compiler-errors` for the impl
|
|
Merge `compiler-builtins` as a Josh subtree
Use the Josh [1] utility to add `compiler-builtins` as a subtree, which
will allow us to stop using crates.io for updates. This is intended to
help resolve some problems when unstable features change and require
code changes in `compiler-builtins`, which sometimes gets trapped in a
bootstrap cycle.
This was done using `josh-filter` built from the r24.10.04 tag:
git fetch https://github.com/rust-lang/compiler-builtins.git 233434412fe7eced8f1ddbfeddabef1d55e493bd
josh-filter ":prefix=library/compiler-builtins" FETCH_HEAD
git merge --allow-unrelated FILTERED_HEAD
The HEAD in the `compiler-builtins` repository is 233434412f ("fix an if
statement that can be collapsed").
[1]: https://github.com/josh-project/josh
|
