Rollup of 11 pull requests by jhpratt · Pull Request #149940 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
This flag was an artifact of compiletest's old libtest-based test executor, and currently doesn't influence compiletest's output at all.
This commit introduces two new constants to SystemTime: MIN and MAX,
whose value represent the maximum values for the respective data type,
depending upon the platform.
Technically, this value is already obtainable during runtime with the
following algorithm: Use SystemTime::UNIX_EPOCH and call checked_add
(or checked_sub) repeatedly with Duration::new(0, 1) on it, until it
returns None. Mathematically speaking, this algorithm will terminate
after a finite amount of steps, yet it is impractical to run it, as it
takes practically forever.
Besides, this commit also adds a unit test. Concrete implementation depending upon the platform is done in later commits.
In the future, the hope of the authors lies within the creation of a
SystemTime::saturating_add and SystemTime::saturating_sub, similar
to the functions already present in std::time::Duration. However, for
those, these constants are crucially required, thereby this should be
seen as the initial step towards this direction.
Below are platform specifc notes:
Hermit
The HermitOS implementation is more or less identitcal to the Unix one.
sgx
The implementation uses a Duration to store the Unix time, thereby
implying Duration::ZERO and Duration::MAX as the limits.
solid
The implementation uses a time_t to store the system time within a
single value (i.e. no dual secs/nanosecs handling), thereby implying its
::MIN and ::MAX values as the respective boundaries.
UEFI
UEFI has a weird way to store times, i.e. a very complicated struct.
The standard proclaims "1900-01-01T00:00:00+0000" to be the lowest
possible value and MAX_UEFI_TIME is already present for the upper
limit.
Windows
Windows is weird. The Win32 documentation makes no statement on a
maximum value here. Next to this, there are two conflicting types:
SYSTEMTIME and FILETIME. Rust's Standard Library uses FILETIME,
whose limit will (probably) be i64::MAX packed into two integers.
However, SYSTEMTIME has a lower-limit.
xous
It is similar to sgx in the sense of using a Duration.
unsupported
Unsupported platforms store a SystemTime in a Duration, just like
sgx, thereby implying Duration::ZERO and Duration::MAX as the
respective limits.
This logic is cargo-specific anyway, so there is no need for it to be a generally-available helper method.
The INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES lint was missing from
this causing it to be an unknown lint when attempting to allow it.
…toyo
Update rustc_codegen_gcc rotate operation document
Description
This PR resolves a TODO comment in the rustc_codegen_gcc backend by documenting that the rotate operations (rotate_left and rotate_right) already implement the optimized branchless algorithm from comment.
The existing implementation already uses the optimal branchless rotation pattern:
- For left rotation:
(x << n) | (x >> (-n & (width-1))) - For right rotation:
(x >> n) | (x << (-n & (width-1)))
This pattern avoids branches and generates efficient machine code across different platforms, which was the goal mentioned in the original TODO.
Changes
- Removed the TODO comment that suggested implementing the algorithm from https://blog.regehr.org/archives/1063
…=ChrisDenton
Add SystemTime::{MIN, MAX}
Accepted ACP: <rust-lang/libs-team#692> Tracking Issue: <rust-lang#149067>
This merge request introduces two new constants to SystemTime: MIN and MAX, whose values represent the maximum values for the respective data type, depending upon the platform.
Technically, this value is already obtainable during runtime with the following algorithm:
Use SystemTime::UNIX_EPOCH and call checked_add (or checked_sub) repeatedly with Duration::new(0, 1) on it, until it returns None.
Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever.
Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a checked_add and checked_sub on it fail.
In the future, the hope of the authors lies within the creation of a SystemTime::saturating_add and SystemTime::saturating_sub, similar to the functions already present in std::time::Duration.
However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction.
With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time.
This feature (and a related saturating version of checked_{add, sub} has been requested multiple times over the course of the past few years, most notably:
Use let...else instead of match foo { ... _ => return }; and if let ... else return
…49038, r=estebank
Add proper suggestion for associated function with unknown field
Fixes rust-lang#149038
The first commit is changing the old suggestion to verbose, the second commit is a new added suggestion.
r? @estebank
…r=petrochenkov
Fix: Prevent macro-expanded extern crates from shadowing extern arguments
prevents an ICE by fixing a logic bug in build_reduced_graph.rs.
the bug caused the compiler to correctly detect and report a shadowing error for a macro-expanded extern crate but then continue processing the invalid item, corrupting the resolver's internal state (extern_prelude) and leading to a crash in later resolution passes the fix adds an early return after the shadowing error is reported to ensure the invalid item is not added to the resolution graph.
Fixes rust-lang#149821
…sync, r=eholk
Weak for Arc pointer is marked as DynSend/DynSync
std::sync::Weak (weak pointer for Arc) added to DynSend and DynSync (looks like it was missed to add there when implemented).
…=jdonszelmann
Remove unused code in cfg_old
r? @jdonszelmann
Fixes one of the todos from rust-lang#149865
bootstrap: Don't pass an unused --color to compiletest
- Follow-up to rust-lang#149850
This flag was an artifact of compiletest's old libtest-based test executor, and currently doesn't influence compiletest's output at all.
A follow-up commit also inlines force_coloring_in_ci into its only remaining caller, and updates its comment.
…petrochenkov
Add a sanity check in case of any duplicate nodes
A simple check in case compiler tries to encode a dep node twice like in rust-lang#141540.
Also if we'd try to mark a red node as green as it may then create a bad DepNodeIndex like in rust-lang#148295.
If it prevents rust-lang#141540 from emitting a faulty dep-graph.bin file via panic then it means you will be able to temporarily fix it by simply restarting cargo or rust-analyzer without cleaning up incremental cache.
… r=davidtwco
declare_lint_pass for INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES
The INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES lint was missing from this causing it to be an unknown lint when attempting to allow it.
r? @davidtwco
Area: The compiletest test runner
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html)
Area: The testsuite used to check the correctness of rustc
Operating System: Hermit
Target: SGX
Operating System: SOLID
Operating system: Unix-like
Operating system: Windows
Status: Awaiting review from the assignee but also interested parties.
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Relevant to the compiler team, which will review and decide on the PR/issue.
Relevant to the library team, which will review and decide on the PR/issue.
The Rustc Trait System Refactor Initiative (-Znext-solver)
labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit that referenced this pull request
Rollup of 11 pull requests
Successful merges:
- #145278 (Update
rustc_codegen_gccrotate operation document) - #148825 (Add SystemTime::{MIN, MAX})
- #148837 (Use
let...elseinstead ofmatch foo { ... _ => return };andif let ... else return) - #149177 (Add proper suggestion for associated function with unknown field)
- #149843 (Inherit attributes in delegation)
- #149860 (Fix: Prevent macro-expanded extern crates from shadowing extern arguments)
- #149874 (Weak for Arc pointer is marked as DynSend/DynSync)
- #149903 (Remove unused code in
cfg_old) - #149911 (bootstrap: Don't pass an unused
--colorto compiletest) - #149916 (Add a sanity check in case of any duplicate nodes)
- #149924 (
declare_lint_passforINLINE_ALWAYS_MISMATCHING_TARGET_FEATURES)
r? @ghost
@rustbot modify labels: rollup
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels