| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Detect struct construction with private field in field with default
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor-2.rs:19:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor-2.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the type `Priv1` of field `field1` is private, but you can construct the default value defined for it in `S` using `..` in the struct initializer expression
|
LL | let _ = S { field: (), .. };
| ~~
```
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144553 (Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`)
- rust-lang/rust#145064 (Add regression test for `saturating_sub` bounds check issue)
- rust-lang/rust#145121 (bootstrap: `x.py dist rustc-src` should keep LLVM's siphash)
- rust-lang/rust#145150 (Replace unsafe `security_attributes` function with safe `inherit_handle` alternative)
- rust-lang/rust#145152 (Use `eq_ignore_ascii_case` to avoid heap alloc in `detect_confuse_type`)
- rust-lang/rust#145200 (mbe: Fix typo in attribute tracing)
- rust-lang/rust#145222 (Fix typo with paren rustc_llvm/build.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add regression test for `saturating_sub` bounds check issue
Add codegen test for issue where `valid_index.saturating_sub(X)` produced an extra bounds check.
This was fixed by the LLVM upgrade.
Closes rust-lang/rust#139759
|
|
Rehome 32 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
|
|
When trying to construct a struct that has a public field of a private type, suggest using `..` if that field has a default value.
```
error[E0603]: struct `Priv1` is private
--> $DIR/non-exhaustive-ctor.rs:25:39
|
LL | let _ = S { field: (), field1: m::Priv1 {} };
| ------ ^^^^^ private struct
| |
| while setting this field
|
note: the struct `Priv1` is defined here
--> $DIR/non-exhaustive-ctor.rs:14:4
|
LL | struct Priv1 {}
| ^^^^^^^^^^^^
help: the field `field1` you're trying to set has a default value, you can use `..` to use it
|
LL | let _ = S { field: (), .. };
| ~~
```
|
|
Start reporting future breakage for `ILL_FORMED_ATTRIBUTE_INPUT` in dependencies
This has been a warn lint since early 2019 and a deny-by-default lint since late 2019.
We're currently transitioning some of the cases where this lint is being produced to a hard error (https://github.com/rust-lang/rust/pull/143607 https://github.com/rust-lang/rust/pull/143808 and more)
So let's report this lint in all dependencies for the remaining attributes
r? `@traviscross`
`@rustbot` labels +I-lang-nominated +T-lang -T-compiler
cc `@jdonszelmann`
(Separate question: Why does the "Future incompatibility report" only trigger if `report_in_deps` is true, even if the future incompatibility happens in the same crate, is this correct?)
This also needs a crater run, but I don't have permissions to trigger this
|
|
|
|
Rollup of 17 pull requests
Successful merges:
- rust-lang/rust#141624 (unstable-book: Add stubs for environment variables; document some of the important ones)
- rust-lang/rust#143093 (Simplify polonius location-sensitive analysis)
- rust-lang/rust#144402 (Stabilize loongarch32 inline asm)
- rust-lang/rust#144403 (`tests/ui/issues/`: The Issues Strike Back [4/N])
- rust-lang/rust#144739 (Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc)
- rust-lang/rust#145089 (Improve error output when a command fails in bootstrap)
- rust-lang/rust#145112 ([win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC)
- rust-lang/rust#145129 ([win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC)
- rust-lang/rust#145130 (improve "Documentation problem" issue template.)
- rust-lang/rust#145135 (Stabilize `duration_constructors_lite` feature)
- rust-lang/rust#145145 (some `derive_more` refactors)
- rust-lang/rust#145147 (rename `TraitRef::from_method` to `from_assoc`)
- rust-lang/rust#145156 (Override custom Cargo `build-dir` in bootstrap)
- rust-lang/rust#145160 (Change days-threshold to 28 in [behind-upstream])
- rust-lang/rust#145162 (`{BTree,Hash}Map`: add "`Entry` API" section heading)
- rust-lang/rust#145187 (Fix an unstable feature comment that wasn't a doc comment)
- rust-lang/rust#145191 (`suggest_borrow_generic_arg`: use the correct generic args)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`suggest_borrow_generic_arg`: use the correct generic args
The suggestion now gets calls' generic arguments from the callee's type to handle cases where the callee isn't an identifier expression. Fixes rust-lang/rust#145164.
|
|
[win][arm64ec] Partial fix for raw-dylib-link-ordinal on Arm64EC
These are the test fixes required to get `raw-dylib-link-ordinal` working on Arm64EC.
For the test to completely pass, we also need an updated `ar_archive_writer` with <https://github.com/rust-lang/ar_archive_writer/pull/24> merged in.
|
|
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
|
|
Stabilize loongarch32 inline asm
r? ````````@Amanieu````````
|
|
Simplify polonius location-sensitive analysis
This PR reworks the location-sensitive analysis into what we think is a worthwhile subset of the datalog analysis. A sort of polonius alpha analysis that handles NLL problem case 3 and more, but is still using the faster "reachability as an approximation of liveness", as well as the same loans-in-scope computation as NLLs -- and thus doesn't handle full flow-sensitivity like the datalog implementation.
In the last few months, we've identified this subset as being actionable:
- we believe we can make a stabilizable version of this analysis
- it is an improvement over the status quo
- it can also be modeled in a-mir-formality, or some other formalism, for assurances about soundness, and I believe ````````@nikomatsakis```````` is interested in looking into this during H2.
- and we've identified the areas of work we wish to explore later to gradually expand the supported cases: the differences between reachability and liveness, support of kills, and considerations of time-traveling, for example.
The approach in this PR is to try less to have the graph only represent live paths, by checking whether we reach a live region during traversal and recording the loan as live there, instead of equating traversal with liveness like today because it has subtleties with the typeck edges in statements (that could forward loans to the successor point without ensuring their liveness). We can then also simplify these typeck stmt edges. And we also can simplify traversal by removing looking at kills, because that's enough to handle a bunch of NLL problem 3 cases -- and we can gradually support them more and more in traversal in the future, to reduce the approximation of liveness.
There's still some in-progress pieces of work w/r/t opaque types that I'm expecting [lcnr's opaque types rework](https://github.com/rust-lang/rust/pull/139587), and [amanda's SCCs rework](https://github.com/rust-lang/rust/pull/130227) to handle. That didn't seem to show up in tests until I rebased today (and shows lack of test coverage once again) when https://github.com/rust-lang/rust/pull/142255 introduced a couple of test failures with the new captures rules from edition 2024. It's not unexpected since we know more work is needed with member constraints (and we're not even using SCCs in this prototype yet)
I'll look into these anyways, both for future work, and checking how these other 2 PRs would change things.
---
I'm not sure the following means a lot until we have some formalism in-place, but:
- I've changed the polonius compare-mode to use this analysis: the tests pass with it, except 2 cases with minor diagnostics differences, and the 2 edition 2024 opaque types one I mentioned above and need to investigate
- things that are expected to work still do work: it bootstraps, can run our rustc-perf benchmarks (and the results are not even that bad), and a crater run didn't find any regressions (forgetting that crater currently fails to test around a quarter of all crates 👼)
- I've added tests with improvements, like the NLL problem case 3 and others, as well as some that behave the same as NLLs today and are thus worse than the datalog implementation
r? ````````@jackh726````````
(no rush I know you're deep in phd work and "implmentating" the new trait solver for r-a :p <3)
This also fixes rust-lang/rust#135646, a diagnostics ICE from the previous implementation.
|
|
Stop using uadd.with.overflow
As discussed in [#t-compiler/llvm > `uadd.with.overflow` (again) @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/.60uadd.2Ewith.2Eoverflow.60.20.28again.29/near/533041085), stop emitting `uadd.with.overflow` in favour of `add`+`icmp` instead.
r? nikic
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
remove `P`
Previous work: rust-lang/rust#141603
MCP: https://github.com/rust-lang/compiler-team/issues/878
cc `@nnethercote`
|
|
|
|
Rollup of 23 pull requests
Successful merges:
- rust-lang/rust#141658 (rustdoc search: prefer stable items in search results)
- rust-lang/rust#141828 (Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code)
- rust-lang/rust#144823 (coverage: Extract HIR-related helper code out of the main module)
- rust-lang/rust#144883 (Remove unneeded `drop_in_place` calls)
- rust-lang/rust#144923 (Move several more float tests to floats/mod.rs)
- rust-lang/rust#144988 (Add annotations to the graphviz region graph on region origins)
- rust-lang/rust#145010 (Couple of minor abi handling cleanups)
- rust-lang/rust#145017 (Explicitly disable vector feature on s390x baseline of bad-reg test)
- rust-lang/rust#145027 (Optimize `char::is_alphanumeric`)
- rust-lang/rust#145050 (add member constraints tests)
- rust-lang/rust#145073 (update enzyme submodule to handle llvm 21)
- rust-lang/rust#145080 (Escape diff strings in MIR dataflow graphviz)
- rust-lang/rust#145082 (Fix some bad formatting in `-Zmacro-stats` output.)
- rust-lang/rust#145083 (Fix cross-compilation of Cargo)
- rust-lang/rust#145096 (Fix wasm target build with atomics feature)
- rust-lang/rust#145097 (remove unnecessary `TypeFoldable` impls)
- rust-lang/rust#145100 (Rank doc aliases lower than equivalently matched items)
- rust-lang/rust#145103 (rustc_metadata: remove unused private trait impls)
- rust-lang/rust#145115 (defer opaque type errors, generally greatly reduce tainting)
- rust-lang/rust#145119 (rustc_public: fix missing parenthesis in pretty discriminant)
- rust-lang/rust#145124 (Recover `for PAT = EXPR {}`)
- rust-lang/rust#145132 (Refactor map_unit_fn lint)
- rust-lang/rust#145134 (Reduce indirect assoc parent queries)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Recover `for PAT = EXPR {}`
I type this constantly, and the existing suggestion to put `in` before the `=` is misleading.
|
|
rustc_public: fix missing parenthesis in pretty discriminant
|
|
defer opaque type errors, generally greatly reduce tainting
fixes the test for rust-lang/rust#135528, does not actually fix that issue properly.
This is useful as it causes the migration to rust-lang/rust#139587 to be a lot easier.
|
|
Rank doc aliases lower than equivalently matched items
Follow-up of https://github.com/rust-lang/rust/pull/143988.
cc `@lolbinarycat`
|
|
Fix some bad formatting in `-Zmacro-stats` output.
r? `@petrochenkov`
|
|
add member constraints tests
taken from rust-lang/rust#139587.
|
|
Explicitly disable vector feature on s390x baseline of bad-reg test
If the baseline s390x cpu is changed to a newer variant, such as z13, the vector feature may be enabled by default. When rust is packaged on fedora 38 and newer, it is set to z13.
Explicitly disable vector support on the baseline test for consistent results across s390x cpus.
|
|
Remove unneeded `drop_in_place` calls
Might as well pull this out from rust-lang/rust#144561 because this is still used in things like `Vec::truncate` where it'd be nice to allow it be removed if inlined enough to see that the type is `Copy`.
So long as perf says it's ok, at least 🤞
|
|
r=GuillaumeGomez
rustdoc search: prefer stable items in search results
fixes https://github.com/rust-lang/rust/issues/138067
this does add a new field to the search index, but since we're only listing unstable items instead of adding a boolean flag to every item, it should only increase the search index size of sysroot crates, since those are the only ones using the `staged_api` feature, at least as far as the rust project is concerned.
|
|
add a scope for `if let` guard temporaries and bindings
This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.
This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).
Tracking issue for `if_let_guard`: rust-lang/rust#51114
Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
|
|
Revert "Port `#[allow_internal_unsafe]` to the new attribute system"
This reverts commit 4f7a6ace9e2f2192af7b5d32f4b1664189e0e143 (PR: https://github.com/rust-lang/rust/pull/144857)
r? `@Kobzol`
cc: `@scrabsha`
clean revert it seems :3
|
|
|
|
Account for bare tuples and `Pin` methods in field searching logic
When looking for the field names and types of a given type, account for tuples. This allows suggestions for incorrectly nested field accesses and field name typos to trigger as intended. Previously these suggestions only worked on `ty::Adt`, including tuple structs which are no different to tuples, so they should behave the same in suggestions.
When suggesting field access which would encounter a method not found, do not suggest pinning when those methods are on `impl Pin` itself.
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: one of the expressions' fields has a method of the same name
|
LL | let x = f.0.get_ref();
| ++
```
instead of
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(f);
LL ~ let x = pinned.as_ref().get_ref();
|
```
Fix rust-lang/rust#144602.
|
|
Implement declarative (`macro_rules!`) attribute macros (RFC 3697)
This implements [RFC 3697](https://github.com/rust-lang/rust/issues/143547), "Declarative (`macro_rules!`) attribute macros".
I would suggest reading this commit-by-commit. This first introduces the
feature gate, then adds parsing for attribute rules (doing nothing with them),
then adds the ability to look up and apply `macro_rules!` attributes by path,
then adds support for local attributes, then adds a test, and finally makes
various improvements to errors.
|
|
In rustc_pattern_analysis, put `true` witnesses before `false` witnesses
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
r? `@Nadrieril`
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
|
|
|
|
|
|
This allows a macro attribute to implement default arguments by
reapplying itself with the defaults filled in, for instance.
|
|
|
|
|
|
|
|
Test macros via path and local macros.
|
|
Avoid saying "a declarative macro cannot be used as an attribute macro";
instead, say that the macro has no `attr` rules.
|
|
This handles various kinds of errors, but does not allow applying the
attributes yet.
This adds the feature gate `macro_attr`.
|
|
|
|
Now that `macro_rules` macros can define attribute rules, make sure
error messages account for that.
|
|
|
