There are a few places were we have to construct it, though, and a few
places that are more invasive to change. To do this, we create a
constructor with a long obvious name.
There are a few places were we have to construct it, though, and a few
places that are more invasive to change. To do this, we create a
constructor with a long obvious name.
These features include:
- V for vector extension
- Zfinx, Zdinx, Zhinx and Zhinxmin float in integer register extensions
- Zfh, Zfhmin 16-bit float pointer extensions
- Zbkb, Zkbc, Zbkc, Zk* cryptography extensions
It matches name in LLVM feature and is_riscv_feature_detected!.
Update books
## reference
8 commits in 9d289c05fce7254b99c6a0d354d84abb7fd7a032..0a2fe6651fbccc6416c5110fdf5b93fb3cb29247
2022-02-23 08:58:20 -0800 to 2022-03-15 09:32:25 -0700
- Documentation PR for cfg_panic (rust-lang/reference#1157)
- Document aarch64 `target_feature` options (rust-lang/reference#1102)
- Try to clarify destructor not being run scenario. (rust-lang/reference#1107)
- Add undocumented Punctuation token Tilde `~` (rust-lang/reference#1149)
- update UB list for safe target_feature (rust-lang/reference#1050)
- Update const_eval.md for feature stabilization (rust-lang/reference#1166)
- Remove `.intel_syntax`/`.att_syntax` support entirely.
- Fix `.intel_syntax` directive
## book
3 commits in 3f255ed40b8c82a0434088568fbed270dc31bf00..036e88a4f135365de85358febe5324976a56030a
2022-02-27 21:26:12 -0500 to 2022-03-04 21:53:33 -0500
- Fix some links and small wordings
- Snapshot of chapter 19 for nostarch
- Clarify fully-qualified syntax explanation
## rust-by-example
2 commits in 2a928483a20bb306a7399c0468234db90d89afb5..d504324f1e7dc7edb918ac39baae69f1f1513b8e
2022-02-28 11:36:59 -0300 to 2022-03-07 09:26:32 -0300
- Fixed extra indentation at line 43 in Phantom Testcase example. (rust-lang/rust-by-example#1515)
- Typo fixed in description of inline ASM cpuid function (rust-lang/rust-by-example#1514)
## rustc-dev-guide
3 commits in 32f2a5b4e7545318846185198542230170dd8a42..0e4b961a9c708647bca231430ce1b199993e0196
2022-03-01 10:45:24 -0600 to 2022-03-14 08:40:37 -0700
- update winget install instructions to ensure proper packages are installed (-e for --exact, and full package names to ensure arbitrary packages from
the msstore source aren't installed)
- Add missing rustdoc tests explanations
- Fix incorrectly escaped backtick
Rollup of 5 pull requests
Successful merges:
- #94868 (Format core and std macro rules, removing needless surrounding blocks)
- #94951 (Extend the irrefutable_let_patterns lint to let chains)
- #94955 (Refactor: Use `format_args_capture` in some parts of `rustc_parse`)
- #94957 (Improve the explanation about the behaviour of read_line)
- #94974 (Ensure that `let_else` does not interact with `let_chains`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Extend the irrefutable_let_patterns lint to let chains
Implements the suggestion from https://github.com/rust-lang/rust/pull/94927#issuecomment-1067078300
We only look for complete suffixes or prefixes of irrefutable let patterns, so
that an irrefutable let pattern in a chain surrounded by refutable ones is
not linted, as it is an useful pattern that has no low-cost replacement (unlike suffixes or prefixes which can just be copied outside of the `if`: either into the `if`'s block, or the block surrounding the `if`).
If all patterns in a let chain are irrefutable, we lint as well.
Depends on #94958 ~~so I included it into the PR for now~~ *which has been merged since*.
r? `@estebank`
cc `@joshtriplett` `@c410-f3r`
Format core and std macro rules, removing needless surrounding blocks
Many of the asserting and printing macros in `core` and `std` are written with prehistoric-looking formatting, like this:
335ffbfa54/library/std/src/macros.rs (L96-L101)
In modern Rust style this would conventionally be written as follows instead, always using braces and a trailing semicolon on the macro arms:
af53809c87/library/std/src/macros.rs (L98-L105)
Getting rid of the unneeded braces inside the expansion reduces extraneous indentation in macro-expanded code. For example:
```rust
println!("repro {}", true);
```
```rust
// before:
{
::std::io::_print(
::core::fmt::Arguments::new_v1(
&["repro ", "\n"],
&[::core::fmt::ArgumentV1::new_display(&true)],
),
);
};
```
```rust
// after:
::std::io::_print(
::core::fmt::Arguments::new_v1(
&["repro ", "\n"],
&[::core::fmt::ArgumentV1::new_display(&true)],
),
);
```
Only look for complete suffixes or prefixes of irrefutable let patterns, so
that an irrefutable let pattern in a chain surrounded by refutable ones is
not linted, as it is an useful pattern.
As of version 0.2.120 of the libc crate, the solaris target now requires
some additional libraries to be present in the sysroot. Note that the
solaris target doesn't really build against files from Solaris, but
rather against some files from DilOS (a platform similar to both Solaris
and illumos). Pull in the extra libraries and their compilation links
from that apt repository.
Add GUI test to check URLs
The first commit merges both file doing kinda the same thing. Didn't make much sense to keep them separated.
The second commit add checks to ensure the URL has the expected value depending if the search is displayed or not.
r? `@notriddle`
Rollup of 4 pull requests
Successful merges:
- #94810 (debuginfo: Fix bug in type name generation for dyn types with associated types but no other generic arguments.)
- #94947 (fix typos)
- #94956 (Fix small typo in FIXME)
- #94958 (Support other types of pluralization in pluralize macro)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix typos
Rework of #94603 which got closed as I was trying to unmerge and repush. This is a subset of changes from the original pr as I sed'd whatever typos I remembered from the original PR
thanks to `@cuishuang` for the original PR
debuginfo: Fix bug in type name generation for dyn types with associated types but no other generic arguments.
For types like `&dyn Future<Output=bool>` the compiler currently emits invalid types names in debuginfo. This PR fixes this.
Before:
```txt
// DWARF
&dyn core::future::future::Future, Output=bool>
// CodeView
ref$<dyn$<core::future::future::Future,assoc$<Output,bool> > > >
```
After:
```txt
// DWARF
&dyn core::future::future::Future<Output=bool>
// CodeView
ref$<dyn$<core::future::future::Future<assoc$<Output,bool> > > >
```
These syntactically incorrect type names can cause downstream tools (e.g. debugger extensions) crash when trying to parse them.
r? `@wesleywiser`
