Resync #3
Merged
Resync #3
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
Pass Ident by reference in ast Visitor `MutVisitor`'s version of `visit_ident` passes around `&Ident`, but `Visitor` copies `Ident`. This PR changes that r? `@petrochenkov` related to rust-lang#128974
…Kobzol remove `change-id` from CI script It's not necessary to set `change-id` for CI since rust-lang#130356.
library: consistently use American spelling for 'behavior' We use "behavior" a lot more often than "behaviour", but some "behaviour" have even snuck into user-facing docs. This makes the spelling consistent.
Run the full stage 2 `run-make` test suite in `x86_64-gnu-debug` Run the full `run-make` test suite in the `x86_64-gnu-debug` CI job. This is currently the *only* CI job where `//@ needs-force-clang-based-test` will be satisfied, so some `run-make` tests will literally never be run otherwise. Before this PR, the CI job only ran `run-make` tests which contains the substring `clang` in its test name, which is both (1) a footgun because it's very easy to forget and (2) it masks tests that would otherwise fail (even failing to compile) because the test is skipped if doesn't have a `clang` in its test name. With the environment of `x86_64-gnu-debug`, two `run-make` tests failed before this PR: 1. `tests/run-make/issue-84395-lto-embed-bitcode/rmake.rs`: this was broken for a long time because `objcopy` in llvm bin tools was renamed to `llvm-objcopy`. This test was converted into a rmake.rs test, rather straight forward. 2. `tests/run-make/cross-lang-lto-riscv-abi/rmake.rs`: this was broken for a long time and never worked. The old version inspected human-readable output of `llvm-readobj --file-header` looking for substring `EF_RISCV_FLOAT_ABI_DOUBLE`, but the human-readable output will only contain something like `Flags: 0x5, RVC, double-float ABI`, hence it will never match. This test was fixed by instead using the `object` crate to actually decode the ELF headers looking for the specific `e_flags` based on reading the RISCV ELF psABI docs. This PR is best reviewed commit-by-commit, two commits setup the support library for functionality and two commits are for each of the failing `run-make` tests. I had to bump the `x86_64-gnu-debug` job to be ran with a runner with larger disk space. Part of rust-lang#132034. try-job: x86_64-gnu-debug
Then we can rename the _raw functions to drop their suffix, and instead explicitly use is_stable_const_fn for the few cases where that is really what you want.
…vectors." This reverts commit 5af56ca.
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#132106 (Pass Ident by reference in ast Visitor) - rust-lang#132130 (remove `change-id` from CI script) - rust-lang#132137 (library: consistently use American spelling for 'behavior') r? `@ghost` `@rustbot` modify labels: rollup
This updates the "start" and "stop" methods of the test runner to use the standalone package server.
…ompiler-errors Const stability checks v2 The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage: - It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention. - The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check. Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories. This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. Also see the updated dev-guide at rust-lang/rustc-dev-guide#2098. I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`. ### Open question There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics. I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics. Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api` Part of rust-lang#129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown) Fixes rust-lang#131073 by making it so that const-stable functions are always stable try-job: test-various
Update cargo 14 commits in cf53cc54bb593b5ec3dc2be4b1702f50c36d24d5..e75214ea4936d2f2c909a71a1237042cc0e14b07 2024-10-18 13:56:15 +0000 to 2024-10-25 16:34:32 +0000 - refactor(env): remove unnecessary clones (rust-lang/cargo#14730) - test(install): Verify 2024 edition / resolver=3 doesn't affect resolution (rust-lang/cargo#14724) - Fix: trace `config` `[env]` table in dep-info. (rust-lang/cargo#14701) - Added unstable-schema generation for Cargo.toml (rust-lang/cargo#14683) - fix: add source replacement info when no matching package found (rust-lang/cargo#14715) - feat(complete): Include descriptions in zsh (rust-lang/cargo#14726) - refactor(fingerprint): avoid unnecessary fopen calls (rust-lang/cargo#14728) - docs(resolver): Make room for v3 resolver (rust-lang/cargo#14725) - test: add fixes in the sat resolver (rust-lang/cargo#14707) - docs(ci): Don't constrainty latest_deps job by MSRV (rust-lang/cargo#14711) - refactor: use `Iterator::is_sorted` (rust-lang/cargo#14702) - refactor(rustfix): minor refactors (rust-lang/cargo#14710) - chore(deps): update msrv (rust-lang/cargo#14705) - fix(renovate): Switch matchPackageNames to matchDepNames (rust-lang/cargo#14704)
- removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers
Revert rust-lang#127731 "Emit error when calling/declaring functions with unavailable …" This reverts rust-lang#127731 due to the unexpected [perf regressions](rust-lang#127731 (comment)) and to give time to mitigate the regressions before re-landing it. r? `@RalfJung` cc `@veluca93`
Use `Enabled{Lang,Lib}Feature` instead of n-tuples
Instead of passing around e.g. `(gate_name, attr_span, stable_since)` 3-tuples for enabled lang features or `(gate_name, attr_span)` 2-tuples for enabled lib features, use `Enabled{Lang,Lib}Feature` structs with named fields.
Also did some minor code-golfing of involved iterator chains to hopefully make them easier to follow.
Follow-up to rust-lang#132098 (comment) cc `@RalfJung.`
Update Fuchsia CI script for package serving This updates the "start" and "stop" methods of the test runner to use the standalone package server. r? `@tmandry`
…ler-errors Effects cleanup - removed extra bits from predicates queries that are no longer needed in the new system - removed the need for `non_erasable_generics` to take in tcx and DefId, removed unused arguments in callers r? compiler-errors
automatic PR: explain how to trigger CI
fix: Turn "Remove `dbg!`" into a quick fix for better prioritization
Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.
```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
--> $DIR/wf-static-type.rs:10:13
|
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
| ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
|
= note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
--> $DIR/wf-static-type.rs:7:17
|
LL | struct IsCopy<T:Copy> { t: T }
| ^^^^ required by this bound in `IsCopy`
```
vs the prior
```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
--> $DIR/wf-static-type.rs:10:13
|
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
| ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
|
= note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
--> $DIR/wf-static-type.rs:7:17
|
LL | struct IsCopy<T:Copy> { t: T }
| ^^^^ required by this bound in `IsCopy`
```
…rescope, r=traviscross,lcnr Stabilize if_let_rescope Close rust-lang#131154 Tracked by rust-lang#124085
…utlives, r=spastorino
Ensure that resume arg outlives region bound for coroutines
When proving that `{Coroutine}: 'region`, we must also prove that the coroutine's resume ty outlives that region as well. See the inline comment.
Fixes rust-lang#132104
Remove detail from label/note that is already available in other note
Remove the "which is required by `{root_obligation}`" post-script in
"the trait `X` is not implemented for `Y`" explanation in E0277. This
information is already conveyed in the notes explaining requirements,
making it redundant while making the text (particularly in labels)
harder to read.
```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
--> $DIR/wf-static-type.rs:10:13
|
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
| ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`
|
= note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
--> $DIR/wf-static-type.rs:7:17
|
LL | struct IsCopy<T:Copy> { t: T }
| ^^^^ required by this bound in `IsCopy`
```
vs the prior
```
error[E0277]: the trait bound `NotCopy: Copy` is not satisfied
--> $DIR/wf-static-type.rs:10:13
|
LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None };
| ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy`
|
= note: required for `Option<NotCopy>` to implement `Copy`
note: required by a bound in `IsCopy`
--> $DIR/wf-static-type.rs:7:17
|
LL | struct IsCopy<T:Copy> { t: T }
| ^^^^ required by this bound in `IsCopy`
```
*Ignore first three commits from rust-lang#132086
… r=nnethercote Cleanup op lookup in HIR typeck Minor cleanup for some redundant methods involved with looking up the `Operator::operator` methods for operators.
cg_llvm: Clean up FFI calls for setting module flags This is a combination of several inter-related changes to how module flags are set: - Remove some unnecessary code for setting an `"LTOPostLink"` flag, which has been obsolete since LLVM 17. - Define our own enum instead of relying on enum values defined by LLVM's unstable C++ API. - Use safe wrapper functions to set module flags, instead of direct `unsafe` calls. - Consistently pass pointer/length strings instead of C strings. - Remove or shrink some `unsafe` blocks.
…stable-attribute, r=joboet xous: sync: remove `rustc_const_stable` attribute on Condvar and Mutex new() These functions had `#[rustc_const_stable(feature = "const_locks", since = "1.63.0")]` on them because they were originally taken from `no_threads`. with d066dfd these no longer compile. Since other platforms do not have this attribute, remove it. This fixes the build for Xous.
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#131984 (Stabilize if_let_rescope) - rust-lang#132151 (Ensure that resume arg outlives region bound for coroutines) - rust-lang#132157 (Remove detail from label/note that is already available in other note) - rust-lang#132274 (Cleanup op lookup in HIR typeck) - rust-lang#132319 (cg_llvm: Clean up FFI calls for setting module flags) - rust-lang#132321 (xous: sync: remove `rustc_const_stable` attribute on Condvar and Mutex new()) r? `@ghost` `@rustbot` modify labels: rollup
This is a standard pattern: ``` MyAnalysis.into_engine(tcx, body).iterate_to_fixpoint() ``` `into_engine` and `iterate_to_fixpoint` are always called in pairs, but sometimes with a builder-style `pass_name` call between them. But a builder-style interface is overkill here. This has been bugging me a for a while. This commit: - Merges `Engine::new` and `Engine::iterate_to_fixpoint`. This removes the need for `Engine` to have fields, leaving it as a trivial type that the next commit will remove. - Renames `Analysis::into_engine` as `Analysis::iterate_to_fixpoint`, gives it an extra argument for the optional pass name, and makes it call `Engine::iterate_to_fixpoint` instead of `Engine::new`. This turns the pattern from above into this: ``` MyAnalysis.iterate_to_fixpoint(tcx, body, None) ``` which is shorter at every call site, and there's less plumbing required to support it.
It's no longer needed. `Engine::iterate_to_fixpoint` can be inlined into `Analysis::iterate_to_fixpoint` and removed. The commit also renames `engine.rs` as `results.rs`.
This test fails on targets without unwinding because the proc macro was compiled as the target, not the host. Some targets were explicitly disabled to pass CI, but these directives are more general. Fixes Fuchsia tests.
…oboet Use Hacker's Delight impl in `i64::midpoint` instead of wide `i128` impl This PR switches `i64::midpoint` and (`isize::midpoint` where `isize == i64`) to using our Hacker's Delight impl instead of wide `i128` implementation. As LLVM seems to be outperformed by the complexity of signed 128-bits number compared to our Hacker's Delight implementation.[^1] It doesn't seems like it's an improvement for the other sizes[^2], so we let them with the wide implementation. [^1]: https://rust.godbolt.org/z/ravE75EYj [^2]: https://rust.godbolt.org/z/fzr171zKh r? libs
…=Nadrieril Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains fixes rust-lang#128661 Is there any preference where the test goes? There looks to be several places it could fit.
TypingMode: merge intercrate, reveal, and defining_opaque_types This adds `TypingMode` and uses it in most places. We do not yet remove `Reveal` from `param_env`s. This and other future work as tracked in rust-lang#132279 and via `FIXME`s. Fetching the `TypingMode` of the `InferCtxt` asserts that the `TypingMode` agrees with `ParamEnv::reveal` to make sure we don't introduce any subtle bugs here. This will be unnecessary once `ParamEnv::reveal` no longer exists. As the `TypingMode` is now a part of the query input, I've merged the coherence and non-coherence caches for the new solver. I've also enabled the local `infcx` cache during coherence by clearing the cache when forking it with a different `TypingMode`. #### `TypingMode::from_param_env` I am using this even in cases where I know that the `param_env` will always be `Reveal::UserFacing`. This is to make it easier to correctly refactor this code in the future, any time we use `Reveal::UserFacing` in a body while not defining its opaque types is incorrect and should use a `TypingMode` which only reveals opaques defined by that body instead, cc rust-lang#124598 r? ``@compiler-errors``
…ainters, r=workingjubilee powerpc64-ibm-aix: update maintainters Chaofan (`@ecnelises)` and Kai (`@bzEq)` will be passing over maintainership for the target over to David Tenty (`@daltenty)` and Chris Cambly (`@gilamn5tr)`
…ners, r=compiler-errors Point to Fuchsia team in platform support docs This consolidates our docs into a single source of truth for the current Fuchsia maintainers. r? ```@tmandry```
…r=estebank Use `token_descr` more in error messages This is the first two commits from rust-lang#124141, put into their own PR to get things rolling. Commit messages have the details. r? ``@estebank`` cc ``@petrochenkov``
Remove `Engine` It's just unnecessary plumbing. Removing it results in less code, and simpler code. r? ``@cjgillot``
…rrors cg_llvm: Consistently use safe wrapper function `set_section` Follow-up to rust-lang#131962 and rust-lang#132260 (comment). To avoid too much scope creep, I've deliberately kept the changes to `LLVMRustGetSliceFromObjectDataByName` as minimal as possible.
…jubilee cg_llvm: Clean up FFI calls for operand bundles All of these FFI functions have equivalents in the stable LLVM-C API, though `LLVMBuildCallBr` requires a temporary polyfill on LLVM 18. This PR also creates a clear split between `OperandBundleOwned` and `OperandBundle`, and updates the internals of the owner to be a little less terrifying.
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#129394 (Don't lint `irrefutable_let_patterns` on leading patterns if `else if` let-chains) - rust-lang#131856 (TypingMode: merge intercrate, reveal, and defining_opaque_types) - rust-lang#132322 (powerpc64-ibm-aix: update maintainters) - rust-lang#132327 (Point to Fuchsia team in platform support docs) - rust-lang#132332 (Use `token_descr` more in error messages) - rust-lang#132338 (Remove `Engine`) - rust-lang#132340 (cg_llvm: Consistently use safe wrapper function `set_section`) - rust-lang#132342 (cg_llvm: Clean up FFI calls for operand bundles) r? `@ghost` `@rustbot` modify labels: rollup
Fix directives for lint-non-snake-case-crate This test fails on targets without unwinding or with `--target-rustcflags=-Cpanic=abort` because the proc macro was compiled as the target, not the host. Some targets were explicitly disabled to pass CI, but these directives are more general. * `needs-dynamic-linking` is self explanatory * `force-host` for proc macros * `no-prefer-dynamic` is apparently also used for proc macros Note that `needs-unwind` can also be useful for situations other than proc macros where unwinding is necessary. r? `@jieyouxu` try-job: test-various
sskeirik
approved these changes
Oct 30, 2024
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.
Resyncing master