| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix: Temporary fix for `remove_unused_imports` not handling import aliases correctly
Fixes #18129
|
|
Revert "Apply EarlyOtherwiseBranch to scalar value #129047"
This reverts PR #129047, commit a772336fb3fbd1fe4493077fcfe04e0221296a99, reversing changes made to 702987f75b74f789ba227ee04a3d7bb1680c2309.
cc `@DianQK` and `@cjgillot` as the PR author and reviewer of #129047 respectively.
It seems [Apply EarlyOtherwiseBranch to scalar value #129047](https://github.com/rust-lang/rust/pull/129047) may have lead to several nightly regressions:
- https://github.com/rust-lang/rust/issues/130769
- https://github.com/rust-lang/rust/issues/130774
- https://github.com/rust-lang/rust/issues/130771
Example test that would ICE with changes in #129047 (this test is included in this PR):
```rs
//@ compile-flags: -C opt-level=3
//@ check-pass
use std::task::Poll;
pub fn poll(val: Poll<Result<Option<Vec<u8>>, u8>>) {
match val {
Poll::Ready(Ok(Some(_trailers))) => {}
Poll::Ready(Err(_err)) => {}
Poll::Ready(Ok(None)) => {}
Poll::Pending => {}
}
}
```
Since this is a mir-opt ICE that seems to quite easy to trigger with real-world crates being affected, let's revert for now and reland the mir-opt after these are fixed.
|
|
correctly
|
|
|
|
|
|
llvm: replace some deprecated functions
`LLVMMDStringInContext` and `LLVMMDNodeInContext` are deprecated, replace them with `LLVMMDStringInContext2` and `LLVMMDNodeInContext2`.
Also replace `Value` with `Metadata` in some function signatures for better consistency.
|
|
|
|
|
|
Previously if you pass compiler stage 1 to `tool::Cargo`, it will build
stage2 rustc and give you back a cargo built with stage2 rustc, which is
not what we want.
This commit adds a hack that chops off a stage from the compiler passed
to `tool::Cargo`, meaning that we will get a cargo built with stage 1
compiler, avoiding unnecessary and incorrect build of stage2 rustc and
the cargo built by that.
|
|
fix: Fix a bug in span map merge, and add explanations of how span maps are stored
Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.
The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.
Fixes #18163.
|
|
fix: Better support references in consuming postfix completions
Fixes #18155.
|
|
fix: Fix name resolution when an import is resolved to some namespace and then later in the algorithm another namespace is added
The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.
This issue was tried to fix in https://github.com/rust-lang/rust-analyzer/pull/2466, but it was not fixed fully.
That PR is also why IDE features did work: the import at the end was resolved correctly, so IDE features that re-resolved the macro path resolved it correctly.
I was concerned about the performance of this, but this doesn't seem to regress `analysis-stats .`, so I guess it's fine to land this. I have no idea about the incremental perf however and I don't know how to measure that, although when typing in `zbus` (including creating a new function, which should recompute the def map) completion was fast enough.
I didn't check what rustc does, so maybe it does something more performant, like keeping track of only possibly problematic imports.
Fixes #18138.
Probably fixes #17630.
|
|
davidbarsky:davidbarsky/respect-disabling-proc-macros-in-analysis-stats, r=Veykril
analysis-stats: respect `--disable-proc-macros` flag
I noticed that this flag wasn't being respected by `analysis-stats` when profiling proc macro expansion, so here's a small fix.
|
|
fix: fix ambigious package name in flycheck
fixes #18121
|
|
internal: Make COMPLETION_MARKER more explicitly r-a
If a user ever sees the completion marker, it's confusing to see text about IntelliJ. Use a string that's more explicitly about completion for rust-analyzer.
|
|
|
|
Mark `make_ascii_uppercase` and `make_ascii_lowercase` in `[u8]` and `str` as const.
Relevant tracking issue: #130698
This PR extends #130697 and #130713 to the similar methods in byte slices (`[u8]`) and string slices (`str`).
For the `str` methods, this simply requires adding the `const` specifier to the function signatures. The `[u8]` methods, however, require (at least a temporary) reimplementation due to the use of iterators and `for` loops.
|
|
r=cjgillot"
This reverts commit a772336fb3fbd1fe4493077fcfe04e0221296a99, reversing
changes made to 702987f75b74f789ba227ee04a3d7bb1680c2309.
It seems Apply EarlyOtherwiseBranch to scalar value #129047 may have
lead to several nightly regressions:
- https://github.com/rust-lang/rust/issues/130769
- https://github.com/rust-lang/rust/issues/130774
- https://github.com/rust-lang/rust/issues/130771
And since this is a mir-opt ICE that seems to quite easy to trigger with
real-world crates being affected, let's revert for now and reland the
mir-opt later.
|
|
fix: Consider lifetime GATs object unsafe
Fixes #18156.
|
|
And stop passing `BOOTSTRAP_CARGO` as an env var, instead the provided
cargo should go through `--cargo-path.`
|
|
'[u8]' and 'str' as const;
|
|
Rollup of 7 pull requests
Successful merges:
- #129545 (rustdoc: redesign toolbar and disclosure widgets)
- #130618 (Skip query in get_parent_item when possible.)
- #130727 (Check vtable projections for validity in miri)
- #130750 (Add new Tier-3 target: `loongarch64-unknown-linux-ohos`)
- #130758 (Revert "Add recursion limit to FFI safety lint")
- #130759 (Update books)
- #130762 (stabilize const_intrinsic_copy)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
stabilize const_intrinsic_copy
Fixes https://github.com/rust-lang/rust/issues/80697
This stabilizes
```rust
mod ptr {
pub const unsafe fn copy_nonoverlapping<T>(src: *const T, dst: *mut T, count: usize);
pub const unsafe fn copy<T>(src: *const T, dst: *mut T, count: usize);
}
impl *const T {
pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
}
impl *mut T {
pub const unsafe fn copy_to(self, dest: *mut T, count: usize);
pub const unsafe fn copy_to_nonoverlapping(self, dest: *mut T, count: usize);
pub const unsafe fn copy_from(self, src: *const T, count: usize);
pub const unsafe fn copy_from_nonoverlapping(self, src: *const T, count: usize);
}
impl <T> NonNull<T> {
pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
}
```
In particular, this reverts https://github.com/rust-lang/rust/pull/117905, which reverted https://github.com/rust-lang/rust/pull/97276.
The `NonNull` methods are not listed in the tracking issue, they were added to this feature gate in https://github.com/rust-lang/rust/pull/124498. The existing [FCP](https://github.com/rust-lang/rust/issues/80697#issuecomment-1022585839) does not cover them. They are however entirely identical to the `*mut` methods and already stable outside `const`. ``@rust-lang/libs-api`` please let me know if FCP will be required for the `NonNull` methods.
|
|
Update books
## rust-lang/book
5 commits in e7d217be2a75ef1753f0988d6ccaba4d7e376259..99cf75a5414fa8adbe3974bd0836661ca901708f
2024-09-23 16:18:39 UTC to 2024-09-11 18:38:03 UTC
- translations: remove broken link (rust-lang/book#4036)
- Update build instructions: include mdbook plugins (rust-lang/book#4032)
- Add `cargo init` usage suggestion to 1.3 (rust-lang/book#4025)
- Use immutable borrow of `TcpStream` when creating `BufReader` (rust-lang/book#4024)
- Upgrade to Rust 1.81 (rust-lang/book#4031)
## rust-lang/edition-guide
1 commits in b3ca7ade0f87d7e3fb538776defc5b2cc4188172..c7ebae25cb4801a31b6f05353f6d85bfa6feedd1
2024-09-22 08:47:02 UTC to 2024-09-22 08:47:02 UTC
- Update static_mut_refs now that it is a lint (rust-lang/edition-guide#322)
## rust-lang/reference
10 commits in 687faf9958c52116d003b41dfd29cc1cf44f5311..24fb2687cdbc54fa18ae4acf5d879cfceca77b2c
2024-09-22 09:07:12 UTC to 2024-09-10 19:24:17 UTC
- do not talk about the 'address of a constant' (rust-lang/reference#1624)
- Add spec identifier syntax to interior-mutability.md (rust-lang/reference#1585)
- Add spec identifier syntax to input-format.md (rust-lang/reference#1584)
- Document limitations on block doc comments (rust-lang/reference#1602)
- Places based on misaligned pointers: also mention 'static's as a possible base for place projections (rust-lang/reference#1606)
- type-layout: mention that call ABI compatibility is a separate concern (rust-lang/reference#1608)
- stabilize `const_extern_fn` (rust-lang/reference#1596)
- const_eval: update for const_mut_refs and const_refs_to_cell stabilization (rust-lang/reference#1590)
- fix: unclosed tag `sup` (rust-lang/reference#1612)
- Fix improper documentation on casting non_exhaustive enums (rust-lang/reference#1607)
## rust-lang/rustc-dev-guide
13 commits in 0ed9229f5b6f7824b333beabd7e3d5ba4b9bd971..555f3de2fa0d61c4294b74d245f1cbad6fcbf589
2024-09-23 12:51:33 UTC to 2024-09-10 07:32:10 UTC
- chore: add missing `.` (rust-lang/rustc-dev-guide#2074)
- Add remark on required free disk space (rust-lang/rustc-dev-guide#2073)
- fix broken links (rust-lang/rustc-dev-guide#2063)
- Add advice about submitting potentially hard-to-review PRs (rust-lang/rustc-dev-guide#2036)
- Edit a sentence for clarity (rust-lang/rustc-dev-guide#2071)
- Emphasize how to run a single tool test (rust-lang/rustc-dev-guide#2070)
- Remove chalk is owned by WG-traits (rust-lang/rustc-dev-guide#2068)
- Fix conditions lowering text for enums with no fields (rust-lang/rustc-dev-guide#2066)
- update proof tree chapter (rust-lang/rustc-dev-guide#2054)
- Add docs for JS tests (rust-lang/rustc-dev-guide#2048)
- Reflect `x.py test`'s `--rustc-args` option being renamed to `--compiletest-rustc-args` (rust-lang/rustc-dev-guide#2062)
- we standardized on this more reliable command (rust-lang/rustc-dev-guide#2061)
- Fix Typo and Remove Outdated Line About C Variadics (rust-lang/rustc-dev-guide#2060)
|
|
Revert "Add recursion limit to FFI safety lint"
It's not necessarily clear if warning when we hit the recursion limit is the right thing to do, first of all.
**More importantly**, this PR was implemented incorrectly in the first place; it was not decrementing the recursion limit when stepping out of a type, so it would trigger when a ctype has more than RECURSION_LIMIT fields *anywhere* in the type's set of recursively reachable fields.
Reverts #130598
Reopens #130310
Fixes #130757
|
|
Add new Tier-3 target: `loongarch64-unknown-linux-ohos`
MCP: https://github.com/rust-lang/compiler-team/issues/784
|
|
Check vtable projections for validity in miri
Currently, miri does not catch when we transmute `dyn Trait<Assoc = A>` to `dyn Trait<Assoc = B>`. This PR implements such a check, and fixes https://github.com/rust-lang/miri/issues/3905.
To do this, we modify `GlobalAlloc::VTable` to contain the *whole* list of `PolyExistentialPredicate`, and then modify `check_vtable_for_type` to validate the `PolyExistentialProjection`s of the vtable, along with the principal trait that was already being validated.
cc ``@RalfJung``
r? ``@lcnr`` or types
I also tweaked the diagnostics a bit.
---
**Open question:** We don't validate the auto traits. You can transmute `dyn Foo` into `dyn Foo + Send`. Should we check that? We currently have a test that *exercises* this as not being UB:
https://github.com/rust-lang/rust/blob/6c6d210089e4589afee37271862b9f88ba1d7755/src/tools/miri/tests/pass/dyn-upcast.rs#L14-L20
I'm not actually sure if we ever decided that's actually UB or not 🤔
We could perhaps still check that the underlying type of the object (i.e. the concrete type that was unsized) implements the auto traits, to catch UB like:
```rust
fn main() {
let x: &dyn Trait = &std::ptr::null_mut::<()>();
let _: &(dyn Trait + Send) = std::mem::transmute(x);
//~^ this vtable is not allocated for a type that is `Send`!
}
```
|
|
Skip query in get_parent_item when possible.
For HirIds with a non-zero item local id, `self.parent_owner_iter(hir_id).next()` just returns the same HirId with the item local id set to 0, but also does a query to retrieve the Node which is ignored here, which seems wasteful.
|
|
rustdoc: redesign toolbar and disclosure widgets
Fixes #77899
Fixes #90310
## Preview
| before | after
| ------ | -----
|  | 
|  | 
|  | 
|  | 
|  | 
| N/A | 
|  | 
|  | 
https://notriddle.com/rustdoc-html-demo-12/toolbar-v2/std/index.html
## Description
This adds labels to the icons and moves them away from the search box.
These changes are made together, because they work together, but are based on several complaints:
* The [+/-] thing are a Reddit-ism. They don't look like buttons, but look like syntax <https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/More.20visual.20difference.20for.20the.20.2B.2F-.20.20Icons>, <https://github.com/rust-lang/rust/issues/59851> (some of these are laundry lists with more suggestions, but they all mention [+/-] looking wrong)
* The settings, help, and summary buttons are also too hard to recognize <https://lwn.net/Articles/987070/>, <https://github.com/rust-lang/rust/issues/90310>, <https://github.com/rust-lang/rust/issues/14475#issuecomment-274241997>, <https://internals.rust-lang.org/t/improve-rustdoc-design/12758> ("Not all functionality is self-explanatory, for example the [+] button in the top right corner, the theme picker or the settings button.")
The toggle-all and toggle-individual buttons both need done at once, since we want them to look like they go together. This changes them from both being [+/-] to both being arrows.
CC <https://github.com/rust-lang/rust/pull/113074#issuecomment-1677469680> and ``@jsha`` regarding the use of triangles for disclosure, which is what everyone wanted, but was pending a good toggle-all button. This PR adds a toggle-all button that should work.
Settings and Help are also migrated, so that the whole group can benefit from being described using actual words.
The breadcrumbs also get redesigned, so that they use less space, by shrinking the parent module path parts. This is done at the same time as the toolbar redesign because it's, effectively, moving space from the toolbar to the breadcrumbs.
This is aimed at avoiding any line wrapping at desktop sizes.
## Prior art
This style of toolbar, with explicit labels on the buttons, used to be more popular. It's not very common in web browsers nowadays, and for truly universal icons like :arrow_left: I can understand why, but words are great when icons fail.
|
|
Rework `non_local_definitions` lint to only use a syntactic heuristic
This PR reworks the `non_local_definitions` lint to only use a syntactic heuristic, i.e. not use a type-system logic for whenever an `impl` is local or not.
Instead the new logic wanted by T-lang in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762, which is to consider every paths in `Self` and `Trait` and to no longer use the type-system inference trick.
`@rustbot` labels +L-non_local_definitions
Fixes #126768
|
|
|
|
remove workaround for make prepare and use dry-run build instead
Removes an annoying hard-coded logic.
try-job: x86_64-msvc
|
|
If a user ever sees the completion marker, it's confusing to see text
about IntelliJ. Use a string that's more explicitly about completion
for rust-analyzer.
|
|
|
|
add unqualified_local_imports lint
This lint helps deal with https://github.com/rust-lang/rustfmt/issues/4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
|
|
|
|
This ensures the code-gen for these ABIs does not change silently.
Co-authored-by: Folkert <folkert@folkertdev.nl>
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
This reverts commit 716044751b7a36c634be709e37923e3dbdf53888.
|
|
Rollup of 7 pull requests
Successful merges:
- #129201 (std: implement the `random` feature (alternative version))
- #130536 (bootstrap: Set the dylib path when building books with rustdoc)
- #130551 (Fix `break_last_token`.)
- #130657 (Remove x86_64-fuchsia and aarch64-fuchsia target aliases)
- #130721 (Add more test cases for block-no-opening-brace)
- #130736 (Add rustfmt 2024 reformatting to git blame ignore)
- #130746 (readd `@tgross35` and `@joboet` to the review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
fix: Support expect in attribute completion and hover
Fixes #18171
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/784
Co-authored-by: WANG Rui <wangrui@loongson.cn>
|
|
readd @tgross35 and @joboet to the review rotation
We're both (nearly) back from vacation.
CC ``@tgross35``
|
|
Add rustfmt 2024 reformatting to git blame ignore
https://github.com/rust-lang/rust/pull/130724 essentially reformatted the world, so we should add it to the git blame ignore list.
Tested with `git blame compiler/rustc_abi/src/lib.rs -L1137,1146`. I first thought that I have to ignore the merge commit, but it seems like the actual commit that did the reformatting should be ignored instead.
r? ``@compiler-errors``
|
|
Add more test cases for block-no-opening-brace
Also add FIXME's for #80931 & #78168
|
|
Remove x86_64-fuchsia and aarch64-fuchsia target aliases
Closes #106649.
|
