| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Don't implement `AsyncFn` for `FnDef`/`FnPtr` that wouldnt implement `Fn`
Due to unsafety, ABI, or the presence of target features, some `FnDef`/`FnPtr` types don't implement `Fn*`. Do the same for `AsyncFn*`.
Noticed this due to #128764, but this isn't really related to that ICE, which is fixed in #128792.
|
|
Rollup of 7 pull requests
Successful merges:
- #128306 (Update NonNull::align_offset quarantees)
- #128612 (Make `validate_mir` ensure the final MIR for all bodies)
- #128648 (Add regression test)
- #128749 (Mark `{f32,f64}::{next_up,next_down,midpoint}` inline)
- #128795 (Update E0517 message to reflect RFC 2195.)
- #128825 (rm `declared_features` field in resolver)
- #128826 (Only suggest `#[allow]` for `--warn` and `--deny` lint level flags)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Only suggest `#[allow]` for `--warn` and `--deny` lint level flags
`--force-warn` and `--forbid` cannot be overridden
|
|
Add regression test
Fixes #125873
|
|
Make `validate_mir` ensure the final MIR for all bodies
A lot of the crashes tests use `-Zpolymorphize` or `-Zdump-mir` for their side effect of computing the `optimized_mir` for all bodies, which will uncover bugs with late MIR passes like the inliner. I don't like having all these tests depend on `-Zpolymorphize` (or other hacky ways) for no reason, so this PR extends the `-Zvalidate-mir` flag to ensure `optimized_mir`/`mir_for_ctfe` for all body owners during the analysis phase.
Two thoughts:
1. This could be moved later in the compilation pipeline I guess? I don't really think it matters, though.
1. This could alternatively be expressed using a new flag, though I don't necessarily see much value in separating these.
For example, #128171 could have used this flag, in the `tests/ui/polymorphization/inline-incorrect-early-bound.rs`.
r? mir
|
|
|
|
|
|
|
|
Add tracking issue to core-pattern-type
While the actual `pattern_types` feature flag has an issue assigned, the exported macro and its module do not.
cc #123646
|
|
Add -Zmetrics-dir=PATH to save diagnostic metadata to disk
r? ``@estebank``
|
|
Emit an error for invalid use of the `#[no_sanitize]` attribute
fixes #128487.
Currently, the use of the `#[no_sanitize]` attribute for Mod, Impl,... is incorrectly permitted. This PR will correct this issue by generating errors, and I've also added some UI test cases for it.
Referenced #128458. As far as I know, the `#[no_sanitize]` attribute can only be used with functions, so I changed that part to `Fn` and `Method` using `check_applied_to_fn_or_method`. However, I couldn't find explicit documentation on this, so I could be mistaken...
|
|
Skip over args when determining if async-closure's inner coroutine consumes its upvars
#125306 implements a strategy for when we have an `async move ||` async-closure that is inferred to be `async FnOnce`, it will force the inner coroutine to also be `move`, since we cannot borrow any upvars from the parent async-closure (since `FnOnce` is not lending):
https://github.com/rust-lang/rust/blob/8e86c9567154dc5a9ada15ab196d23eae2bd7d89/compiler/rustc_hir_typeck/src/upvar.rs#L211-L229
However, when this strategy was implemented, it reused the `ExprUseVisitor` data from visiting the whole coroutine, which includes additional statements due to `async`-specific argument desugaring:
https://github.com/rust-lang/rust/blob/8e86c9567154dc5a9ada15ab196d23eae2bd7d89/compiler/rustc_ast_lowering/src/item.rs#L1197-L1228
Well, it turns out that we don't care about these argument desugaring parameters, because arguments to the async-closure are not the *async-closure*'s captures -- they exist for only one invocation of the closure, and they're always consumed by construction (see the argument desugaring above), so they will force the coroutine's inferred kind to `FnOnce`. (Unless they're `Copy`, because we never consider `Copy` types to be consumed):
https://github.com/rust-lang/rust/blob/8e86c9567154dc5a9ada15ab196d23eae2bd7d89/compiler/rustc_hir_typeck/src/expr_use_visitor.rs#L60-L66
However, since we *were* visiting these arg exprs, this resulted in us too-aggressively applying `move` to the inner coroutine, resulting in regressions. For example, this PR fixes #128516. Fascinatingly, the note above about how we never consume `Copy` types is why this only regressed when the argument types weren't all `Copy`.
I tried to leave some comments inline to make this more clear :)
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #128363 (Migrate `pdb-buildinfo-cl-cmd` and `pgo-indirect-call-promotion` `run-make` tests to rmake)
- #128384 (Add tests to ensure MTE tags are preserved across FFI boundaries)
- #128636 (migrate `thumb-none-cortex-m` to rmake)
- #128696 (Migrate `staticlib-dylib-linkage` `run-make` test to rmake)
Failed merges:
- #128407 (Migrate `min-global-align` and `no-alloc-shim` `run-make` tests to rmake)
- #128639 (migrate `thumb-none-qemu` to rmake)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rollup of 8 pull requests
Successful merges:
- #128221 (Add implied target features to target_feature attribute)
- #128261 (impl `Default` for collection iterators that don't already have it)
- #128353 (Change generate-copyright to generate HTML, with cargo dependencies included)
- #128679 (codegen: better centralize function declaration attribute computation)
- #128732 (make `import.vis` is immutable)
- #128755 (Integrate crlf directly into related test file instead via of .gitattributes)
- #128772 (rustc_codegen_ssa: Set architecture for object crate for 32-bit SPARC)
- #128782 (unused_parens: do not lint against parens around &raw)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
unused_parens: do not lint against parens around &raw
Requested by `@tmandry` in https://github.com/rust-lang/rust/pull/127679: with `&raw` one somewhat regularly has to write code like `(&raw const (*myptr).field).method()`, so parentheses around the expression are often required. To avoid churn between adding and removing parentheses as method calls appear and disappear, the proposal was made to silence the lint for unnecessary parentheses around `&raw` expressions. This PR implements that.
|
|
Integrate crlf directly into related test file instead via of .gitattributes
resolves https://github.com/rust-lang/rust/issues/128708
This PR seeks to resolve a contributor papercut when using jj to manage the git repo locally which does not support .gitattributes. It does so by integrating the crlf characters directly into the related test and disabling Git's end of line normalization logic across platforms for that specific file, instead of configuring git to always check out the files with alternative eol characters.
related documentation: https://git-scm.com/docs/gitattributes#Documentation/gitattributes.txt-Unset-1
|
|
Add implied target features to target_feature attribute
See [zulip](https://rust-lang.zulipchat.com/#narrow/stream/208962-t-libs.2Fstdarch/topic/Why.20would.20target-feature.20include.20implied.20features.3F) for some context. Adds implied target features, e.g. `#[target_feature(enable = "avx2")]` acts like `#[target_feature(enable = "avx2,avx,sse4.2,sse4.1...")]`. Fixes #128125, fixes #128426
The implied feature sets are taken from [the rust reference](https://doc.rust-lang.org/reference/attributes/codegen.html?highlight=target-fea#x86-or-x86_64), there are certainly more features and targets to add.
Please feel free to reassign this to whoever should review it.
r? ``@Amanieu``
|
|
|
|
Migrate `staticlib-dylib-linkage` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
I'm quite sure this has the same issue as the one brought up in [this discussion](https://github.com/rust-lang/rust/pull/128407#discussion_r1702439172), so I elected to keep the ignore MSVC.
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-17
try-job: armhf-gnu
|
|
migrate `thumb-none-cortex-m` to rmake
tracking issue: https://github.com/rust-lang/rust/issues/121876
I'll leave some comments/questions inline
r? ```@jieyouxu```
try-job: armhf-gnu
try-job: dist-various-1
try-job: test-various
|
|
Add tests to ensure MTE tags are preserved across FFI boundaries
Added run-make tests to verify that, between a Rust-C FFI boundary in both directions, any MTE tags included in a pointer are preserved for the following pointer types, as well as any information stored using TBI:
- int
- float
- string
- function
try-job: aarch64-gnu
|
|
Disallow setting some built-in cfg via set the command-line
This PR disallow users from setting some built-in cfg via set the command-line in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based.
This implements MCP https://github.com/rust-lang/compiler-team/issues/610, with the caveat that we disallow cfgs no matter if they make sense or not, since I don't think it's useful to allow users to set a cfg that will be set anyway. It also complicates the implementation.
------
The `explicit_builtin_cfgs_in_flags` lint detects builtin cfgs set via the `--cfg` flag.
*(deny-by-default)*
### Example
```text
rustc --cfg unix
```
```rust,ignore (needs command line option)
fn main() {}
```
This will produce:
```text
error: unexpected `--cfg unix` flag
|
= note: config `unix` is only supposed to be controlled by `--target`
= note: manually setting a built-in cfg can and does create incoherent behaviours
= note: `#[deny(explicit_builtin_cfgs_in_flags)]` on by default
```
### Explanation
Setting builtin cfgs can and does produce incoherent behaviour, it's better to the use the appropriate `rustc` flag that controls the config. For example setting the `windows` cfg but on Linux based target.
-----
r? `@petrochenkov`
cc `@jyn514`
try-job: aarch64-apple
try-job: test-various
try-job: armhf-gnu
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
try-job: dist-various-1
|
|
|
|
|
|
|
|
Migrate `pgo-gen-lto` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This one is so easy, I'm surprised I missed it.
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
|
|
Don't arbitrarily choose one upper bound for hidden captured region error message
You could argue that the error message is objectively worse, even though it's more accurate. I guess we could also add a note explaining like "cannot capture the intersection of two regions" or something, though I'm not sure if that is confusing due to being totally technical jargon.
This addresses the fact that #128752 says "add `+ 'b`" even though it does nothing to fix the issue. It doesn't fix the issue's root cause, though.
r? `@spastorino`
|
|
r=jieyouxu
Migrate `simd-ffi` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-17
|
|
Enable msvc for run-make/rust-lld
This is simply a matter of using the right argument for lld-link.
As a bonus, I also fixed a typo.
try-job: i686-msvc
try-job: x86_64-msvc
|
|
More information for fully-qualified suggestion when there are multiple impls
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> $DIR/E0283.rs:30:21
|
LL | fn create() -> u32;
| ------------------- `Coroutine::create` defined here
...
LL | let cont: u32 = Coroutine::create();
| ^^^^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation
|
LL | let cont: u32 = <Impl as Coroutine>::create();
| ++++++++ +
LL | let cont: u32 = <AnotherImpl as Coroutine>::create();
| +++++++++++++++ +
```
|
|
|
|
|
|
Migrate `cross-lang-lto-upstream-rlibs`, `long-linker-command-lines` and `long-linker-command-lines-cmd-exe` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The `long-linker` tests are certainly doing something... interesting - they summon `rustc` calls with obscene quantities of arguments and check that this is appropriately handled. I removed the `RUSTC_ORIGINAL` magic - it's equivalent to `RUSTC` in `tools.mk`, so what is the purpose? Making it so the massive pile of flags doesn't modify rustc itself and start leaking into other tests? Tell me what you think.
Please try:
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw
try-job: i686-mingw
try-job: aarch64-apple
try-job: test-various
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-17
|
|
|
|
|
|
|
|
|
|
|
|
|
|
run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`
The common thing between these two tests is to use `#[link(..., kind="static")]` so that it doesn't try to do a DLL import.
`zero-extend-abi-param-passing` also needs to have an optimized static library but there's only helper function for a non-optimized version. Rather than copy/pasting the code (and adding the optimization flag) I reused the same code so that it more easily be kept in sync.
try-job: i686-msvc
try-job: x86_64-msvc
|
|
Enable msvc for link-args-order
I could not see any reason in #70665 why this test needs to specifically use `ld`. Maybe to provide a consistent linker input line? In any case, the test does work for the MSVC linker.
try-job: i686-msvc
try-job: x86_64-msvc
|
|
run-make: enable msvc for `link-dedup`
This is just a case of differing style of linker arguments.
I also cleaned up a bit where we were running the same command three times in a row. Instead I reused the output.
One thing that confused me is why we were testing for the same lib three times in a row but not two. After figuring that out I added a note to hopefully save future readers some confusion.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
add test for symbol visibility of `#[naked]` functions
tracking issue: #90957
This test is extracted from https://github.com/rust-lang/rust/pull/128004
That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.
In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.
Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.
Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.
r? ``@bjorn3``
|
|
Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
// try-job: x86_64-msvc
// try-job: x86_64-mingw
// try-job: i686-msvc
try-job: x86_64-gnu-llvm-17
try-job: aarch64-apple
|
|
Rollup of 9 pull requests
Successful merges:
- #124944 (On trait bound mismatch, detect multiple crate versions in dep tree)
- #125048 (PinCoerceUnsized trait into core)
- #128406 (implement BufReader::peek)
- #128539 (Forbid unused unsafe in vxworks-specific std modules)
- #128687 (interpret: refactor function call handling to be better-abstracted)
- #128692 (Add a triagebot mention for `library/Cargo.lock`)
- #128710 (Don't ICE when getting an input file name's stem fails)
- #128718 (Consider `cfg_attr` checked by `CheckAttrVisitor`)
- #128751 (std::thread: set_name implementation proposal for vxWorks.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Consider `cfg_attr` checked by `CheckAttrVisitor`
I forgor about `cfg_attr` in #128581, it should be treated like `cfg`.
Fixes #128716.
|
|
Don't ICE when getting an input file name's stem fails
Fixes #128681
The file stem is only used as a user-friendly prefix on intermediary files. While nice to have, it's not the end of the world if it fails so there's no real reason to emit an error here. We can continue with a fixed name as we do when an anonymous string is used.
|
|
|
