| Age | Commit message (Collapse) | Author | Lines |
|---|
|
JetBrains has transitioned from the IntelliJ Rust plugin to RustRover as
their dedicated Rust IDE. This updates the documentation to reflect this
change while maintaining backward compatibility with the existing `cargo
dev setup intellij` command.
Changes:
- Replace IntelliJ Rust references with RustRover in CONTRIBUTING.md
- Update links to point to official RustRover homepage
- Update development guide in book/src/development/basics.md
- Keep existing command names for backward compatibility
**Question**: Do we also need to change the `intellij` command to
`rustrover`?
fixes rust-lang/rust-clippy#15406
changelog: Update CONTRIBUTING.md to reference RustRover instead of
deprecated IntelliJ Rust
|
|
limit
When doing lto, rustc generates filenames that are concatenating many information.
In the case of this testcase, it is concatenating crate name and rust file name, plus some hash, and the extension.
In some other cases it will concatenate even more information reducing the maximum effective crate name to about 110 chars on linux filesystems where
filename max length is 255
This commit is ensuring that the temporary file names are limited in size, while still reasonabily ensuring the unicity (with hashing of the stripped part)
|
|
|
|
|
|
|
|
|
|
As suggested in
https://github.com/rust-lang/rust-clippy/pull/15268#discussion_r2249249661
WIP because:
- [x] what should be done with the now-error-pattern-less
`tests/ui/double_ended_iterator_last_unfixable.rs`?
- [x] is the change in behaviour of `double_ended_iterator_last` okay in
general?
- cc @samueltardieu because this changes the code you added in
https://github.com/rust-lang/rust-clippy/pull/14140
changelog: none
r? @y21
|
|
|
|
|
|
|
|
|
|
`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.
|
|
Fix an unstable feature comment that wasn't a doc comment
Every other feature in the list uses a doc comment; fix one that used a regular comment to use a doc comment.
|
|
r=joshtriplett
`{BTree,Hash}Map`: add "`Entry` API" section heading
I wanted to link to an introduction of the `Entry` API to the help message of `clippy::map_entry` (see https://github.com/rust-lang/rust-clippy/issues/11598 for motivation), but I found the documentation on the `Entry` enum itself a bit short. On the other hand, `{BTree,Hash}Map` both have sections in their docs introducing the whole API and giving usage examples, and so I would like to link to that instead. For that, I introduce the "`Entry` API" section heading to both of them.
Do let me know whether you think this is the right approach.
|
|
Change days-threshold to 28 in [behind-upstream]
Make the days-threshold to 28 to reduce false positives.
[#triagebot > Outdated commit message](https://rust-lang.zulipchat.com/#narrow/channel/224082-triagebot/topic/Outdated.20commit.20message)
r? ``````@Urgau``````
cc ``````@jieyouxu``````
|
|
Override custom Cargo `build-dir` in bootstrap
The context for this issue is in https://github.com/rust-lang/rust/issues/145107. The issue is that if people configure `build-dir`, it would break bootstrap. For now, we just hard-code it to our self-contained target directories inside the build directory.
Tested by putting the following:
```toml
[build]
build-dir = "/tmp/foo"
[unstable]
build-dir = true
```
into `<rustc-checkout>/.cargo/config.toml`. `x build` works with this PR, doesn't work without this PR.
Fixes: https://github.com/rust-lang/rust/issues/145107
|
|
rename `TraitRef::from_method` to `from_assoc`
also add a note to `GenericArgs::truncate_to`
|
|
some `derive_more` refactors
some clauses can be merged together without requiring an attribute for each trait derived.
also manually impl `Eq` because the `derive_where` generated code is too much for my comfort (cc https://github.com/ModProg/derive-where/pull/128)
|
|
r=ChrisDenton
Stabilize `duration_constructors_lite` feature
This closes [tracking issue](https://github.com/rust-lang/rust/issues/140881) and stabilises `Duration::from_hours` and `Duration::from_mins` while not touching a `duration_constructors` feature from the related [tracking issue (2)](https://github.com/rust-lang/rust/issues/120301)
|
|
improve "Documentation problem" issue template.
rustdoc has its own issue template now, mention that.
swap the order of the last two sentances so it reads more like a typical if/else chain (base case listed last).
|
|
[win][arm64ec] Add `/machine:arm64ec` when linking LLVM as Arm64EC
When the MSVC linker sees an Arm64EC object file, it needs to know if it's linking the final executable as Arm64EC or Arm64X.
This change adds the `/machine:arm64ec` flag to the linker when building LLVM as Arm64EC to avoid that ambiguity (and resulting linker error).
|
|
[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.
|
|
Improve error output when a command fails in bootstrap
I fixed this because it was being an issue for debugging CI failures.
We try to print as much information as possible, just with a slightly less verbose command description in non-verbose mode. The code is now more unified and hopefully simpler to understand.
I also fixed the `format_short_cmd` logic, it was a bit weird after some recent refactors.
Fixes: https://github.com/rust-lang/rust/issues/145002
r? `````````@jieyouxu`````````
CC `````````@Shourya742`````````
|
|
Use new public libtest `ERROR_EXIT_CODE` constant in rustdoc
Followup of rust-lang/rust#144297.
|
|
`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.
|
|
unstable-book: Add stubs for environment variables; document some of the important ones
This uses a very hacky regex that will probably miss some variables. But having some docs seems better than none at all.
In particular, this documents the following env vars explicitly (cc ````````@madsmtm```````` ````````@flba-eb```````` - do the docs for SDKROOT and QNX_TARGET look right?):
- COLORTERM
- QNX_TARGET
- SDKROOT
- TERM
and generates stubs for the following env vars:
- RUST_BACKTRACE
- RUSTC_BLESS
- RUSTC_BREAK_ON_ICE
- RUSTC_CTFE_BACKTRACE
- RUSTC_FORCE_RUSTC_VERSION
- RUSTC_GRAPHVIZ_FONT
- RUSTC_ICE
- RUSTC_LOG
- RUSTC_RETRY_LINKER_ON_SEGFAULT
- RUSTC_TRANSLATION_NO_DEBUG_ASSERT
- RUST_DEP_GRAPH_FILTER
- RUST_DEP_GRAPH
- RUST_FORBID_DEP_GRAPH_EDGE
- RUST_MIN_STACK
- RUST_TARGET_PATH
- UNSTABLE_RUSTDOC_TEST_LINE
- UNSTABLE_RUSTDOC_TEST_PATH
rendered: 
|
|
|
|
|
|
|
|
|
|
As they were previously.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
Fix extract_expressions_from_format_string on write!
|
|
parser: fix parsing of trait bound polarity and for-binders
|
|
**Input**:
```rust
fn main() {
write!(f, "{2+3}$0")
}
```
**Old output**:
```rust
fn main() {
write!("{}"$0, 2+3)
}
```
**This PR output**:
```rust
fn main() {
write!(f, "{}"$0, 2+3)
}
```
|
|
|
|
|
|
The rustc AST allows both `for<>` binders and `?` polarity
modifiers in trait bounds, but they are parsed in a specific
order and validated for correctness:
1. `for<>` binder is parsed first.
2. Polarity modifiers (`?`, `!`) are parsed second.
3. The parser validates that binders and polarity modifiers
do not conflict:
```rust
if let Some(binder_span) = binder_span {
match modifiers.polarity {
BoundPolarity::Maybe(polarity_span) => {
// Error: "for<...> binder not allowed with ? polarity"
}
}
}
```
This implies:
- `for<> ?Sized` → Valid syntax. Invalid semantics.
- `?for<> Sized` → Invalid syntax.
However, rust-analyzer incorrectly had special-case logic that
allowed `?for<>` as valid syntax. This fix removes that incorrect
special case, making rust-analyzer reject `?for<> Sized` as a
syntax error, matching rustc behavior.
This has caused confusion in other crates (such as syn) which
rely on these files to implement correct syntax evaluation.
|
|
|
|
Implement `stability_implications` without a visitor.
Since https://github.com/rust-lang/rust/pull/143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
|
