| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Refactor AnonSocket::read/write for blocking socketpair
|
|
sysconf adding few more constants.
|
|
|
|
follow-up on #4052, making a miri evaluation context fn for strerror_r.
|
|
|
|
sysconf interception fix for solarish systems.
|
|
also adding the `_SC_PAGESIZE` alias `_SC_PAGE_SIZE` supported by
Linux, macOS and FreeBSD.
close #4050
|
|
eventfd: comment tweaks
|
|
Automatic Rustup
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
Fill out windows io error mapping table
|
|
[AIX] change system dynamic library format
Historically on AIX, almost all dynamic libraries are distributed in `.a` Big Archive Format which can consists of both static and shared objects in the same archive (e.g. `libc++abi.a(libc++abi.so.1)`). During the initial porting process, the dynamic libraries are kept as `.a` to simplify the migration, but semantically having an XCOFF object under the archive extension is wrong. For crate type `cdylib` we want to be able to distribute the libraries as archives as well.
We are migrating to archives with the following format:
```
$ ar -t lib<name>.a
lib<name>.so
```
where each archive contains a single member that is a shared XCOFF object that can be loaded.
|
|
|
|
|
|
|
|
ci: Disable full `debuginfo-level=2` in windows alt job
try-job: dist-x86_64-msvc-alt
|
|
|
|
fmt
fix cfg for windows
remove unused imports
address comments
update libc to 0.2.164
fmt
remove unused imports
|
|
Rollup of 6 pull requests
Successful merges:
- #130236 (unstable feature usage metrics)
- #131544 (Make asm label blocks safe context)
- #131586 (Support s390x z13 vector ABI)
- #132489 (Fix closure arg extraction in `extract_callable_info`, generalize it to async closures)
- #133078 (tests: ui/inline-consts: add issue number to a test, rename other tests)
- #133283 (Don't exclude relnotes from `needs-triage` label)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't exclude relnotes from `needs-triage` label
So initially we *didn't* exclude `needs-triage` label, then we did exclude them in #132825 as sometimes the `needs-triage` is redundant. However, I think they are probably worth double-checking because often some of the labels are only accurate/relevant for the *implementation* PR, but not for the purposes of the relnotes tracking issue. Furthermore, sometimes relevant team labels can be removed. So to make it less likely for relnotes to slip through, I think we should still label relnotes-tracking-issues with `needs-triage`.
cc https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release/topic/Please.20CC.20lang
r? release
|
|
tests: ui/inline-consts: add issue number to a test, rename other tests
rename other tests from a_b_c to a-b-c
|
|
Fix closure arg extraction in `extract_callable_info`, generalize it to async closures
* Fix argument extraction in `extract_callable_info`
* FIx `extract_callable_info` to work for async closures
* Remove redundant `is_fn_ty` which is just a less general `extract_callable_info`
* More precisely name what is being called (i.e. call it a "closure" not a "function")
Review this without whitespace -- I ended up reformatting `extract_callable_info` because some pesky `//` comments were keeping the let-chains from being formatted.
|
|
Support s390x z13 vector ABI
cc #130869
This resolves the following fixmes:
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/abi/call/s390x.rs#L1-L2
- https://github.com/rust-lang/rust/blob/58420a065b68ecb3eec03b942740c761cdadd5c4/compiler/rustc_target/src/spec/targets/s390x_unknown_linux_gnu.rs#L9-L11
Refs: Section 1.2.3 "Parameter Passing" and section 1.2.5 "Return Values" in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1)
This PR extends ~~https://github.com/rust-lang/rust/pull/127731~~ https://github.com/rust-lang/rust/pull/132173 (merged) 's ABI check to handle cases where `vector` target feature is disabled.
If we do not do ABI check, we run into the ABI problems as described in https://github.com/rust-lang/rust/issues/116558 and https://github.com/rust-lang/rust/issues/130869#issuecomment-2408268044, and the problem of the compiler generating strange code (https://github.com/rust-lang/rust/pull/131586#discussion_r1799003554).
cc `@uweigand`
`@rustbot` label +O-SystemZ +A-ABI
|
|
Make asm label blocks safe context
Tracking issue: https://github.com/rust-lang/rust/issues/119364
`asm!()` is forced to be wrapped inside unsafe. If there's no special treatment, the label blocks would also always be unsafe with no way of opting out. It was suggested that a simple fix is to make asm label blocks safe: https://github.com/rust-lang/rust/issues/119364#issuecomment-2316037703.
`@rustbot` labels: +A-inline-assembly +F-asm
|
|
unstable feature usage metrics
example output
```
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat src/lib.rs
───────┬───────────────────────────────────────────────────────
│ File: src/lib.rs
───────┼───────────────────────────────────────────────────────
1 │ #![feature(unix_set_mark)]
2 │ pub fn add(left: u64, right: u64) -> u64 {
3 │ left + right
4 │ }
5 │
6 │ #[cfg(test)]
7 │ mod tests {
8 │ use super::*;
9 │
10 │ #[test]
11 │ fn it_works() {
12 │ let result = add(2, 2);
13 │ assert_eq!(result, 4);
14 │ }
15 │ }
───────┴───────────────────────────────────────────────────────
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cargo +stage1 rustc -- -Zmetrics-dir=$PWD/metrics
Compiling test-lib v0.1.0 (/home/yaahc/tmp/test-lib)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
test-lib on master [?] is 📦 v0.1.0 via 🦀 v1.80.1
❯ cat metrics/unstable_feature_usage.json
───────┬─────────────────────────────────────────────────────────────────────
│ File: metrics/unstable_feature_usage.json
───────┼─────────────────────────────────────────────────────────────────────
1 │ {"lib_features":[{"symbol":"unix_set_mark"}],"lang_features":[]}
```
related to https://github.com/rust-lang/rust/issues/129485
|
|
#124141 preliminaries
Preliminary changes required to start removing `Nonterminal` (https://github.com/rust-lang/rust/pull/124141).
r? `@petrochenkov`
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #131736 (Emscripten: link with -sWASM_BIGINT)
- #132207 (Store resolution for self and crate root module segments)
- #133153 (Add visits to nodes that already have flat_maps in ast::MutVisitor)
- #133218 (Implement `~const` item bounds in RPIT)
- #133228 (Rewrite `show_md_content_with_pager`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rustup
|
|
|
|
|
|
r=tgross35
Rewrite `show_md_content_with_pager`
`show_md_content_with_pager` is complex and has a couple of bugs. This PR improves it.
r? ``@tgross35``
|
|
Implement `~const` item bounds in RPIT
an RPIT in a `const fn` is allowed to be conditionally const itself :)
r? fee1-dead or reroll
|
|
Add visits to nodes that already have flat_maps in ast::MutVisitor
This PR aims to add `visit_` methods for every node that has a `flat_map_` in MutVisitor, giving implementers free choice over overriding `flat_map` for 1-to-n conversions or `visit` for a 1-to-1.
There is one major problem: `flat_map_stmt`.
While all other default implementations of `flat_map`s are 1-to-1 conversion, as they either only call visits or a internal 1-to-many conversions are natural, `flat_map_stmt` doesn't follow this pattern.
`flat_map_stmt`'s default implementation is a 1-to-n conversion that panics if n > 1 (effectively being a 1-to-[0;1]). This means that it cannot be used as is for a default `visit_stmt`, which would be required to be a 1-to-1.
Implementing `visit_stmt` without runtime checks would require it to reach over a potential `flat_map_item` or `filter_map_expr` overrides and call for their `visit` counterparts directly.
Other than that, if we want to keep the behavior of `flat_map_stmt` it cannot call `visit_stmt` internally.
To me, it seems reasonable to make all default implementations 1-to-1 conversions and let implementers handle `visit_stmt` if they need it, but I don't know if calling `visit` directly when a 1-to-1 is required is ok or not.
related to #128974 & #127615
r? ``@petrochenkov``
|
|
Store resolution for self and crate root module segments
Let's make sure to record the segment resolution for `self::`, `crate::` and `$crate::`.
I'm actually somewhat surprised that the only diagnostic that uses this is the one that errors on invalid generics on a module segment... but seems strictly more correct regardless, and there may be other diagnostics using these segments resolutions that just haven't been tested for `self`. Also includes a drive-by on `report_prohibit_generics_error`.
|
|
Emscripten: link with -sWASM_BIGINT
When linking an executable without dynamic linking, this is a pure improvement. It significantly reduces code size and avoids a lot of buggy behaviors. It is supported in all browsers for many years and in all maintained versions of Node.
It does change the ABI, so people who are dynamically linking with a library or executable that uses the old ABI may need to turn it off. It can be disabled if needed by passing `-Clink-arg -sWASM_BIGINT=0` to `rustc`. But few people will want to turn it off.
Note this includes a libc bump to 0.2.162!
|
|
|
|
Update LLVM to 19.1.4
Fixes https://github.com/rust-lang/rust/issues/125619
r? `@DianQK`
|
|
Rollup of 6 pull requests
Successful merges:
- #129838 (uefi: process: Add args support)
- #130800 (Mark `get_mut` and `set_position` in `std::io::Cursor` as const.)
- #132708 (Point at `const` definition when used instead of a binding in a `let` statement)
- #133226 (Make `PointerLike` opt-in instead of built-in)
- #133244 (Account for `wasm32v1-none` when exporting TLS symbols)
- #133257 (Add `UnordMap::clear` method)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
trophy case: add RwLock::downgrade bug
|
|
I think the control flow in this function is complicated and confusing,
largely due to the use of two booleans `print_formatted` and
`fallback_to_println` that are set in multiple places and then used to
guide proceedings.
As well as hurting readability, this leads to at least one bug: if the
`write_termcolor_buf` call fails and the pager also fails, the function
will try to print color output to stdout, but that output will be empty
because `write_termcolor_buf` failed. I.e. the `if fallback_to_println`
body fails to check `print_formatted`.
This commit rewrites the function to be neater and more Rust-y, e.g. by
putting the result of `write_termcolor_buf` into an `Option` so it can
only be used on success, and by using `?` more. It also changes
terminology a little, using "pretty" to mean "formatted and colorized".
The result is a little shorter, more readable, and less buggy.
|
