| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Constify `SystemTime` methods
This is separated out from rust-lang/rust#143949 due to the fact that it touches nontrivial system code. While the same arithmetic methods on `Instant` could be made const, since that type explicitly cannot be constructed at const-time, we don't bother. However, due to the fact that `SystemTime::UNIX_EPOCH` exists, it can be useful to create other anchors at other points in time, and thus these methods should be possible to use in const context.
> Side comment: I would honestly like to just move every single implementation which is a thin wrapper over `Duration` or some integer clock into their own module which is tested on all targets, so that we don't have to worry about code for lower-tier targets not being tested. However, the comments in `std::sys_common` pointing out the desire to move things to `std::sys::common` confused me, particularly due to the fact that `std::sys::common` is taken from the hellish asterisk-import of `std::sys::pal::common` and others.
>
> I think that, for trivial types like this, we should just have a platform-independent module that can be tested on all platforms, to both ensure that the code is properly tested regardless of whether higher-tier platforms needed, and to avoid the extreme mental gymnastics required to determine where in the code it lies.
>
> However, since I'm not on any of the teams maintaining this code and am not involved, I'll settle for just copy-pasting like everyone else has been doing. I just want to express how I'm not happy about that.
**Reviewer note: please only pay attention to the last commit of this PR, until its blocker is merged.**
Since this depends on the previous PR:
`@rustbot` blocked
|
|
Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`
* Add ASCII-related methods from `u8` to `core::ascii::Char`.
* Add `core::ascii::Char::MIN` and `core::ascii::Char::MAX`.
|
|
Set dead_on_return attribute for indirect arguments
Set the dead_on_return attribute (added in LLVM 21) for arguments that are passed indirectly, but not byval.
This indicates that the value of the argument on return does not matter, enabling additional dead store elimination.
From LangRef:
> This attribute indicates that the memory pointed to by the argument is dead upon function return, both upon normal return and if the calls unwinds, meaning that the caller will not depend on its contents. Stores that would be observable either on the return path or on the unwind path may be elided.
>
> Specifically, the behavior is as-if any memory written through the pointer during the execution of the function is overwritten with a poison value upon function return. The caller may access the memory, but any load not preceded by a store will return poison.
>
> This attribute does not imply aliasing properties. For pointer arguments that do not alias other memory locations, noalias attribute may be used in conjunction. Conversely, this attribute always implies dead_on_unwind.
>
> This attribute cannot be applied to return values.
This fixes parts of https://github.com/rust-lang/rust/issues/96497.
|
|
|
|
|
|
Consolidate stage directories and group logs in bootstrap
My post-stage-0-redesign bootstrap fixes aren't done yet, but I think that enough steps have been migrated to the new system that it makes sense to actually modify the directories on disk, and what gets printed when bootstrap runs, so that it actually corresponds to the new system. Before, the printed stages didn't always make sense.
This PR:
- Fixes the numbering of `stageN` directories in the build directory. It was not corresponding to the correct stages before; notice that I did not modify `bootstrap/README.md`, as it was essentially describing what happens after this PR (first commit).
- Unifies all steps that output a build group to use the `Builder::msg` method. It's probably not the final stage, and some of the test steps might not be fully accurate yet, because I didn't fix test step numbering yet, but I think that it's a clear improvement from before, and now that everything uses the same method, we can easily make changes across the board, to ensure that it stays unified (second commit).
r? `@jieyouxu`
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes the minimal fixes necessary for rustdoc to compile and pass
existing tests with the switch to `MacroKinds`. It only works for macros
that don't actually have multiple kinds, and will panic (with a `todo!`)
if it encounters a macro with multiple kinds.
rustdoc needs further fixes to handle macros with multiple kinds, and to
handle attributes and derive macros that aren't proc macros.
|
|
This updates two clippy lints which had exceptions for `MacroKind::Bang`
macros to extend those exceptions to any macro, now that a macro_rules
macro can be any kind of macro.
|
|
The use of `Not` to describe the `!` in `macro_rules!` reads
confusingly, and also results in search collisions with the diagnostic
structure `MacroRulesNot` elsewhere in the compiler. Rename it to use
the more conventional `Bang` for `!`.
|
|
This eliminates the case in `failed_to_match_macro` to check for a
function-like invocation of a macro with no function-like rules.
Instead, macro kind mismatches now result in an unresolved macro, and we
detect this case in `unresolved_macro_suggestions`, which now carefully
distinguishes between a kind mismatch and other errors.
This also handles cases of forward-referenced attributes and cyclic
attributes.
Expand test coverage to include all of these cases.
|
|
|
|
I discovered this via research through the git log, and I want to leave
additional guidance for future macro spelunkers.
|
|
Review everything that uses `MacroKind`, and switch anything that could
refer to more than one kind to use `MacroKinds`.
Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros,
using the concrete `MacroRulesMacroExpander` type, and have it track
which kinds it can handle. Eliminate the separate optional `attr_ext`,
now that a `SyntaxExtension` can handle multiple macro kinds.
This also avoids the need to downcast when calling methods on
`MacroRulesMacroExpander`, such as `get_unused_rule`.
Integrate macro kind checking into name resolution's
`sub_namespace_match`, so that we only find a macro if it's the right
type, and eliminate the special-case hack for attributes.
|
|
Make no_mangle on foreign items explicit instead of implicit
for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it.
I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :)
Builds on rust-lang/rust#144655 which should merge first.
|
|
|
|
Rollup of 17 pull requests
Successful merges:
- rust-lang/rust#131477 (Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var)
- rust-lang/rust#139806 (std: sys: pal: uefi: Overhaul Time)
- rust-lang/rust#144386 (Extract TraitImplHeader in AST/HIR)
- rust-lang/rust#144921 (Don't emit `rustdoc::broken_intra_doc_links` for GitHub-flavored Markdown admonitions like `[!NOTE]`)
- rust-lang/rust#145155 (Port `#[allow_internal_unsafe]` to the new attribute system (attempt 2))
- rust-lang/rust#145214 (fix: re-enable self-assignment)
- rust-lang/rust#145216 (rustdoc: correct negative-to-implicit discriminant display)
- rust-lang/rust#145238 (Tweak invalid builtin attribute output)
- rust-lang/rust#145249 (Rename entered trace span variables from `_span` to `_trace`)
- rust-lang/rust#145251 (Support using #[unstable_feature_bound] on trait)
- rust-lang/rust#145253 (Document compiler and stdlib in stage1 in `pr-check-2` CI job)
- rust-lang/rust#145260 (Make explicit guarantees about `Vec`’s allocator)
- rust-lang/rust#145263 (Update books)
- rust-lang/rust#145273 (Account for new `assert!` desugaring in `!condition` suggestion)
- rust-lang/rust#145283 (Make I-miscompile imply I-prioritize)
- rust-lang/rust#145291 (bootstrap: Only warn about `rust.debug-assertions` if downloading rustc)
- rust-lang/rust#145292 (Fix a typo in range docs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
chore(ci): upgrade checkout to v5
|
|
Signed-off-by: Sacha Ayoun <sachaayoun@gmail.com>
|
|
|
|
Fix a typo in range docs
|
|
bootstrap: Only warn about `rust.debug-assertions` if downloading rustc
The changes in rust-lang/rust#145149 had the unwanted side-effect of causing bootstrap to *always* warn about `rust.debug-assertions = true`, even if rustc isn't going to be downloaded anyway.
cc ``@Shourya742`` ``@Kobzol``
|
|
Make I-miscompile imply I-prioritize
Since I-unsound already implies I-prioritize, it makes sense that I-miscompile should do the same.
|
|
Account for new `assert!` desugaring in `!condition` suggestion
`rustc` in https://github.com/rust-lang/rust/pull/122661 is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>` while not being `bool` itself no longer a straightforward suggestion, but `!!condition` will coerce the expression to be `bool`, so it can be machine applicable.
Transposing https://github.com/rust-lang/rust-clippy/pull/15453/ to the rustc repo.
r? `````@samueltardieu`````
|
|
Update books
## rust-lang/reference
6 commits in 1be151c051a082b542548c62cafbcb055fa8944f..59b8af811886313577615c2cf0e045f01faed88b
2025-08-10 18:21:53 UTC to 2025-08-08 01:00:04 UTC
- Add LoongArch32 to inline-assembly documentation (rust-lang/reference#1942)
- Update `no_builtins` to use the attribute template (rust-lang/reference#1909)
- Update `global_allocator` to use the attribute template (rust-lang/reference#1919)
- Update `windows_subsystem` to use the attribute template (rust-lang/reference#1920)
- Remove note on accepted invalid `should_panic` syntax (rust-lang/reference#1955)
- specify relative drop order of pattern bindings (rust-lang/reference#1953)
## rust-lang/rust-by-example
1 commits in bd1279cdc9865bfff605e741fb76a0b2f07314a7..adc1f3b9012ad3255eea2054ca30596a953d053d
2025-08-08 12:02:24 UTC to 2025-08-08 12:02:24 UTC
- Update Chinese translations in `zh.po` (rust-lang/rust-by-example#1950)
|
|
Make explicit guarantees about `Vec`’s allocator
This commit amends the documentation of `Vec::as_mut_ptr` and `Vec::into_raw_parts` to make it explicit that such calls may be paired with calls to `dealloc` with a suitable layout. This guarantee was effectively already provided by the docs of `Vec::from_raw_parts` mentioning `alloc`.
Additionally, we copy-paste and adjust the “Memory layout” section from the documentation of `std::boxed` to `std::vec`. This explains the allocator guarantees in more detail.
|
|
Document compiler and stdlib in stage1 in `pr-check-2` CI job
This restores the original behavior pre-https://github.com/rust-lang/rust/pull/145011 (I thought that stage 2 makes more sense here, but it made the job ~30m slower, which is bad).
Let's see what will be the "new" duration, it should be ~55 minutes.
r? ```````@jieyouxu```````
|
|
Support using #[unstable_feature_bound] on trait
This is needed to unblock https://github.com/rust-lang/rust/pull/145095
r? ```````@BoxyUwU```````
|
|
Rename entered trace span variables from `_span` to `_trace`
This PR just changes the name of `EnteredTraceSpan` variables used to automatically close tracing spans when going out of scope. This renaming was needed because `_span` could possibly be confused with the `Span` type in rustc, so I used `_trace` as suggested in https://github.com/rust-lang/rust/pull/144727#discussion_r2247267670.
|
|
Tweak invalid builtin attribute output
- Add link to reference/docs when possible
- More accurate suggestions by supporting multiple alternative suggestions
```
error: malformed `crate_type` attribute input
--> $DIR/crate-type-macro-call.rs:1:1
|
LL | #![crate_type = foo!()]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit <https://doc.rust-lang.org/reference/linkage.html>
help: the following are the possible correct uses
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "bin"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "cdylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "dylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "lib"]
|
= and 4 other candidates
```
|
|
rustdoc: correct negative-to-implicit discriminant display
This PR want to fix rust-lang/rust#145125
In:
https://github.com/rust-lang/rust/blob/7f7b8ef27d86c865a7ab20c7c42f50811c6a914d/compiler/rustc_middle/src/ty/util.rs#L33-L38
the `Discr`'s `val` field is `u128`, so we can't use `discr.val as i128` to represent `Discr`'s signed value.
We should use `Discr`'s `Display` trait to display signed value.
https://github.com/rust-lang/rust/blob/7f7b8ef27d86c865a7ab20c7c42f50811c6a914d/compiler/rustc_middle/src/ty/util.rs#L60-L73
|
|
fix: re-enable self-assignment
## Description
Re-enables the self-assignment detection that was previously disabled due to unrelated regressions. The fix detects useless assignments like `x = x` and `foo.field = foo.field`.
## History
The original regressions (rust-lang/rust#81626, rust-lang/rust#81658) were specifically about false positives in write-only field detection, not self-assignment detection. Belows are brief history for the rule that I understand.
- Self-assignment detection was originally implemented in rust-lang/rust#87129 to address rust-lang/rust#75356
- The implementation was disabled alongside the revert of rust-lang/rust#81473's "write-only fields" detection
- rust-lang/rust#81473 was reverted via rust-lang/rust#86212 and rust-lang/rust#83171 due to false positives in write-only field detection (rust-lang/rust#81626, rust-lang/rust#81658)
- The self-assignment detection feature got removed, even though it wasn't the reason for the problems
This PR only re-enables the self-assignment checks, which are orthogonal to the problematic write-only field analysis.
## Changes
- Removed `#[allow(dead_code)]` from `compiler/rustc_passes/src/dead.rs` file
- `handle_assign` and
- `check_for_self_assign`
- Added `ExprKind::Assign` handling in `visit_expr` to call both methods
- Updated test expectations in `tests/ui/lint/dead-code/self-assign.rs`
|
|
Port `#[allow_internal_unsafe]` to the new attribute system (attempt 2)
This is a slightly modified version of ae1487aa9922de7642c448cc0908584026699e1c, which caused a performance regression (reverted in https://github.com/rust-lang/rust/pull/145086#issue-3303428759). The diff between this PR and the previous one can be seen in 027a1def.
r? ```````@jdonszelmann``````` :sparkling_heart:
|
|
r=fmease,GuillaumeGomez
Don't emit `rustdoc::broken_intra_doc_links` for GitHub-flavored Markdown admonitions like `[!NOTE]`
fixes rust-lang/rust#141866
|
|
Extract TraitImplHeader in AST/HIR
Several fields of `Impl` are only applicable when it's a trait impl. This moves those fields into a new struct that is only present for trait impls.
|
|
std: sys: pal: uefi: Overhaul Time
Use UEFI time format for SystemTime.
All calculations and comparisons are being done using UnixTime since UEFI Time format does not seem good fit for those calculations.
I have tested the conversions and calculations, but I am not sure if there is a way to run unit tests for platform specific code in Rust source.
The only real benefit from using UEFI Time representation is that to and fro conversion will preserve `daylight` and `timezone` values.
r? `@joboet`
|
|
Apple: Always pass SDK root when linking with `cc`, and pass it via `SDKROOT` env var
Fixes https://github.com/rust-lang/rust/issues/80817, fixes https://github.com/rust-lang/rust/issues/96943, and generally simplifies our linker invocation on Apple platforms.
Part of https://github.com/rust-lang/rust/issues/129432.
### Necessary background on trampoline binaries
The developer binaries such as `/usr/bin/cc` and `/usr/bin/clang` are actually trampolines (similar in spirit to the Rust binaries in `~/.cargo/bin`) which effectively invokes `xcrun` to get the current Xcode developer directory, which allows it to find the actual binary under `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/*`.
This binary is then launched with the following environment variables set (but none of them are set if `SDKROOT` is set explicitly):
- `SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk`
- `LIBRARY_PATH=/usr/local/lib` (appended)
- `CPATH=/usr/local/include` (appended)
- `MANPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:` (prepended)
This allows the user to type e.g. `clang foo.c` in their terminal on macOS, and have it automatically pick up a suitable Clang binary and SDK from either an installed Xcode.app or the Xcode Command Line Tools.
(It acts roughly as-if you typed `xcrun -sdk macosx clang foo.c`).
### Finding a suitable SDK
All compilation on macOS is cross-compilation using SDKs, there are no system headers any more (`/usr/include` is gone), and the system libraries are elsewhere in the file system (`/usr/lib` is basically empty). Instead, the logic for finding the SDK is handled by the `/usr/bin/cc` trampoline (see above).
But relying on the `cc` trampoline doesn't work when:
- Cross-compiling, since a different SDK is needed there.
- Invoking the linker directly, since the linker doesn't understand `SDKROOT`.
- Linking build scripts inside Xcode (see https://github.com/rust-lang/rust/issues/80817), since Xcode prepends `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin` to `PATH`, which means `cc` refers to the _actual_ Clang binary, and we end up with the wrong SDK root specified.
Basically, we cannot rely on the trampoline at all, so the last commit removes the special-casing that was done when linking with `cc` for macOS (i.e. the most common path), so that **we now always invoke `xcrun` (if `SDKROOT` is not explicitly specified) to find the SDK root**.
Making sure this is non-breaking has a few difficulties though, namely that the user might not have Xcode installed, and that the compiler driver may not understand the `-isysroot` flag. These difficulties are explored below.
#### No Xcode
There are several compiler drivers which work without Xcode by bundling their own SDK, including `zig cc`, Nixpkgs' `clang` and Homebrew's `llvm` package. Additionally, `xcrun` is rarely available when cross-compiling from non-macOS and instead the user might provide a downloaded SDK manually with `-Clink-args=...`.
We do still want to _try_ to invoke `xcrun` if possible, since it is usually the SDK that the user wants (and if not, the environment should override `xcrun`, such as is done by Nixpkgs). But we do not want failure to invoke `xcrun` to stop the linking process. This is changed in the second-to-last commit.
#### `SDKROOT` vs. `-isysroot`
The exact reasoning why we do not always pass the SDK root when linking on macOS eludes me (the git history dead ends in rust-lang/rust#100286), but I suspect it's because we want to support compiler drivers which do not support the `-isysroot` option.
To make sure that such use-cases continue to work, we now pass the SDK root via the `SDKROOT` environment variable. This way, compiler drivers that support setting the SDK root (such as Clang and GCC) can use it, while compiler drivers that don't (presumably because they figure out the SDK in some other way) can just ignore it.
One small danger here would be if there's some compiler driver out there which works with the `-isysroot` flag, but not with the `SDKROOT` environment variable. I am not aware of any?
In a sense, this also shifts the blame; if a compiler driver does not understand `SDKROOT`, it won't work with e.g. `xcrun -sdk macosx15.0 $tool` either, so it can more clearly be argued that this is incorrect behaviour on the part of the tool.
Note also that this overrides the behaviour discussed above (`/usr/bin/cc` sets some extra environment variables), I will argue that is fine since `MANPATH` and `CPATH` is useless when linking, and `/usr/local/lib` is empty on a default system at least since macOS 10.14 (it might be filled by extra libraries installed by the user, but I'll argue that if we want it to be part of the default library search path, we should set it explicitly so that it's also set when linking with `-Clinker=ld`).
### Considered alternatives
- Invoke `/usr/bin/cc` instead of `cc`.
- This breaks many other use-cases though where overriding `cc` in the PATH is desired.
- Look up `which cc`, and do special logic if in Xcode toolchain.
- Seems brittle, and besides, it's not the `cc` in the Xcode toolchain that's wrong, it's the `/usr/bin/cc` behaviour that is a bit too magical.
- Invoke `xcrun --sdk macosx cc`.
- This completely ignores `SDKROOT`, so we'd still have to parse that first to figure out if it's suitable or not, but would probably be workable.
- Maybe somehow configure the linker with extra flags such that it'll be able to link regardless of linking for macOS or e.g. iOS? Though I doubt this is possible.
- Bundle the SDK, similar to `zig-cc`.
- Comes with it's own host of problems.
### Testing
Tested that this works with the following `-Clinker=...`:
- [x] Default (`cc`)
- [x] `/usr/bin/ld`
- [x] Actual Clang from Xcode (`/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang`)
- [x] `/usr/bin/clang` (invoked via `clang` instead of `cc`)
- [x] Homebrew's `llvm` package (ignores `SDKROOT`, uses their own SDK)
- [x] Homebrew's `gcc` package (`SDKROOT` is preferred over their own SDK)
- [x] ~Macports `clang`~ Couldn't get it to build
- [x] Macports `gcc` (`SDKROOT` is preferred over their own SDK)
- [x] Zig CC installed via. homebrew (ignores both `-isysroot` and `SDKROOT`, uses their own SDK)
- [x] Nixpkgs `clang` (ignores `SDKROOT`, uses their own SDK)
- [x] Nixpkgs `gcc` (ignores `SDKROOT`, uses their own SDK)
- [x] ~[`cosmocc`](https://github.com/jart/cosmopolitan)?~ Doesn't accept common flags (like `-arch`)
CC ```````@BlackHoleFox``````` ```````@thomcc```````
|
|
|
|
|
|
|
|
|
|
|
|
Now stageN-X corresponds to stage N X, as it should.
|
|
|
|
|
