Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
Temporarily revert to NonZeroUsize in rustc-abi to fix building on stable
rust-analyzer uses an auto-published version of `rustc-abi`, but `NonZero` isn't yet stable. This prevents us from updating the RA subtree, which is quite old already.
I can file a revert PR after the release.
Improve parser
Fixes#124935.
- Add a few more help diagnostics to incorrect semicolons
- Overall improved that function
- Addded a few comments
- Renamed diff_marker fns to git_diff_marker
android: use posix_memalign for aligned allocations
Our target page says
> Rust will support the most recent Long Term Support (LTS) Android Native Development Kit (NDK). By default Rust will support all API levels supported by the NDK, but a higher minimum API level may be required if deemed necessary.
According to [this](https://github.com/android/ndk/wiki/Changelog-r26), the minimum API level of the current LTS NDK is 21. According to [this](https://stackoverflow.com/questions/44852378/android-ndk-r15b-posix-memalign-undeclared-identifier), posix_memalign exists since API level 16. So I think we should be able to use it here?
Fix println! ICE when parsing percent prefix number
This PR fixes#125002 ICE occurring, for example, with `println!("%100000", 1)` or `println!("% 100000", 1)`.
## Test Case/Change Explanation
The return type of `Num::from_str` has been changed to `Option<Self>` to handle errors when parsing large integers fails.
1. The first `println!` in the test case covers the change of the first `Num::from_str` usage in `format_foreign.rs:426`.
2. The second `println!` in the test case covers the change of the second `Num::from_str` usage in line 460.
3. The 3rd to 5th `Num::from_str` usages behave the same as before.
The 3rd usage would cause an ICE when `num > u16::MAX` in the previous version, but this commit does not include a fix for the ICE in `println!("{:100000$}")`. I think we need to emit an error in the compiler and have more discussion in another issue/PR.
Update cargo
6 commits in 4de0094ac78743d2c8ff682489e35c8a7cafe8e4..0de7f2ec6c39d68022e6b97a39559d2f4dbf3930
2024-05-09 16:09:22 +0000 to 2024-05-17 16:54:54 +0000
- Add special `check-cfg` lint config for the `unexpected_cfgs` lint (rust-lang/cargo#13913)
- refactor: more comments and variable rename (rust-lang/cargo#13924)
- test: set safe.directory for git repo in apache container (rust-lang/cargo#13920)
- refactor: misc refactors for `ops::resolve` (rust-lang/cargo#13917)
- Preserve file permissions on unix during `write_atomic` (rust-lang/cargo#13898)
- Update benchmark formatting for new nightly (rust-lang/cargo#13901)
r? ghost
Inline Duration construction into `Duration::from_{secs,millis,micros,nanos}`
The millis/micros/nanos cases I don't feel as strongly about, but I see no reason why `Duration::from_secs` should call into `Duration::new` - that's just creating unnecessary work for the inlining and DCE passes.
Migrate `run-make/issue64319` to `rmake` and rename
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
~~I noticed that the Makefile was not listed in `allowed-run-makefiles` in Tidy. Does this mean the test was being ignored?~~ EDIT: No, it was there, just not in its expected alphabetical order.
EDIT2: Perhaps it could be interesting to clean this test visually by looping over the `rustc` calls, like in #125227.
Update `expr` matcher for Edition 2024 and add `expr_2021` nonterminal
This commit adds a new nonterminal `expr_2021` in macro patterns, and `expr_fragment_specifier_2024` feature flag.
This change also updates `expr` so that on Edition 2024 it will also match `const { ... }` blocks, while `expr_2021` preserves the current behavior of `expr`, matching expressions without `const` blocks.
Joint work with `@vincenzopalazzo.`
Issue #123742
