| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Clippy subtree update
r? `@Manishearth`
|
|
|
|
functions instead
|
|
Add `{ignore,needs}-{rustc,std}-debug-assertions` directive support
Add `{ignore,needs}-{rustc,std}-debug-assertions` compiletest directives and retire the old `{ignore,only}-debug` directives. The old `{ignore,only}-debug` directives were ambiguous because you could have std built with debug assertions but rustc not built with debug assertions or vice versa. If we want to support the use case of controlling test run based on if rustc was built with debug assertions, then having `{ignore,only}-debug` will be very confusing.
cc ````@matthiaskrgr````
Closes #123987.
r? bootstrap (or compiler tbh)
|
|
clippy-subtree-update
|
|
miri: update ABI compat checks to accept Option-like types
This implements the t-lang decision described [here](https://github.com/rust-lang/rust/pull/130628#issuecomment-2402761599).
Fixes https://github.com/rust-lang/miri/issues/3983
|
|
make char::is_whitespace unstably const
I am adding this to the existing https://github.com/rust-lang/rust/issues/132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
|
|
Rollup of 5 pull requests
Successful merges:
- #131261 (Stabilize `UnsafeCell::from_mut`)
- #131405 (bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip)
- #132077 (Add a new `wide-arithmetic` feature for WebAssembly)
- #132562 (Remove the `wasm32-wasi` target from rustc)
- #132660 (Remove unused errs.rs file)
Failed merges:
- #131721 (Add new unstable feature `const_eq_ignore_ascii_case`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove the `wasm32-wasi` target from rustc
This commit is the final step in the journey of renaming the historical `wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of `wasm32-wasip1` has currently been available for 6 months. Users have already seen warnings on stable for 2 months about usage of `wasm32-wasi` and stable users have another 2 months of warnings before the target is removed from stable.
This commit is intended to be the final step in this transition so the source tree should no longer mention `wasm32-wasi` except in historical reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
Do not filter empty lint passes & re-do CTFE pass
Some structs implement `LintPass` without having a `Lint` associated with them #125116 broke that behaviour by filtering them out. This PR ensures that lintless passes are not filtered out.
|
|
ismailarilik:chore/style/sync-submodule-exclusion-list-between-tidy-and-rustfmt, r=jieyouxu
chore(style): sync submodule exclusion list between tidy and rustfmt
As asked in the FIXME comments
|
|
|
|
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`
We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.
`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.
This PR is a bit large, but it's just naming.
The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.
r? `@noratrieb` or reassign
|
|
Clippy: Move some attribute lints to be early pass (post expansion)
r? ```@xFrednet```
As a side effect it removes a duplicated warning on line 53 of the `allow_attributes` test. I discussed this with ```@xFrednet``` , and it's mainly to support the attribute rework https://github.com/rust-lang/rust/issues/131229
|
|
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
Remove outdated tidy license fixmes
~~This PR re-enables license dependency checking for:~~
- ~~the `backtrace` submodule~~
- ~~and the `portable-simd` subtree~~
~~The `stdarch` submodule doesn't have a `Cargo.lock` yet so we can't re-enable it.~~
This PR removes outdated tidy license fixmes, https://github.com/rust-lang/rust/pull/132560#issuecomment-2453525276.
r? bootstrap
|
|
|
|
|
|
This commit is the final step in the journey of renaming the historical
`wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various
steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is
summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of
`wasm32-wasip1` has currently been available for 6 months. Users have
already seen warnings on stable for 2 months about usage of
`wasm32-wasi` and stable users have another 2 months of warnings before
the target is removed from stable.
This commit is intended to be the final step in this transition so the
source tree should no longer mention `wasm32-wasi` except in historical
reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
|
|
feat: Show `static` values on hover
|
|
Do not format generic consts
We introduced **nightly support** for generic const items in #113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items.
r? `````@calebcartwright````` or `````@ytmimi`````
|
|
unicode_data.rs: show command for generating file
https://github.com/rust-lang/rust/pull/131647 made this an easily runnable tool, now we just have to mention that in the comment. :)
Fixes https://github.com/rust-lang/rust/issues/131640.
|
|
Subtree sync for rustc_codegen_cranelift
The highlight this time is an update to Cranelift 0.113,
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
|
|
Add `--print host-tuple` to print host target tuple
People often parse `-vV` output to get to the host tuple, which is annoying to do. It's easier to just get it directly.
I called it "host-tuple" instead of "host" because it's clearer that it's just the target name. I'm open to different names, but I think this one is fine.
a quick GitHub search for `'^host` reveals many instances of people doing the parsing, for example:
https://github.com/japaric/xargo/blob/68e0ca57cd90837fe02f262f074182f9cfeb6227/README.md?plain=1#L369
https://github.com/taiki-e/setup-cross-toolchain-action/blob/0e38473b0c562d6db19a98d3ec20a80f7ac189ae/main.sh#L96
https://github.com/taiki-e/cargo-llvm-cov/blob/8a3553b86551eabf9c30c060b1f72a5bbccb98c6/README.md?plain=1#L625
https://github.com/SiliconLabs/cpc-nvm3/blob/43f3ec39709b30700ef7f39d91fa647974323bf1/do.sh#L35
needs a compiler FCP. I could also do an MCP but I think just an FCP here makes the most sense.
|
|
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
|
|
|
|
miri: Directly use rustc_abi
I tried to make this a PR to the miri repo for funsies. Ironically, the integration flow meant that it would use a too-old toolchain hash, and I didn't understand the build system there enough to want to manually fiddle with the hashes.
|
|
|
|
|
|
As asked in the FIXME comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove support for decompressing dylib metadata
We haven't been compressing dylib metadata for a while now. Removing decompression support will regress error messages about an incompatible rustc version being used, but dylibs are pretty rare anyway.
Fixes https://github.com/rust-lang/rust-analyzer/issues/18451
|
|
Rollup of 9 pull requests
Successful merges:
- #131168 (Fix `target_os` for `mipsel-sony-psx`)
- #132209 (Fix validation when lowering `?` trait bounds)
- #132294 (Bump Fuchsia)
- #132357 (Improve missing_abi lint)
- #132385 (compiler: Move `rustc_target::spec::abi::Abi` to `rustc_abi::ExternAbi`)
- #132403 (continue `TypingMode` refactor)
- #132417 (macOS: Document the difference between Clang's `-darwin` and `-macosx` targets)
- #132421 (Remove `""` case from RISC-V `llvm_abiname` match statement)
- #132422 (llvm: Match new LLVM 128-bit integer alignment on sparc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
continue `TypingMode` refactor
There are still quite a few places which (indirectly) rely on the `Reveal` of a `ParamEnv`, but we're slowly getting there
r? `@compiler-errors`
|
