| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 15 pull requests
Successful merges:
- #137829 (Stabilize [T]::split_off... methods)
- #137850 (Stabilize `box_uninit_write`)
- #137912 (Do not recover missing lifetime with random in-scope lifetime)
- #137913 (Allow struct field default values to reference struct's generics)
- #137923 (Simplify `<Postorder as Iterator>::size_hint`)
- #137949 (Update MSVC INSTALL.md instructions to recommend VS 2022 + recent Windows 10/11 SDK)
- #137963 (Add ``dyn`` keyword to `E0373` examples)
- #137975 (Remove unused `PpMode::needs_hir`)
- #137981 (rustdoc search: increase strictness of typechecking)
- #137986 (Fix some typos)
- #137991 (Add `avr-none` to SUMMARY.md and platform-support.md)
- #137993 (Remove obsolete comment from DeduceReadOnly)
- #137996 (Revert "compiler/rustc_data_structures/src/sync/worker_local.rs: delete "unsafe impl Sync"")
- #138019 (Pretty-print `#[deprecated]` attribute in HIR.)
- #138026 (Make CrateItem::body() function return an option)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Make CrateItem::body() function return an option
When we initially created `CrateItem`, it would only represent items that contain a body.
That is no longer the case, for now, make this explicit by expanding the APIs to retrieve the item body.
This is related to https://github.com/rust-lang/project-stable-mir/issues/34
r? `@oli-obk`
|
|
r=compiler-errors
Pretty-print `#[deprecated]` attribute in HIR.
Pretty-print `#[deprecated]` attribute in a form closer to how it might appear in Rust source code, rather than using a `Debug`-like representation.
Consider the following Rust code:
```rust
#[deprecated]
pub struct PlainDeprecated;
#[deprecated = "here's why this is deprecated"]
pub struct DirectNote;
#[deprecated(since = "1.2.3", note = "here's why this is deprecated")]
pub struct SinceAndNote;
```
Here's the previous output:
```
#[attr="Deprecation{deprecation: Deprecation{since: Unspecifiednote:
suggestion: }span: }")]
struct PlainDeprecated;
#[attr="Deprecation{deprecation: Deprecation{since: Unspecifiednote:
here's why this is deprecatedsuggestion: }span: }")]
struct DirectNote;
#[attr="Deprecation{deprecation: Deprecation{since: NonStandard(1.2.3)note:
here's why this is deprecatedsuggestion: }span: }")]
struct SinceAndNote;
```
Here's the new output:
```rust
#[deprecated]
struct PlainDeprecated;
#[deprecated = "here's why this is deprecated"]
struct DirectNote;
#[deprecated(since = "1.2.3", note = "here's why this is deprecated"]
struct SinceAndNote;
```
Also includes a test for `#[diagnostic::(..)]` attributes, though their behavior is not changed here. I already wrote the test, so I figured it probably won't hurt to have it.
Related to discussion in #137645.
r? `@jdonszelmann`
|
|
r=compiler-errors
Revert "compiler/rustc_data_structures/src/sync/worker_local.rs: delete "unsafe impl Sync""
Revert "compiler/rustc_data_structures/src/sync/worker_local.rs: delete "unsafe impl Sync""
This reverts commit 02406903b0c26440428580a4bbaf30da973c5b23.
See https://github.com/rust-lang/rust/pull/136858#discussion_r1977482593
cc "Parallel Rustc Front-end" https://github.com/rust-lang/rust/issues/113349
r? SparrowLii
``@rustbot`` label: +WG-compiler-parallel
``@rustbot`` label: +C-cleanup
|
|
Remove obsolete comment from DeduceReadOnly
The situation described in the comment does arise in practice now and described panic is long gone.
|
|
Add `avr-none` to SUMMARY.md and platform-support.md
This was missed this in the implementation PR, so update the links here.
|
|
Fix some typos
Fix some typos
|
|
rustdoc search: increase strictness of typechecking
r? `@notriddle`
The signature of `makePrimitiveElement` is now more accurate.
I believe the intent of the code is that `name` cannot be null if `bindingName.name` is null, and I believe typescript is expressive enough to encode this, but I'm not quite sure how, or if this would be desirable.
I'm also introducing mapped types into `rustdoc.d.ts`, but I think it's worth it in order to avoid keeping two interfaces in sync.
I may add more commits onto this to remove more ``@ts-expect-error`` instances.
|
|
Remove unused `PpMode::needs_hir`
This method was added in #99360 to avoid an overzealous `span_delayed_bug` ICE in specific circumstances, but the only caller was subsequently removed in #136603, which presumably avoids the problem in a more principled way.
|
|
Add ``dyn`` keyword to `E0373` examples
Closes #137962
|
|
Update MSVC INSTALL.md instructions to recommend VS 2022 + recent Windows 10/11 SDK
This is generally iffy because we don't consistently [document the exact minimum versions of build tools required to build a given Rust toolchain](https://github.com/rust-lang/rust/issues/129307).
cc #129307, *maybe* rustup docs are outdated?
Anyway, I updated this because I was on a slightly older VS toolchain and I couldn't `./x build library` on MSVC (even though maybe a month ago I could) due to CI `rustc_llvm` using stuff from newer Windows 11 SDK maybe. I updated the VS toolchain + Windows 11 SDK, and then I could build.
I'm not 100% sure the requirements here are accurate. It might be too high?
r? ````@ChrisDenton````
|
|
Simplify `<Postorder as Iterator>::size_hint`
The current version is sometimes malformed (cc #137919); let's see if we can get away with a loose but trivially-correct one.
|
|
r=BoxyUwU
Allow struct field default values to reference struct's generics
Right now, the default field value feature (https://github.com/rust-lang/rust/issues/132162) lowers anon consts whose types may reference ADT params that the const doesn't inherit.
This PR fixes this, so that these defaults can reference ADTs' generics, and sets the `generics_of` parenting up correctly.
There doesn't seem to be a good reason not to support this, since the anon const has a well-defined type from the field, and the anon const doesn't interact with the type system like generic parameter defaults do.
r? `````@boxyuwu````` or reassign
I could also make this into an error if this seems problematic (https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:default-field-value-implicit-param?expand=1)...... but I'd rather make this work and register an open question on the tracking issue about validating that this is well-vetted.
Fixes #137896
|
|
r=oli-obk
Do not recover missing lifetime with random in-scope lifetime
Suppresses a ton of stray errors, since this recovery doesn't really make sense anymore now that we have a dedicated `ReError` kind.
r? oli-obk or reassign
|
|
Stabilize `box_uninit_write`
Closes: https://github.com/rust-lang/rust/issues/129397.
|
|
Stabilize [T]::split_off... methods
This was previously known as the slice_take feature.
Closes #62280
|
|
Rollup of 6 pull requests
Successful merges:
- #137077 (Postprocess bootstrap metrics into GitHub job summary)
- #137373 (Compile run-make-support and run-make tests with the bootstrap compiler)
- #137634 (Update `compiler-builtins` to 0.1.149)
- #137667 (Add `dist::Gcc` build step)
- #137722 (`librustdoc`: 2024 edition! 🎊)
- #137947 (Do not install rustup on Rust for Linux job)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
When we initially created `CrateItem`, it would only represent items
that contain a body.
That is no longer the case, for now, make this explicit by expanding
the APIs to retrieve the item body.
This is related to https://github.com/rust-lang/project-stable-mir/issues/34
|
|
Do not install rustup on Rust for Linux job
Trying to fix the RfL job after the recent rustup update.
r? ``@ghost``
try-job: x86_64-rust-for-linux
|
|
`librustdoc`: 2024 edition! 🎊
Like #137333 , but for rustdoc 😁
|
|
Add `dist::Gcc` build step
This PR adds a `dist:Gcc` bootstrap step to distribute a prebuilt `libgccjit.so` from CI on x64 Linux.
With primed sccache, the build takes ~4 minutes on CI, and produces a 50 MiB archive.
I want to land this before adding something akin to `[gcc] download-ci-gcc = true`, to already have the artifacts available on CI, to make it easier to setup the download merge-base logic.
r? ``@ghost``
|
|
Update `compiler-builtins` to 0.1.149
Includes a change to make a subset of math symbols available on all platforms [1], and disables `f16` on aarch64 without neon [2].
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
[2]: https://github.com/rust-lang/compiler-builtins/pull/775
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: armhf-gnu
try-job: dist-various-1
try-job: dist-various-2
try-job: dist-aarch64-linux
try-job: dist-arm-linux
try-job: dist-armv7-linux
try-job: dist-x86_64-linux
try-job: test-various
|
|
Compile run-make-support and run-make tests with the bootstrap compiler
It does not seem necessary to have to recompile run-make-support on changes to the local compiler/stdlib. This PR simplifies the implementation of a few tools, then switches rms to stage0 and also makes the handling of environment variables in run-make tests simpler.
Best reviewed commit-by-commit. I can split it into multiple PRs if you want.
Also tested that `COMPILETEST_FORCE_STAGE0=1 ./x test tests/run-make --stage 0` still works. Incredibly, it looks like it even passes more tests than on `master` :laughing:
r? ``@jieyouxu``
|
|
Postprocess bootstrap metrics into GitHub job summary
This PR adds a postprocessing step to each CI job that writes the build and test step bootstrap metrics into [GitHub job summary](https://github.blog/news-insights/product-news/supercharging-github-actions-with-job-summaries/). You can see an example result for dist and test jobs [here](https://github.com/rust-lang-ci/rust/actions/runs/13619495480).
r? ``@ghost``
try-job: dist-x86_64-illumos
try-job: x86_64-gnu
|
|
mgca: Lower all const paths as `ConstArgKind::Path`
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
r? `@BoxyUwU`
|
|
|
|
|
|
|
|
some of the fields of rustdoc.Row were confusing null and undefined.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Support raw-dylib link kind on ELF
raw-dylib is a link kind that allows rustc to link against a library without having any library files present.
This currently only exists on Windows. rustc will take all the symbols from raw-dylib link blocks and put them in an import library, where they can then be resolved by the linker.
While import libraries don't exist on ELF, it would still be convenient to have this same functionality. Not having the libraries present at build-time can be convenient for several reasons, especially cross-compilation. With raw-dylib, code linking against a library can be cross-compiled without needing to have these libraries available on the build machine. If the libc crate makes use of this, it would allow cross-compilation without having any libc available on the build machine. This is not yet possible with this implementation, at least against libc's like glibc that use symbol versioning. The raw-dylib kind could be extended with support for symbol versioning in the future.
This implementation is very experimental and I have not tested it very well. I have tested it for a toy example and the lz4-sys crate, where it was able to successfully link a binary despite not having a corresponding library at build-time.
I was inspired by Björn's comments in https://internals.rust-lang.org/t/bundle-zig-cc-in-rustup-by-default/22096/27
Tracking issue: #135694
r? bjorn3
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
|
|
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
|
|
"unsafe impl Sync""
This reverts commit 02406903b0c26440428580a4bbaf30da973c5b23.
|
|
|
|
|
|
|
|
|
|
The situation described in the comment does arise in practice now and
described panic is long gone.
|
|
Get rid of the `Captures` hack
|
|
|
|
This was missed this in the implementation PR, so update the links here.
|
|
Signed-off-by: fuyangpengqi <995764973@qq.com>
|
