| Age | Commit message (Collapse) | Author | Lines |
|---|
|
std: expose `const_io_error!` as `const_error!`
ACP: https://github.com/rust-lang/libs-team/issues/205
Tracking issue: https://github.com/rust-lang/rust/issues/133448
Probably best reviewed commit-by-commit, the first one does the API change, the second does the mass-rename.
|
|
CI: split x86_64-msvc-ext job
try-job: x86_64-msvc-ext1
try-job: x86_64-msvc-ext3
|
|
use `--exact` on `--skip` to avoid unintended substring matches
Without the `--exact` flag, using `--skip tests/rustdoc` can unintentionally skip other tests that match as substrings such as `rustdoc-gui`, `rustdoc-js`, etc.
For debugging, run: `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc` and `./x.py --stage 2 test rustdoc-ui --skip tests/rustdoc -- --exact`
Resolves https://github.com/rust-lang/rust/issues/117721
try-job: x86_64-apple-1
|
|
Rollup of 8 pull requests
Successful merges:
- #115293 (Remove -Zfuel.)
- #132605 (CI: increase timeout from 4h to 6h)
- #133304 (Revert diagnostics hack to fix ICE 132920)
- #133402 (Constify `Drop` and `Destruct`)
- #133458 (Fix `Result` and `Option` not getting a jump to def link generated)
- #133471 (gce: fix typing_mode mismatch)
- #133475 (`MaybeStorage` improvements)
- #133513 (Only ignore windows-gnu in avr-jmp-offset)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Only ignore windows-gnu in avr-jmp-offset
The failure in 133480 occurs on mingw but there's currently no evidence it fails on msvc too.
|
|
`MaybeStorage` improvements
Minor dataflow improvements.
r? `@tmiasko`
|
|
gce: fix typing_mode mismatch
Fixes #133271
r? `@BoxyUwU`
|
|
Fix `Result` and `Option` not getting a jump to def link generated
It was just because we didn't store the "span" in the `PreludeTy` variant.
r? ``@notriddle``
|
|
Constify `Drop` and `Destruct`
r? `@lcnr` or `@fee1-dead`
|
|
Revert diagnostics hack to fix ICE 132920
This reverts 8a568d9f15453cbfe5d6f45fa5f5bb32e58b93ed from #128849 to fix the diagnostics ICE in #132920.
The hack mentioned in that commit was supposed to be tailored to E277, but that codepath is used actually shared with other errors, e.g. at least the E283 from the linked issue.
We may have to eat the slightly worse diagnostics until a non-hacky way to make this error less verbose is implemented (or I guess a different hack specializing even more to E277's structure).
Sorry ``@estebank`` 🙏. I can close this if you'd prefer to fix it in a different way.
Since it seems unexpected that #128849 would impact the repro, here's how the error used to look before that PR.
```console
warning: unused import: `minirapier::Ray`
--> src/main.rs:2:5
|
2 | use minirapier::Ray;
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
error[E0283]: type annotations needed
--> src/main.rs:10:5
|
10 | insert_resource(Res.into());
| ^^^^^^^^^^^^^^^ ---------- type must be known at this point
| |
| cannot infer type of the type parameter `R` declared on the function `insert_resource`
|
= note: cannot satisfy `_: Resource`
= help: the trait `Resource` is implemented for `Res`
note: required by a bound in `insert_resource`
--> src/main.rs:4:23
|
4 | fn insert_resource<R: Resource>(_resource: R) {}
| ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
|
10 | insert_resource::<R>(Res.into());
| +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
|
10 - insert_resource(Res.into());
10 + insert_resource(Res);
```
And how it looks now without the ICE.
```console
warning: unused import: `minirapier::Ray`
--> src/main.rs:2:5
|
2 | use minirapier::Ray;
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
error[E0283]: type annotations needed
--> src/main.rs:10:5
|
10 | insert_resource(Res.into());
| ^^^^^^^^^^^^^^^ ---------- type must be known at this point
| |
| cannot infer type of the type parameter `R` declared on the function `insert_resource`
|
= note: cannot satisfy `_: Resource`
note: there are multiple different versions of crate `minibevy` in the dependency graph
--> /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_b/src/lib.rs:1:1
|
1 | pub trait Resource {}
| ^^^^^^^^^^^^^^^^^^ this is the required trait
|
::: src/main.rs:1:5
|
1 | use minibevy::Resource;
| -------- one version of crate `minibevy` is used here, as a direct dependency of the current crate
2 | use minirapier::Ray;
| ---------- one version of crate `minibevy` is used here, as a dependency of crate `minirapier`
|
::: /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_a/src/lib.rs:1:1
|
1 | pub trait Resource {}
| ------------------ this is the found trait
= help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `insert_resource`
--> src/main.rs:4:23
|
4 | fn insert_resource<R: Resource>(_resource: R) {}
| ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
|
10 | insert_resource::<R>(Res.into());
| +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
|
10 - insert_resource(Res.into());
10 + insert_resource(Res);
|
```
The improvements from #128849 are still present and the note about the trait coming from the 2 versions of bevy is more explanatory/helpful than before, albeit a bit verbosely.
Fixes #132920.
|
|
CI: increase timeout from 4h to 6h
Our CI got a bit slower since the last time we [lowered](https://github.com/rust-lang/rust/pull/127648) the timeout, and if e.g. Docker build cache is broken, the timeout can be triggered.
Discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/ci.20job.20timings.20stats).
|
|
Remove -Zfuel.
I'm not sure this feature is used. I only found 2 references in a google search, both referring to its introduction.
Meanwhile, it's a global mutable state, untracked by incremental compilation, so incompatible with it.
|
|
Rollup of 12 pull requests
Successful merges:
- #133042 (btree: add `{Entry,VacantEntry}::insert_entry`)
- #133070 (Lexer tweaks)
- #133136 (Support ranges in `<[T]>::get_many_mut()`)
- #133140 (Inline ExprPrecedence::order into Expr::precedence)
- #133155 (Yet more `rustc_mir_dataflow` cleanups)
- #133282 (Shorten the `MaybeUninit` `Debug` implementation)
- #133326 (Remove the `DefinitelyInitializedPlaces` analysis.)
- #133362 (No need to re-sort existential preds in relate impl)
- #133367 (Simplify array length mismatch error reporting (to not try to turn consts into target usizes))
- #133394 (Bail on more errors in dyn ty lowering)
- #133410 (target check_consistency: ensure target feature string makes some basic sense)
- #133435 (miri: disable test_downgrade_observe test on macOS)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
miri: disable test_downgrade_observe test on macOS
Due to https://github.com/rust-lang/rust/issues/121950, this test can fail on Miri. The test is also quite slow on Miri (taking more than 30s) due to the high iteration count (a total of 2000), so let's reduce that a little.
Fixes https://github.com/rust-lang/rust/issues/133421
|
|
target check_consistency: ensure target feature string makes some basic sense
|
|
Bail on more errors in dyn ty lowering
If we have more than one principal trait, or if we have a principal trait with errors in it, then bail with `TyKind::Error` rather than attempting lowering. Lowering a dyn trait with more than one principal just arbitrarily chooses the first one and drops the subsequent ones, and lowering a dyn trait path with errors in it is just kinda useless.
This suppresses unnecessary errors which I think is net-good, but also is important to make sure that we don't end up leaking `{type error}` in https://github.com/rust-lang/rust/issues/133388 error messaging :)
r? types
|
|
Simplify array length mismatch error reporting (to not try to turn consts into target usizes)
This changes `TypeError::FixedArrayLen` to use `ExpectedFound<ty::Const<'tcx>>` (instead of `ExpectedFound<u64>`), and renames it to `TypeError::ArrayLen`. This allows us to avoid a `try_to_target_usize` call in the type relation, which ICEs when we have a scalar of the wrong bit length (i.e. u8).
This also makes `structurally_relate_tys` to always use this type error kind any time we have a const mismatch resulting from relating the array-len part of `[T; N]`.
This has the effect of changing the error message we issue for array length mismatches involving non-valtree consts. I actually quite like the change, though, since before:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected `M`, found `N`
|
= note: expected array `[u8; M]`
found array `[u8; N]`
```
and after, which I think is far less verbose:
```
LL | fn test<const N: usize, const M: usize>() -> [u8; M] {
| ------- expected `[u8; M]` because of return type
LL | [0; N]
| ^^^^^^ expected an array with a size of M, found one with a size of N
```
The only questions I have are:
1. Should we do something about backticks here? Right now we don't backtick either fully evaluated consts like `2`, or rigid consts like `Foo::BAR`.... but maybe we should? It seems kinda verbose to do for numbers -- maybe we could intercept those specifically.
2. I guess we may still run the risk of leaking unevaluated consts into error reporting like `2 + 1`...?
r? ``@BoxyUwU``
Fixes #126359
Fixes #131101
|
|
No need to re-sort existential preds in relate impl
We already assert that these predicates are in the right ordering in `mk_poly_existential_predicates`.
r? types
|
|
Remove the `DefinitelyInitializedPlaces` analysis.
Its only use is in the `tests/ui/mir-dataflow/def_inits-1.rs` where it is tested via `rustc_peek_definite_init`.
Also, it's probably buggy. It's supposed to be the inverse of `MaybeUninitializedPlaces`, and it mostly is, except that `apply_terminator_effect` is a little different, and `apply_switch_int_edge_effects` is missing. Unlike `MaybeUninitializedPlaces`, which is used extensively in borrow checking, any bugs in `DefinitelyInitializedPlaces` are easy to overlook because it is only used in one small test.
This commit removes the analysis. It also removes
`rustc_peek_definite_init`, `Dual` and `MeetSemiLattice`, all of which are no longer needed.
r? ``@cjgillot``
|
|
Shorten the `MaybeUninit` `Debug` implementation
Currently the `Debug` implementation for `MaybeUninit` winds up being pretty verbose. This struct:
```rust
#[derive(Debug)]
pub struct Foo {
pub a: u32,
pub b: &'static str,
pub c: MaybeUninit<u32>,
pub d: MaybeUninit<String>,
}
```
Prints as:
Foo {
a: 0,
b: "hello",
c: core::mem::maybe_uninit::MaybeUninit<u32>,
d: core::mem::maybe_uninit::MaybeUninit<alloc::string::String>,
}
The goal is just to be a standin for content so the path prefix doesn't add any useful information. Change the implementation to trim `MaybeUninit`'s leading path, meaning the new result is now:
Foo {
a: 0,
b: "hello",
c: MaybeUninit<u32>,
d: MaybeUninit<alloc::string::String>,
}
|
|
r=cjgillot
Yet more `rustc_mir_dataflow` cleanups
A few more cleanups.
r? `@cjgillot`
|
|
Inline ExprPrecedence::order into Expr::precedence
The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).
Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:
1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`
As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.
The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:
```rust
match self.kind {
ExprKind::Closure(..) => ExprPrecedence::Closure,
...
}
```
although there were exceptions of both many-to-one, and one-to-many:
```rust
ExprKind::Underscore => ExprPrecedence::Path,
ExprKind::Path(..) => ExprPrecedence::Path,
...
ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```
Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.
You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:
- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.
- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.
- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.
This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
|
|
Support ranges in `<[T]>::get_many_mut()`
As per T-libs-api decision in #104642.
I implemented that with a separate trait and not within `SliceIndex`, because doing that via `SliceIndex` requires adding support for range types that are (almost) always overlapping e.g. `RangeFrom`, and also adding fake support code for `impl SliceIndex<str>`.
An inconvenience that I ran into was that slice indexing takes the index by value, but I only have it by reference. I could change slice indexing to take by ref, but this is pretty much the hottest code ever so I'm afraid to touch it. Instead I added a requirement for `Clone` (which all index types implement anyway) and cloned. This is an internal requirement the user won't see and the clone should always be optimized away.
I also implemented `Clone`, `PartialEq` and `Eq` for the error type, since I noticed it does not do that when writing the tests and other errors in std seem to implement them. I didn't implement `Copy` because maybe we will want to put something non-`Copy` there.
|
|
Lexer tweaks
Some cleanups and small performance improvements.
r? ```@chenyukang```
|
|
btree: add `{Entry,VacantEntry}::insert_entry`
This matches the recently-stabilized methods on `HashMap` entries. I've
reused tracking issue #65225 for now, but we may want to split it.
|
|
Rollup of 13 pull requests
Successful merges:
- #133411 (the emscripten OS no longer exists on non-wasm targets)
- #133419 (Added a doc test for std::path::strip_prefix)
- #133430 (Tweak parameter mismatch explanation to not say `{unknown}`)
- #133443 (Remove dead code stemming from the old effects desugaring (II))
- #133450 (remove "onur-ozkan" from users_on_vacation)
- #133454 (Update test expectations to accept LLVM 'initializes' attribute)
- #133462 (Use ReadCache for archive reading in bootstrap)
- #133464 (std::thread: avoid leading whitespace in some panic messages)
- #133467 (tests: Add recursive associated type bound regression tests)
- #133470 (Cleanup: delete `//@ pretty-expanded` directive)
- #133473 (tests: Add regression test for recursive enum with Cow and Clone)
- #133481 (Disable `avr-rjmp-offset` on Windows for now)
- #133495 (add test for alias-bound shadowing, rename folder)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add test for alias-bound shadowing, rename folder
r? `@BoxyUwU` `@compiler-errors`
|
|
Disable `avr-rjmp-offset` on Windows for now
The linker has been randomly crashing on `x86_64-mingw` that's causing spurious failures (#133480). Disable this test on Windows for now.
cc `@jfrimmel` (nothing actionable, just FYI because linker gonna linker)
cc `@ehuss` (who noticed this)
r? compiler (or anyone really)
|
|
tests: Add regression test for recursive enum with Cow and Clone
I could not find any existing test. `git grep "(Cow<'[^>]\+\["` gave no hits before this tests.
Closes #100347
|
|
Cleanup: delete `//@ pretty-expanded` directive
This PR removes the `//@ pretty-expanded` directive support in compiletest and removes its usage inside ui tests because it does not actually do anything, and its existence is itself misleading. This PR is split into two commits:
1. The first commit just drops `pretty-expanded` directive support in compiletest.
2. The second commit is created by `sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs`[^1], reblessing, and slightly adjusting some leading whitespace in a few tests.
We can tell this is fully removed because compiletest doesn't complain about unknown directive when running the `ui` test suite.
cc #23616
### History
Originally, there was some effort to introduce more test coverage for `-Z unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In [Make it an error to not declare used features #23598][pr-23598], there was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z unpretty=expanded` test). This was needed because back then the dedicated `tests/pretty` ("pretty") test suite did not existed, and the pretty tests were grouped together under `run-pass` tests (I believe the `ui` test suite didn't exist back then either). Unfortunately, in this process the replacement `//@ pretty-expanded` directives contained a `FIXME #23616` linking to [There are very few tests for `-Z unpretty` expansion #23616][issue-23616]. But this was arguably backwards and somewhat misleading, as noted in [#23616](https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901):
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
### Current status
As of Nov 2024, we have a dedicated `pretty` test suite, and some time over the years the split between `run-pass` into `ui` and `pretty` test suites caused all the `//@ pretty-expanded` in `ui` tests to do absolutely nothing: the compiletest logic for `pretty-expanded` only triggers in the *pretty* test suite, but none of the pretty tests use it. Oops.
Nobody remembers this, nobody uses this, it's misleading in ui tests. Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
### Follow-ups
- [x] Yeet this directive from rustc-dev-guide docs. https://github.com/rust-lang/rustc-dev-guide/pull/2147
[^1]: https://github.com/chmln/sd
r? compiler
|
|
tests: Add recursive associated type bound regression tests
Add regression tests for https://github.com/rust-lang/rust/issues/129541 as requested in https://github.com/rust-lang/rust/issues/129541#issuecomment-2498514488.
Closes #129541
r? ``@lcnr``
|
|
std::thread: avoid leading whitespace in some panic messages
This:
```
panic!(
"use of std::thread::current() is not possible after the thread's
local data has been destroyed"
)
```
will print a newline followed by a bunch of spaces, since the entire string literal is interpreted literally.
I think the intention was to print the message without the newline and the spaces, so let's add some `\` to make that happen.
r? ``@joboet``
|
|
Use ReadCache for archive reading in bootstrap
Address expensive archive reading in bootstrap. This fixes https://github.com/rust-lang/rust/issues/133268
Enable the `std` feature of `object` to use `ReadCache` instead of reading the entire archive file into memory to check for headers. This takes minimal extra time to compile compared to introducing other expensive dependencies to `bootstrap`.
r? jieyouxu
|
|
Update test expectations to accept LLVM 'initializes' attribute
The test was checking for two `ptr` arguments by matching commas (or non-commas), however after
https://github.com/llvm/llvm-project/pull/117104 LLVM adds an `initializes((0, 16))` attribute, which includes a comma.
So instead, we make the test check for two LLVM values, i.e. something prefixed by %.
(See also https://crbug.com/380707238)
|
|
remove "onur-ozkan" from users_on_vacation
|
|
Remove dead code stemming from the old effects desugaring (II)
Follow-up to #132374.
r? project-const-traits
|
|
Tweak parameter mismatch explanation to not say `{unknown}`
* Tweak parameter mismatch explanation not to call parameters with no identifier `{unknown}`
* Say "both" when there are two parameters
* Backtick a type parameter name for consistency
|
|
Added a doc test for std::path::strip_prefix
I was about 90% sure `Path::new("/test/haha/foo.txt").strip_prefix("/te")` would return an Err, but I couldn't find an example to confirm this behaviour.
This should be an easy merge :)
|
|
the emscripten OS no longer exists on non-wasm targets
https://github.com/rust-lang/rust/pull/117338 removed our asmjs targets, which AFAIK means that emscripten only exists on wasm targets. However at least one place in the code still checked "is wasm or is emscripten". Let's fix that.
Cc ```@workingjubilee```
|
|
|
|
|
|
|
|
|
|
Refactor `where` predicates, and reserve for attributes support
Refactor `WherePredicate` to `WherePredicateKind`, and reserve for attributes support in `where` predicates.
This is a part of #115590 and is split from #132388.
r? petrochenkov
|
|
Update cargo and books
10 commits in 66221abdeca2002d318fde6efff516aab091df0e..4c39aaff66862cc0da52fe529aa1990bb8bb9a22
2024-11-19 21:30:02 +0000 to 2024-11-25 16:36:17 +0000
- feat: Stabilize Edition 2024 (rust-lang/cargo#14828)
- Improve error handling when PathSource is relative (rust-lang/cargo#14854)
- test: address test output nondeterminism (rust-lang/cargo#14855)
- chore: move supports-unicode to workspace deps (rust-lang/cargo#14853)
- Check build target supports std when building with -Zbuild-std=std (rust-lang/cargo#14183)
- fix(publish): Allow dry-run of a non-bumped workspace (rust-lang/cargo#14847)
- test: Switch from 'exec_with_output' to 'run' (rust-lang/cargo#14848)
- test(rustflags): Verify -Cmetadata directly, not through -Cextra-filename (rust-lang/cargo#14846)
- chore: remove bors mentions (rust-lang/cargo#14845)
- Clarify how `cargo::metadata` env var is selected (rust-lang/cargo#14842)
## nomicon
1 commits in eac89a3cbe6c4714e5029ae8b5a1c556fd4e8c42..0674321898cd454764ab69702819d39a919afd68
2024-11-16 14:05:28 +0000 to 2024-11-19 12:35:48 +0000
- races: Clarify a “mostly” that might be misread (rust-lang-nursery/nomicon#468)
## reference
12 commits in 41ccb0e6478305401dad92e8fd3d04a4304edb4c..5c86c739ec71b8bc839310ff47fa94e94635bba9
2024-11-15 21:45:16 +0000 to 2024-11-25 17:23:35 +0000
- Document `gen` keyword as reserved in Rust 2024 (rust-lang-nursery/reference#1501)
- 2024: Update `expr` macro fragment specifier (rust-lang-nursery/reference#1639)
- Add rust_2024 prelude (rust-lang-nursery/reference#1552)
- 2024: Add reserved syntax (rust-lang-nursery/reference#1652)
- Add Lifetime Capture Rules 2024 (rust-lang-nursery/reference#1601)
- Add a section dedicated to Edition 2024 changes to temporary scopes (rust-lang-nursery/reference#1592)
- 2024: Add unsafe attribute differences (rust-lang-nursery/reference#1579)
- 2024: Add updates for unsafe extern blocks (rust-lang-nursery/reference#1565)
- Fix rule for lazy boolean temporary drop scope (rust-lang-nursery/reference#1681)
- Raw lifetimes (rust-lang-nursery/reference#1603)
- Fix some missing emdashes (rust-lang-nursery/reference#1676)
- Added an additional example of lifetime elision (rust-lang-nursery/reference#1678)
## rustc-dev-guide
6 commits in b679e71c2d66c6fe13e06b99ac61773b866213f0..787b4166ccc67bd8f72a6e3ef6685ce9ce82909a
2024-11-18 16:18:15 +0800 to 2024-11-22 11:17:57 +0000
- Remove constants section as it is outdated
- Flatten generic parameter defs section
- Add instructions to test error code docs (rust-lang/rustc-dev-guide#2145)
- Reorganize the "Source Code Representation" chapters (rust-lang/rustc-dev-guide#2142)
- Make `Diag` a clickable link in Suggestion section (rust-lang/rustc-dev-guide#2140)
- update for rustc_intrinsic_const_stable_indirect (rust-lang/rustc-dev-guide#2138)
## edition-guide
6 commits in 915f9b319c2823f310430ecdecd86264a7870d7e..f48b0e842a3911c63240e955d042089e9e0894c7
2024-11-06 07:23:07 +0000 to 2024-11-25 16:20:27 +0000
- Update for 2024 stabilization (rust-lang-nursery/edition-guide#338)
- Enable triagebot merge-conflicts and shortcuts (rust-lang-nursery/edition-guide#336)
- Organize the 2024 chapters into sub-chapters by category (rust-lang-nursery/edition-guide#334)
- Fix broken Cargo Book link in cargo-resolver.md (rust-lang-nursery/edition-guide#335)
- Edition 2024 guide for temporary lifetime changes (rust-lang-nursery/edition-guide#318)
- 2024: rustfmt sorting (rust-lang-nursery/edition-guide#332)
|
|
- drop_flag_effects: `pub` items within are all re-exported in `lib.rs`.
- un_derefer: doesn't contain any `pub` items.
|
|
|
