| Age | Commit message (Collapse) | Author | Lines |
|---|
|
multiple times
|
|
Remove the unused StableSet and StableMap types from rustc_data_structures.
The current implementation is not "stable" in the same sense that `HashStable` and `StableHasher` are stable, i.e. across compilation sessions. So, in my opinion, it's better to remove those types (which are basically unused anyway) than to give the wrong impression that these are safe for incr. comp.
I plan to provide new "stable" collection types soon that can be used to replace `FxHashMap` and `FxHashSet` in query results (see [draft](https://github.com/michaelwoerister/rust/commit/69d03ac7a7d651a397ab793e9d78f8fce3edf7a6)). It's unsound that `HashMap` and `HashSet` implement `HashStable` (see https://github.com/rust-lang/rust/issues/98890 for a recent P-critical bug caused by this) -- so we should make some progress there.
|
|
Add a check confirming that features referenced in `implied_by` meta
items actually exist.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Improves the diagnostic when a feature attribute is specified
unnecessarily but the feature implies another (i.e. it was partially
stabilized) to refer to the implied feature.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
If part of a feature is stabilized and a new feature is added for the
remaining parts, then the `implied_by` attribute can be used to indicate
which now-stable feature previously contained a item. If the now-stable
feature is still active (if the user has only just updated rustc, for
example) then there will not be an stability error for uses of the item
from the implied feature.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
Change some regular comments into documentation comments.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
r=petrochenkov,GuillaumeGomez
Improve the function pointer docs
This is #97842 but for function pointers instead of tuples. The concept is basically the same.
* Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
|
|
Avoid `Symbol` to `&str` conversions
`Symbol::as_str` is a slowish operation, so this patch removes some usages of it.
|
|
|
|
The attribute is also renamed `fake_variadic`.
|
|
|
|
Migrate half of the `rustc_passes::check_attr` diagnostics to using
diagnostic derives and being translatable.
|
|
Support unstable moves via stable in unstable items
part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of https://github.com/rust-lang/rust/pull/90328.
The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.
This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
|
|
Rollup of 5 pull requests
Successful merges:
- #97720 (Always create elided lifetime parameters for functions)
- #98315 (Stabilize `core::ffi:c_*` and rexport in `std::ffi`)
- #98705 (Implement `for<>` lifetime binder for closures)
- #99126 (remove allow(rustc::potential_query_instability) in rustc_span)
- #99139 (Give a better error when `x dist` fails for an optional tool)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Implement `for<>` lifetime binder for closures
This PR implements RFC 3216 ([TI](https://github.com/rust-lang/rust/issues/97362)) and allows code like the following:
```rust
let _f = for<'a, 'b> |a: &'a A, b: &'b B| -> &'b C { b.c(a) };
// ^^^^^^^^^^^--- new!
```
cc ``@Aaron1011`` ``@cjgillot``
|
|
Rename `debugging_opts` to `unstable_opts`
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
cc https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Codegen.20options.20.2F.20debugging.20options
r? `@Amanieu` cc `@nikic` `@joshtriplett`
|
|
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
|
|
|
|
|
|
|
|
|
|
`UnsafeCell` blocks niches inside its nested type from being available outside
fixes #87341
This implements the plan by `@eddyb` in https://github.com/rust-lang/rust/issues/87341#issuecomment-886083646
Somewhat related PR (not strictly necessary, but that cleanup made this PR simpler): #94527
|
|
This helps bring `hir::Expr` size down, `Closure` was the biggest
variant, especially after `for<>` additions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use a bitset instead of a hash map in HIR ID validator
The hashset insertion was slightly hot in incr patched runs, but it seems unnecessary to use a hashset here, as it just checks that a dense set of N integers was seen.
I'm not sure if it's possible to know the amount of items beforehand to preallocate the bitset? I suppose not.
|
|
lints: mostly translatable diagnostics
As lints are created slightly differently than other diagnostics, intended to try make them translatable first and then look into the applicability of diagnostic structs but ended up just making most of the diagnostics in the crate translatable (which will still be useful if I do make a lot of them structs later anyway).
r? ``@compiler-errors``
|
|
|
|
|
|
rustc_passes/src/entry.rs: De-duplicate more code with `fn throw_attr_err()`
So we can more easily re-use the code for other attributes later. More specifically [`#[unix_sigpipe]`](https://github.com/rust-lang/rust/pull/97802). This refactoring is covered by this test:
https://github.com/rust-lang/rust/blob/8aab472d52ba7314dc193c73abcd384e2586123c/src/test/ui/feature-gates/issue-43106-gating-of-builtin-attrs-error.rs#L120
(Well, only `#[start]`, but the code for `#[rustc_main]` is identical.)
|
|
Rewrite dead-code pass to avoid fetching HIR.
This allows to get a more uniform handling of spans, and to simplify the grouping of diagnostics for variants and fields.
|
|
Accept `DiagnosticMessage` in `LintDiagnosticBuilder::build` so that
lints can be built with translatable diagnostic messages.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
So we can re-use the code for other attributes later.
|
|
Fixup missing renames from `#[main]` to `#[rustc_main]`
In #84217 `#[main]` was removed and replaced with `#[rustc_main]`. In some places the rename was forgotten, which makes the current code confusing, because at first glance it seems that `#[main]` is still around. Perform the renames also in these places.
I noticed this (after first being confused by it) when working on #97802.
r? `@petrochenkov`
(since you reviewed the other PR)
|
|
rustc_target: Remove some redundant target properties
`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.
`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.
I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
|
|
|
|
|
|
|
|
|
|
In fc357039f9 `#[main]` was removed and replaced with `#[rustc_main]`.
In some place the rename was forgotten, which makes the current code
confusing, because at first glance it seems that `#[main]` is still
around. Perform the renames also in these places.
|
|
r=estebank
Collapse multiple dead code warnings into a single diagnostic
closes #97643
|
