| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Changes to `compiler-builtins` don't currently get a `T-` label, but it
is mostly managed by libs. Add the autolabel here.
|
|
Add a few links to the collections mentioned in the module doc for Collections.
|
|
`compiler-builtins` is already in the crate graph via `alloc`, and all
features related to `compiler-builtins` goes through `alloc`. There
isn't any reason that `std` needs this direct dependency, so remove it.
|
|
The three panic-related library crates need to have access to `core`,
and `compiler-builtins` needs to be in the crate graph. Rather than
specifying both dependencies, switch these crates to use
`rustc-std-workspace-core` which already does this.
This means there is now a single place that the `compiler-builtins`
dependency needs to get configured, for everything other than `alloc`
and `std`.
|
|
`compiler_builtins` shouldn't be called directly. Change the `PartialEq`
implementation for `DevicePathNode` to use slice equality instead, which
will call `memcmp`/`bcmp` via the intrinsic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To avoid representing them just with strings.
|
|
|
|
|
|
|
|
|
|
Do not write dummy bindings to extern prelude.
Use more precise `Used::Scope` while recording use and remove now redundant `introduced_by_item` check.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#144688 (Uniform `enter_trace_span!` and add documentation)
- rust-lang/rust#144702 (stall `ConstArgHasType` in `compute_goal_fast_path`)
- rust-lang/rust#144711 (Consider operator's span when computing binop expr span)
- rust-lang/rust#144712 (Deduplicate `IntTy`/`UintTy`/`FloatTy`.)
- rust-lang/rust#144726 (merge rustc_attr_data_structures into rustc_hir)
- rust-lang/rust#144733 (fix: Match width of ascii and unicode secondary file start)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
fix: Match width of ascii and unicode secondary file start
The current [unicode secondary file start](https://github.com/rust-lang/rust/blob/64ca23b6235732fa61c0a2b957c5d7e591e7c972/compiler/rustc_errors/src/emitter.rs#L2991) is only three characters, whereas the ASCII variant and normal [file start](https://github.com/rust-lang/rust/blob/64ca23b6235732fa61c0a2b957c5d7e591e7c972/compiler/rustc_errors/src/emitter.rs#L2983-L2984) are four characters. This slight difference caused the paths following a Unicode secondary file start to not align with other structured elements.
|
|
merge rustc_attr_data_structures into rustc_hir
this move was discussed on zulip: [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/528530091)
Many PRs in the attribute rework depend on this move.
|
|
merge rustc_attr_data_structures into rustc_hir
this move was discussed on zulip: [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/528530091)
Many PRs in the attribute rework depend on this move.
|
|
Deduplicate `IntTy`/`UintTy`/`FloatTy`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This commit removes them and places a single definition in `rustc_ast_ir`. This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but means a bunch of silly conversion functions can be removed.
r? `@fmease`
|
|
Deduplicate `IntTy`/`UintTy`/`FloatTy`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This commit removes them and places a single definition in `rustc_ast_ir`. This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but means a bunch of silly conversion functions can be removed.
r? `@fmease`
|
|
Consider operator's span when computing binop expr span
When computing the span of a binop consisting of `lhs` and `rhs`, we previously just took the spans of `lhs.span.to(rhs.span)`. In the case that both `lhs` and `rhs` are both arguments to a macro, this can produce a wildly incorrect span.
To fix this, first compute the span between `lhs` and the binary operator, which will cause `lhs` to possibly be adjusted to a relevant macro metavar, and then compute that span extended to `rhs`, which will cause it to also be adjusted to a relevant macro metavar.
This coincidentally fixes a FIXME in `tests/ui/lint/wide_pointer_comparisons.rs` and suppresses a nonsense suggestion.
|
|
stall `ConstArgHasType` in `compute_goal_fast_path`
I'm having major deja-vu about this; I thought that already implemented this but 🤷 maybe not.
|
|
Uniform `enter_trace_span!` and add documentation
1. The latest changes to `enter_trace_span!` were ported from Miri (see https://github.com/rust-lang/miri/pull/4452#discussion_r2204958019), so now both the `rustc_const_eval` and the Miri macro accept the same syntax. Furthermore, the Miri macro was changed to just call rustc_const_eval`'s, to avoid duplication.
2. I made the `layout_of` (& friends) calls use that new syntax, e.g. `enter_trace_span!(layouting::layout_of, ...)`
3. I made sure the macro specifies all types/traits/macros it refers to using `$crate::`, so the macro works anywhere independently of which types/traits/macros are imported in the context it is used in.
4. I added documentation, examples and tips to the macro's doc. To make the rustdoc compile I had to add some hidden lines (`#`), but now it acts as a compilation test which will avoid reintroducing issue 3. in the future. I will also create a documentation file with everything one needs to know about tracing at a later point, but I figured adding some of that info directly on the tracing macro makes it more discoverable.
5. In `stack.rs` I made it so that the `"frame"` span has a field named "frame" (instead of "message") with the data about the frame. This field used to be called "message" (tracing's default) since it was previously formatted using `"{}", instance`, and now I replaced it with `frame = %instance`.
|
|
add `SyntaxEditor::delete_all` to migrate utils.rs `add_trait_assoc_items_to_impl`
|
|
|
|
Suggesting to remove `*&` or `*&mut` in a macro may be incorrect, as it
would require tracking all possible macro usages. In some cases, it is
not possible to remove the dereference or the reference.
For example, in the following code, the `drmut!()` macro will be linted
against while called as `drmut!(d)`, and the suggestion would be to
remove the `*&mut`. That would make `drmut!(u.data).num = 1` invalid,
as a `ManuallyDrop` object coming through a union cannot be implicitely
dereferenced through `DerefMut`.
```rust
use std::mem::ManuallyDrop;
#[derive(Copy, Clone)]
struct Data {
num: u64,
}
union Union {
data: ManuallyDrop<Data>,
}
macro_rules! drmut {
($e:expr) => { *&mut $e };
}
fn f(mut u: Union, mut d: Data) {
unsafe {
drmut!(u.data).num = 1;
}
drmut!(d).num = 1;
}
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The data in the table needs to be in the same order as the headings.
changelog: none
Fixes rust-lang/rust-clippy#15370
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#136840 (Fix linker-plugin-lto only doing thin lto)
- rust-lang/rust#144053 (Remove install Rust script from CI)
- rust-lang/rust#144297 (Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc)
- rust-lang/rust#144721 (`std_detect`: Linux 6.16 support for RISC-V)
r? `@ghost`
`@rustbot` modify labels: rollup
|
