checkpoint 1 #17
Open
checkpoint 1 #17
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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#144655 which should merge first.
…e kind 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.
I discovered this via research through the git log, and I want to leave additional guidance for future macro spelunkers.
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.
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 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.
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.
In the desugaring of `assert!`, we now expand to a `match` expression
instead of `if !cond {..}`.
The span of incorrect conditions will point only at the expression, and not
the whole `assert!` invocation.
```
error[E0308]: mismatched types
--> $DIR/issue-14091.rs:2:13
|
LL | assert!(1,1);
| ^ expected `bool`, found integer
```
We no longer mention the expression needing to implement the `Not` trait.
```
error[E0308]: mismatched types
--> $DIR/issue-14091-2.rs:15:13
|
LL | assert!(x, x);
| ^ expected `bool`, found `BytePos`
```
`assert!(val)` now desugars to:
```rust
match val {
true => {},
_ => $crate::panic::panic_2021!(),
}
```
Fix rust-lang#122159.
We make some minor changes to some diagnostics to avoid span overlap on
type mismatch or inverted "expected"/"found" on type errors.
We remove some unnecessary parens from core, alloc and miri.
address review comments
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
Shourya742
force-pushed
the
2025-08-12-remove-default-config
branch
from
9034adc to
db2cacd
Compare
This seem to have been overlooked in <rust-lang#138162>
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 rust-lang#96497.
…ross35 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`.
…hpratt Constify `SystemTime` methods This is separated out from rust-lang#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
…ake, r=lcnr editorconfig: don't trim trailing whitespace in tests some test snapshot files require trailing whitespace, and previously manually editing those snapshot files (as is required for run-make tests and some platform-specific tests) in an editor with editorconfig support would cause that whitespace to be removed, [causing CI failures like this one](rust-lang#144596 (comment))
…gross35 Stabilize `path_file_prefix` feature This stabilises `Path::file_prefix`, following the FCP in [tracking issue ](rust-lang#86319) (FCP ended almost a year ago, so if it's needed for proccess we could rerun it) Closes: rust-lang#86319
Deprecate RUST_TEST_* env variables Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can - warn and then remove on use of unstable environment variables - warn on use of stable environment variables (no plan to remove due to compatibility) Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables). This would include: - `RUST_TEST_THREADS` - `RUST_TEST_NOCAPTURE` - `RUST_TEST_SHUFFLE` (unstable) - `RUST_TEST_SHUFFLE_SEED` (unstable) The primary outcomes for this change are - Reducing the scope of what is expected for custom test harnesses to implement - Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g. `RUST_TEST_NOCAPTURE=1` when json output is being read. For testing-devex FCP, see rust-lang/testing-devex-team#10 Fixes rust-lang/testing-devex-team#10 History ------- At each step, I could not find evidence of design discussions on whether to support CLI, env, or both. The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope. At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem. **Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free **2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`. In that issue and the implementation (rust-lang#8823). **2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr. `--nocapture` and `RUST_TEST_NOCAPTURE` were added together. **2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS` **2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414 **2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED` Potentially relevant issues --------------------------- - rust-lang#74845
…=fmease Remove unused `#[must_use]` Self-explanatory Fixes rust-lang#145257
chore(ci): upgrade checkout to v5 Maintenance update to actions/checkout@v5 to align with the current runner stack (Node 24); nothing else modified. Release notes: https://github.com/actions/checkout/releases/tag/v5.0.0
Rollup of 11 pull requests Successful merges: - rust-lang#144210 (std: thread: Return error if setting thread stack size fails) - rust-lang#145310 (Reduce usage of `compiler_for` in bootstrap) - rust-lang#145311 (ci: clean windows disk space in background) - rust-lang#145340 (Split codegen backend check step into two and don't run it with `x check compiler`) - rust-lang#145408 (Deduplicate -L search paths) - rust-lang#145412 (Windows: Replace `GetThreadId`+`GetCurrentThread` with `GetCurrentThreadId`) - rust-lang#145413 (bootstrap: Reduce dependencies) - rust-lang#145426 (Fix typos in bootstrap.example.toml) - rust-lang#145430 (Fix wrong spans with external macros in the `dropping_copy_types` lint) - rust-lang#145431 (Enhance UI test output handling for runtime errors) - rust-lang#145448 (Autolabel `src/tools/{rustfmt,rust-analyzer}` changes with `T-{rustfmt,rust-analyzer}`) r? `@ghost` `@rustbot` modify labels: rollup
`apply_member_constraints`: fix placeholder check Checking whether the member region is *an existential region from a higher universe* is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before rust-lang#140466. I've encountered this issue separately while working on rust-lang#139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile ```rust trait Proj<'a> { type Assoc; } impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F { type Assoc = (); } fn is_proj<F: for<'a> Proj<'a>>(f: F) {} fn define<'a>() -> impl Sized + use<'a> { // This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`. // 'unconstrained_b is an inference variable from a higher universe as it gets // created inside of the binder of `F: for<'a> Proj<'a>`. This previously // caused us to not apply member constraints. We now do, constraining // it to `'a`. is_proj(define::<'a>); &() } fn main() {} ``` This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc rust-lang#140569/rust-lang#142073. However, as we always skipped these member regions in `apply_member_constraints` the skipped region is guaranteed to cause an error in `check_member_constraints` later on.
…lnay Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc` Fixes rust-lang#143688. `@rustbot` label T-libs-api needs-fcp Also needs a crater run, as the `Box` impls could theoretically be breaking due to `#[fundamental]` (though a [cursory search](https://github.com/search?q=%2Fimpl%28%3C.*%3E%29%3F+Default+for+Pin%3C%2F+path%3A*.rs&type=code) suggests this is unlikely to cause issues).
…ls, r=tgross35
Stabilize as_array_of_cells
This PR stabilizes
```rust
impl<T, const N: usize> Cell<[T; N]> {
pub const fn as_array_of_cells(&self) -> &[Cell<T>; N];
}
```
Stabilization report: rust-lang#88248 (comment)
Closes: rust-lang#88248
fix: Reject async assoc fns of const traits/impls in ast_passes Fixes rust-lang#117629
Implement `#[derive(From)]` Implements the `#[derive(From)]` feature ([tracking issue](rust-lang#144889), [RFC](rust-lang/rfcs#3809)). It allows deriving the `From` impl on structs and tuple structs with exactly one field. Some implementation notes: - I wasn't exactly sure which spans to use in the derive generating code, so I just used `span` everywhere. I don't know if it's the Right Thing To Do. In particular the errors when `#[derive(From)]` is used on a struct with an unsized field are weirdly duplicated. - I had to solve an import stability problem, where if I just added the unstable `macro From` to `core::convert`, previously working code like `use std::convert::From` would suddenly require an unstable feature gate, because rustc would think that you're trying to import the unstable macro. `@petrochenkov` suggested that I add the macro the the core prelude instead. This has worked well, although it only works in edition 2021+. Not sure if I botched the prelude somehow and it should live elsewhere (?). - I had to add `Ty::AstTy`, because the `from` function receives an argument with the type of the single field, and the existing variants of the `Ty` enum couldn't represent an arbitrary type.
…-iter-chain, r=jhpratt Stabilize `core::iter::chain` Closes rust-lang#125964
…alexcrichton fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP` missed this in rust-lang#145275 since test calls `rustc` with `-C target-cpu mvp` try-job: `test-various`
Remove duplicated tracing span in bootstrap `trace_cmd` is now called also in the `stream` method, so including it also here was duplicating command spans. r? `@jieyouxu`
…pr, r=jieyouxu Fix tracing debug representation of steps without arguments in bootstrap I was wondering why I see `lainSourceTarbal` in tracing logs... r? `@jieyouxu`
…-run, r=jieyouxu Do not copy files in `copy_src_dirs` in dry run This reduces the time to run the current 9 dist snapshot tests from ~24s to ~2s on my PC. r? `@jieyouxu`
…ovenance, r=RalfJung Stabilize `const_exposed_provenance` feature This closes [tracking issue](rust-lang#144538) and stabilises `fn with_exposed_provenance` and `fn with_exposed_provenance_mut` in const
Enable new `[range-diff]` feature in triagebot This new feature adds a comment to triagebot range-diff feature when a PR is rebased onto a different base/master commit. Related to [#t-compiler > Experimental range-diff for force-push @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Experimental.20range-diff.20for.20force-push/near/534649322) r? Kobzol
Rollup of 11 pull requests Successful merges: - rust-lang#143717 (Add `Default` impls for `Pin`ned `Box`, `Rc`, `Arc`) - rust-lang#144054 (Stabilize as_array_of_cells) - rust-lang#144907 (fix: Reject async assoc fns of const traits/impls in ast_passes) - rust-lang#144922 (Implement `#[derive(From)]`) - rust-lang#144963 (Stabilize `core::iter::chain`) - rust-lang#145436 (fix(tests/rmake/wasm-unexpected-features): change features from `WASM1` to `MVP`) - rust-lang#145453 (Remove duplicated tracing span in bootstrap) - rust-lang#145454 (Fix tracing debug representation of steps without arguments in bootstrap) - rust-lang#145455 (Do not copy files in `copy_src_dirs` in dry run) - rust-lang#145462 (Stabilize `const_exposed_provenance` feature) - rust-lang#145466 (Enable new `[range-diff]` feature in triagebot) r? `@ghost` `@rustbot` modify labels: rollup
Revert "Partially outline code inside the panic! macro". This reverts rust-lang#115670 Without any tests/benchmarks that show some improvement, it's hard to know whether the change had any positive effect. (And if it did, whether that effect is still achieved today.)
const-eval: full support for pointer fragments This fixes rust-lang/const-eval#72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in rust-lang#137280. For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics: ```rust use std::{mem::{self, MaybeUninit}, ptr}; type Byte = MaybeUninit<u8>; const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) { let mut i = 0; while i < n { *dst.add(i) = *src.add(i); i += 1; } } const _MEMCPY: () = unsafe { let ptr = &42; let mut ptr2 = ptr::null::<i32>(); // Copy from ptr to ptr2. memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>()); assert!(*ptr2 == 42); }; ``` What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again. We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^ This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to rust-lang/unsafe-code-guidelines#558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
… r=lcnr Print regions in `type_name`. Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`. Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo. `c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter. The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions. Fixes rust-lang#145168. r? `@lcnr`
Shourya742
force-pushed
the
2025-08-12-remove-default-config
branch
from
fdcd154 to
77c3d6e
Compare
Shourya742
force-pushed
the
2025-08-12-remove-default-config
branch
from
83d5b07 to
e261e25
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.