Remove LLVM attribute removal
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function.
Then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
(see [`src/test/codegen/optimize-attr-1.rs`](03a8cc7df1/src/test/codegen/optimize-attr-1.rs (L33)))
However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
r? `@ghost` (blocked on #94221)
`@rustbot` label S-blocked
Rollup of 9 pull requests
Successful merges:
- #94464 (Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.)
- #94476 (7 - Make more use of `let_chains`)
- #94478 (Fix panic when handling intra doc links generated from macro)
- #94482 (compiler: fix some typos)
- #94490 (Update books)
- #94496 (tests: accept llvm intrinsic in align-checking test)
- #94498 (9 - Make more use of `let_chains`)
- #94503 (Provide C FFI types via core::ffi, not just in std)
- #94513 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Provide C FFI types via core::ffi, not just in std
Tracking issue: https://github.com/rust-lang/rust/issues/94501
The ability to interoperate with C code via FFI is not limited to crates
using std; this allows using these types without std.
The existing types in `std::os::raw` become type aliases for the ones in
`core::ffi`. This uses type aliases rather than re-exports, to allow the
std types to remain stable while the core types are unstable.
This also moves the currently unstable `NonZero_` variants and
`c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving
them unstable.
Historically, we didn't do this because these types are target-dependent.
However, `core` itself is also target-dependent. `core` should not call
any OS services, but it knows the target and the target's ABI.
tests: accept llvm intrinsic in align-checking test
This changed in upstream change https://reviews.llvm.org/D98152 (aka
a266af7211)
wherein LLVM got smarter about using intrinsics. As best I can tell the
change I've made here preserves the intent of the test on LLVM 14 and
before while also passing on LLVM 15 and later.
Update books
## nomicon
1 commits in 90993eeac93dbf9388992de92965f99cf6f29a03..f6d6126fc96ecf4a7f7d22da330df9506293b0d0
2022-02-13 12:44:12 +0900 to 2022-02-26 02:21:21 +0900
- ffi: explicitly declare hello_from_rust for C99 (rust-lang/nomicon#343)
## reference
20 commits in 70fc73a6b908e08e66aa0306856c5211312f6c05..9d289c05fce7254b99c6a0d354d84abb7fd7a032
2022-02-14 19:33:01 -0800 to 2022-02-23 08:58:20 -0800
- Fix typo in `functions.md` (rust-lang/reference#1173)
- Fix CI
- Unify global_asm/asm directive list
- Update src/inline-assembly.md
- Update src/inline-assembly.md
- Fix changes unintentional reverted in d5d3d80
- Add note about operand interpolations
- Sort lists, add syntax control directives
- Add another missed batch suggestion
- Add missed batch suggestion
- Apply suggestions from code review
- Add .type, .size, and .p2align
- Reformat directive lists
- Add `.inst` directive
- Add missing directives
- Add additional directives in use
- Add `.fill` directive
- Style fixes
- Fix code block
- Add supported Directives list
## book
13 commits in 67b768c0b660a069a45f0e5d8ae2f679df1022ab..3f255ed40b8c82a0434088568fbed270dc31bf00
2022-02-09 21:52:41 -0500 to 2022-02-27 21:26:12 -0500
- Add a back reference about enum variant initializer fns. Fixesrust-lang/book#800.
- Update ch01-03-hello-cargo.md
- ch03-05: Add definite article for the block of code
- Change variable names from "slice" to "values"
- Remove reference to advanced lifetime section that no longer exists
- Fix link to go to the right newtype section
- Remove confusing and redundant part of a sentence about newtypes
- Make transition less repetitive
- Correct wording about associated functions.
- Remove unnecessary extern crate proc_macro
- Clarify that this code is defining, not using a procedural macro
- Add manual regeneration steps for cargo new test
- Update Listing 11-1 to reflect current contents
## rust-by-example
11 commits in 18c0055b8aea49391e8f758a4400097999c9cf1e..2a928483a20bb306a7399c0468234db90d89afb5
2022-01-19 08:51:55 -0300 to 2022-02-28 11:36:59 -0300
- Update destructure_slice.md (rust-lang/rust-by-example#1513)
- Update iter_find.md (rust-lang/rust-by-example#1512)
- Add an example of collecting errors while iterating successes (rust-lang/rust-by-example#1509)
- Fix broken link on asm (rust-lang/rust-by-example#1508)
- Update abort_unwind.md (rust-lang/rust-by-example#1505)
- Remove duplicate text in asm.md (rust-lang/rust-by-example#1506)
- Improve asm clobber example (rust-lang/rust-by-example#1504)
- Add +1 to next_age (rust-lang/rust-by-example#1503)
- fix comment on into_iter() for arrays (rust-lang/rust-by-example#1502)
- Added new Rust 1.58 direct format args (rust-lang/rust-by-example#1501)
- documentation for cfg_panic (rust-lang/rust-by-example#1500)
## rustc-dev-guide
13 commits in 62f58394ba7b203f55ac35ddcc4c0b79578f5706..32f2a5b4e7545318846185198542230170dd8a42
2022-02-11 08:42:50 -0500 to 2022-03-01 10:45:24 -0600
- Add architecture suggestion for Apple silicon (rust-lang/rustc-dev-guide#1320)
- cargo timings has been stabilized (rust-lang/rustc-dev-guide#1319)
- Add known-bug header. (rust-lang/rustc-dev-guide#1311)
- Fix typo (rust-lang/rustc-dev-guide#1315)
- Typo (rust-lang/rustc-dev-guide#1313)
- instrument-coverage has been stabilized.
- symbol-mangling-version has been stabilized
- Fix `Ty` link (rust-lang/rustc-dev-guide#1308)
- Edit glossary (rust-lang/rustc-dev-guide#1302)
- Fix heading levels in the query chapter (rust-lang/rustc-dev-guide#1305)
- Fix link
- Edit "Queries" chapter (rust-lang/rustc-dev-guide#1301)
- Link to The Rust Performance Book (rust-lang/rustc-dev-guide#1300)
## edition-guide
1 commits in beea0a3cdc3885375342fd010f9ad658e6a5e09a..c55611dd6c58bdeb52423b5c52fd0f3c93615ba8
2021-12-05 07:06:45 -0800 to 2022-02-21 14:21:39 +0100
- Remove `+nightly` for `cargo new` (rust-lang/edition-guide#276)
Suggest adding a new lifetime parameter when two elided lifetimes should match up for traits and impls.
Suggest adding a new lifetime parameter when two elided lifetimes should match up for functions in traits and impls.
Issue #94462
Direct users towards using Rust target feature names in CLI
This PR consists of a couple of changes on how we handle target features.
In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).
The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery. And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.
Sponsored by: standard.ai
When CStr moves to core with an alias in std, this can link to
`crate::ffi::CStr`. However, linking in the reverse direction (from core
to std) requires a relative path, and that path can't work from both
core::ffi and std::os::raw (different number of `../` traversals
required).
The ability to interoperate with C code via FFI is not limited to crates
using std; this allows using these types without std.
The existing types in `std::os::raw` become type aliases for the ones in
`core::ffi`. This uses type aliases rather than re-exports, to allow the
std types to remain stable while the core types are unstable.
This also moves the currently unstable `NonZero_` variants and
`c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving
them unstable.
core can't depend on external crates the way std can. Rather than revert
usage of cfg_if, add a copy of it to core. This does not export our
copy, even unstably; such a change could occur in a later commit.
This changed in upstream change https://reviews.llvm.org/D98152 (aka
a266af7211)
wherein LLVM got smarter about using intrinsics. As best I can tell the
change I've made here preserves the intent of the test on LLVM 14 and
before while also passing on LLVM 15 and later.
Rollup of 3 pull requests
Successful merges:
- #94359 (Fix inconsistent symbol mangling of integers constants with -Zverbose)
- #94465 (6 - Make more use of `let_chains`)
- #94470 (⬆️ rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix inconsistent symbol mangling of integers constants with -Zverbose
The `PrettyPrinter` changes formatting of array size and integer
constants based on `-Zverbose`, so its implementation cannot be used in
legacy symbol mangling.
Example symbol demangling before changes:
```console
$ cat a.rs
pub struct A<T>(T);
impl A<[u8; 128]> { pub fn f() {} }
$ rustc --crate-type=lib a.rs -Zverbose=n && nm -C ./liba.rlib
00000000 T a::A<[u8; 128]>::f
$ rustc --crate-type=lib a.rs -Zverbose=y && nm -C ./liba.rlib
00000000 T a::A<[u8; Const { ty. usize, val. Value(Scalar(0x0000000000000080)) }]>::f
```
Check method input expressions once
If the user mistakenly forgets to wrap their method args in a tuple, then the compiler tries to check that types within the tuple match the expression args. This means we call `check_expr` once within this diagnostic code, so when we check the expr once again in `demand_compatible`, we attempt to apply expr adjustments twice, leading to ICEs.
This PR attempts to fix this by skipping the expression type check in `demand_compatible` if we have detected an method arg mismatch at all.
This does lead to a single UI test regressing slightly, due to a diagnostic disappearing, though I don't know if it is generally meaningful to even raise an type error after noting that the argument count is incorrect in a function call, since the user might be providing (in-context) meaningless expressions to the wrong method.
I can adjust this to be a bit more targeted (to just skip checking exprs in `demand_compatible` in the tuple case) if this UI test regression is a problem.
fixes#94334
cc #94291
Also drive-by fixup of `.node_type(expr.hir_id)` to `.expr_ty(expr)`, since that method exists.
Rollup of 7 pull requests
Successful merges:
- #91545 (Generalize "remove `&`" and "add `*`" suggestions to more than one deref)
- #93385 (Rustdoc ty consistency fixes)
- #93926 (Lint against more useless `#[must_use]` attributes)
- #94094 (use BOOL for TCP_NODELAY setsockopt value on Windows)
- #94384 (Add Atomic*::from_mut_slice)
- #94448 (5 - Make more use of `let_chains`)
- #94452 (Sync portable-simd for bitmasks &c.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Sync portable-simd for bitmasks &c.
In the ideal case, where everything works easily and nothing has to be rearranged, it is as simple as:
- `git subtree pull -P library/portable-simd https://github.com/rust-lang/portable-simd - ${branch}`
- write the commit message
- `python x.py test --stage 1` to make sure it runs
- `git push` to your PR-to-rustc branch
If anything borks up this flow, you can fix it with sufficient git wizardry but you are usually better off going back to the source, fixing it, and starting over, before you open the PR.
r? `@calebzulawski`
Add Atomic*::from_mut_slice
Tracking issue #76314 for `from_mut` has a question about the possibility of `from_mut_slice`, and I found a real case for it. A user in the forum had a parallelism problem that could be solved by open-indexing updates to a vector of atomics, but they didn't want to affect the other code using that vector. Using `from_mut_slice`, they could borrow that data as atomics just long enough for their parallel loop.
ref: https://users.rust-lang.org/t/sharing-vector-with-rayon-par-iter-correctly/72022
use BOOL for TCP_NODELAY setsockopt value on Windows
This issue was found by the Wine project and mitigated there [^1].
Windows' setsockopt expects a BOOL (a typedef for int) for TCP_NODELAY
[^2]. Windows itself is forgiving and will accept any positive optlen and
interpret the first byte of *optval as the value, so this bug does not
affect Windows itself, but does affect systems implementing Windows'
interface more strictly, such as Wine. Wine was previously passing this
through to the host's setsockopt, where, e.g., Linux requires that
optlen be correct for the chosen option, and TCP_NODELAY expects an int.
[^1]: d6ea38f32d
[^2]: https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-setsockopt
Lint against more useless `#[must_use]` attributes
This expands the existing `#[must_use]` check in `unused_attributes` to lint against pretty much everything `#[must_use]` doesn't support.
Fixes#93906.
Generalize "remove `&`" and "add `*`" suggestions to more than one deref
Suggest removing more than one `&` and `&mut`, along with suggesting adding more than one `*` (or a combination of the two).
r? `@estebank`
(since you're experienced with these types of suggestions, feel free to reassign)
If they are trying to use features rustc doesn't yet know about,
request a feature request.
Additionally, also warn against using feature names without leading `+`
or `-` signs.
Caching the stable hash of Ty within itself
Instead of computing stable hashes on types as needed, we compute it during interning.
This way we can, when a hash is requested, just hash that hash, which is significantly faster than traversing the type itself.
We only do this for incremental for now, as incremental is the only frequent user of stable hashing.
As a next step we can try out
* moving the hash and TypeFlags to Interner, so projections and regions get the same benefit (tho regions are not nested, so maybe that's not a good idea? Would be nice for dedup tho)
* start comparing types via their stable hash instead of their address?
