profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Migi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

Migi/vaneck 7

Searches for starts to the Van Eck sequence that make it become periodic.

Migi/derive_destructure 6

Destructure Rust structs that implement Drop.

Migi/async-std 0

Async version of the Rust standard library

Migi/liberation-circuit 0

Trapped in a hostile computer system, you must make a way out - RTS/coding game

Migi/MinimalCompsHX 0

Haxe port of Keith Peters minimalcomps

Migi/moveslice 0

A one-function utility crate for moving chunks of elements in a slice around, safely and quickly.

Migi/nalgebra 0

Linear algebra library for Rust.

Migi/noisy_float-rs 0

A rust library for checked floating point operations

Migi/qcell 0

Statically-checked alternatives to RefCell

pull request commentrust-lang/rust

Make `Duration` respect `width` when formatting using `Debug`

I don't understand what went wrong. Looks like the build was cancelled?

Migi

comment created time in 2 days

fork Migi/structopt

Parse command line arguments by defining a struct.

fork in 9 days

issue commentrust-lang/rust

`Duration` `fmt::Debug` impl doesn't honor alignment

Fixed by #88999.

hawkw

comment created time in 9 days

PR opened rust-lang/rust

Make `Duration` handle `width` when formatting using `Debug`

When printing or writing a std::time::Duration using Debug formatting, it previously completely ignored any specified width. This is unlike types like integers and floats, which do pad to width, for both Display and Debug. Curiously, Duration's Debug formatting did consider precision.

Before you ask "who formats Debug output?", note that Duration doesn't actually implement Display, so Debug is currently the only way to format Durations. I think that's wrong, and Duration should get a Display implementation, but in the meantime there's no harm in making the Debug formatting respect width rather than ignore it.

Fixes issue #88059.

+106 -30

0 comment

3 changed files

pr created time in 10 days

push eventMigi/rust

Camille GILLOT

commit sha 31330bfce12f59b9c9a4d7b20235fdc38dcf7583

Use variable.

view details

Guillaume Gomez

commit sha 2627db6a3cc4115cc3ff7a1597eb44347acb0c54

Rollup merge of #86747 - FabianWolff:issue-86653, r=GuillaumeGomez Improve wording of the `drop_bounds` lint This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound. There are two issues with the current warning message and lint description: - First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended. - Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not). cc `@jonhoo,` does this solve the issue for you? r? `@GuillaumeGomez`

view details

Guillaume Gomez

commit sha 3b1e7b1fc9853497140f7f5371882234f0295893

Rollup merge of #87166 - de-vri-es:show-discriminant-before-overflow, r=jackh726 Show discriminant before overflow in diagnostic for duplicate values. This PR adds the value before overflow for explicit discriminant values in the error for duplicate discriminant values. I found it rather confusing to see only the overflowed value. It only does this for literals, since overflows in const evaluated arithmetic are already a hard error. This is my first PR to the compiler, so please let me know if the implementation can be improved :) Before: ![image](https://user-images.githubusercontent.com/786213/125850097-bf5fb7e0-d800-4386-a738-c30f41822964.png) After: ![image](https://user-images.githubusercontent.com/786213/125850120-e2bb765d-ad86-4888-a6cb-dec34fba3fea.png)

view details

Guillaume Gomez

commit sha c6da5b08e0177d0b9053cd7dd6be422ee047d671

Rollup merge of #88077 - kit-981:feature/fix-minimum-os-version-in-header, r=petrochenkov Generate an iOS LLVM target with a specific version This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain. I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command. This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.

view details

Guillaume Gomez

commit sha 2638d27ba56d9d1fac481de95522b00383d44b91

Rollup merge of #88164 - durin42:llvm-14-san-opts, r=nikic PassWrapper: adapt for LLVM 14 changes These API changes appear to have all taken place in https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and AddressSanitizerPass to only accept their options type as a ctor argument instead of the sequence of bools etc. This required a couple of parameter additions, which I made match the default prior to the mentioned upstream LLVM change. This patch restores rustc to building (though not quite passing all tests, I've mailed other patches for those issues) against LLVM HEAD.

view details

Guillaume Gomez

commit sha 167ae26a889649fd6d6499eaeef3e7acd5c9c5df

Rollup merge of #88211 - petrochenkov:withhilo, r=jyn514 cleanup: `Span::new` -> `Span::with_lo` Extracted from https://github.com/rust-lang/rust/pull/84373 as suggested in https://github.com/rust-lang/rust/pull/84373#issuecomment-857773867. It turned out less useful then I expected, but anyway. r? `@cjgillot` `@bors` rollup

view details

Guillaume Gomez

commit sha 5868e2853704b00d6b0256c1503a91a6417b9db9

Rollup merge of #88211 - petrochenkov:withhilo, r=jyn514 cleanup: `Span::new` -> `Span::with_lo` Extracted from https://github.com/rust-lang/rust/pull/84373 as suggested in https://github.com/rust-lang/rust/pull/84373#issuecomment-857773867. It turned out less useful then I expected, but anyway. r? `@cjgillot` `@bors` rollup

view details

Guillaume Gomez

commit sha 518b27b57ae2ce9e3a10f167c36385b1dbbbf614

Rollup merge of #88229 - m-ou-se:macro-suggest-right-kind, r=estebank Suggest importing the right kind of macro. Fixes #88228. r? `@estebank`

view details

Guillaume Gomez

commit sha 3e8e8d2dad6181f58e78c14b9dd19c267ad602c0

Rollup merge of #88238 - m-ou-se:used-imports-no-track-namespace, r=estebank Stop tracking namespace in used_imports. This changes `used_imports` from a `FxHashSet<(NodeId, Namespace)>` to a `FxHashSet<NodeId>`, as the Namespace information isn't used. The only point that uses it did three lookups, `|=`'ing them together. r? `@estebank`

view details

Andreas Liljeqvist

commit sha 5a501f73ff753109c7e73d4981fe011633bd8e84

Use custom wrap-around type instead of Range

view details

bors

commit sha af140757b4cb1a60d107c690720311ba8e06e7de

Auto merge of #88240 - GuillaumeGomez:rollup-wdom91m, r=GuillaumeGomez Rollup of 7 pull requests Successful merges: - #86747 (Improve wording of the `drop_bounds` lint) - #87166 (Show discriminant before overflow in diagnostic for duplicate values.) - #88077 (Generate an iOS LLVM target with a specific version) - #88164 (PassWrapper: adapt for LLVM 14 changes) - #88211 (cleanup: `Span::new` -> `Span::with_lo`) - #88229 (Suggest importing the right kind of macro.) - #88238 (Stop tracking namespace in used_imports.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

view details

Andreas Liljeqvist

commit sha 1b4064f04a5d9f2ff910f448f65e3396502ff280

fix 32bit err

view details

linux1

commit sha f28793dd13e8a8132d559629728e6ca9514dbe36

Feat: added inline asm support for s390x

view details

linux1

commit sha 5f5afba5fbb869db26c4f9e88c29bad94007dfd1

Feat: added s390x reg-definitions, constraint codes, and tests

view details

linux1

commit sha 7095dfffc3bde0fc56a837241db84e414e3d9b25

Refactor: added #[no_mangle]

view details

linux1

commit sha 66e95b17ecfc93e39b1846436a86f0e924ab30b3

Fix: moved #[no_mangle]

view details

linux1

commit sha eeb0b52bf852b902b2bd1adaf919c35e2387ce28

Feat: further testing & support for i64 general register use

view details

linux1

commit sha 0c9e23c7ce964438b107d064533b89f024e7ccf8

Fix: appeased x.py test tidy --bless

view details

bors

commit sha 558553272d5f80ca6484ed3de961fe4f1a9d411d

Auto merge of #88200 - pcwalton:no-dso-local-on-mach-o, r=nagisa Stop emitting the `dso_local` LLVM attribute for external symbols under the static relocation model on macOS. This matches Clang's behavior: https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1038-L1040 Even if `dso_local` were properly supported in this way on macOS, it seems incorrect to add this annotation as liberally as we did. The `dso_local` annotation is for symbols that ultimately end up in the same linkage unit, but we were adding this annotation even for `static` values inside `extern` blocks marked with `#[link(type="framework")]`, which should be considered dynamically linked. Note that Clang likewise avoids emitting `dso_local` for `dllimport` symbols: https://github.com/llvm/llvm-project/blob/973cb2c326be9f256da0897c4d2ef117dc22761d/clang/lib/CodeGen/CodeGenModule.cpp#L1005-L1007 This issue caused breakage in the `ring` crate, which links to a symbol defined in `Security.framework` that ultimately resolves to address `0x0`: https://github.com/briansmith/ring/blob/b94d61e044b42827fefd71d5f61e8c58a7659870/src/rand.rs#L390 For this symbol, the use of `dso_local` causes LLVM to emit a relocation of type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the binary is large enough, `0x0` might be out of range, and the link will fail. Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset and cause the link to succeed. As a side note, the static relocation model is effectively deprecated for security reasons on macOS, as it prohibits PIE. It's also completely unsupported on Apple Silicon, so I don't think it's worth going to the effort of properly supporting this model on that platform.

view details

Dan Gohman

commit sha a0ce5f25fab82f52eb65248dbf452f6d7a485d24

Remove redundant conversions.

view details

push time in 10 days

issue commentrust-lang/rust

Debug trait for tuples, array/slices, Vec, String (etc?) do not respect `width` parameter

This issue has been reported independently several times over the years: see issues #43909, #55584, #55749, #83361, #87905, #88059. Clearly people do try to apply formatting parameters to Debug-formatted values.

I tested some of the most common types for how their Debug implementations currently handle width and precision. Here's a Playground link. In summary:

width precision
integers pads as expected irrelevant
floats pads as expected handled as expected
strings ignored ignored
Duration ignored handled as expected
booleans pads as expected weird: println!("{:.3?}", false) prints fal
() pads as expected weird: println!("{:.1?}", ()) prints (
Slices / Vec pads each element (!) applied to each element
Structs/enums using #[derive(Debug)] pads each member (!) applied to each member

To clarify the last 2: Slices, Vecs, and structs/enums using #[derive(Debug)] all simply forward the width and precision to a recursive Debug::fmt call that formats their member values. For example, println!("{:.5?}", [1., 2.]) prints [1.00000, 2.00000]. That seems reasonable for precision, but for width it pads (and aligns) each element of the slice/struct to width, which is kind of weird. It's unfortunate that width can't be implemented for slices and structs like it is for other types by padding the entire thing to the given width. That would require allocations, but Debug is part of std::core.

I will try to implement the following changes:

  • Make Duration pad to width rather than ignore it
  • Make strings pad to width rather than ignore it
  • Fix the weird behavior of booleans and () for precision
pnkfelix

comment created time in 12 days

issue commentrust-lang/rust

format!() ignores width when displaying enums

If I understand correctly, this is not a bug and the issue can be closed. Any implementation of Display needs to ensure it implements the parameters it wants to support, either manually or by delegating to a different Display implementation. It does not (and cannot) happen automatically.

dimo414

comment created time in 12 days

pull request commentuazu/qcell

Add `TCellOwner::try_new` and `TCellOwner::wait_for_new`

The intent of that test was just to stress-test that everything still works in an extreme scenario, not necessarily as a recommendation that users should use the API like that.

Migi

comment created time in a month

PR opened uazu/qcell

Add `TCellOwner::try_new` and `TCellOwner::wait_for_new`

This commit adds two new functions:

  • TCellOwner::try_new: checks if a TCellOwner already exists, and returns None if it does.
  • TCellOwner::wait_for_new: if a TCellOwner already exists, it blocks the thread until that existing owner is dropped.

Internally, this was implemented using a single static Condvar. If a wait_for_new call finds that a TCellOwner with its marker type Q already exists, it waits for this Condvar. Any time a TCellOwner is dropped, all threads waiting for this Condvar are woken up and check if the TCellOwner that was dropped was their marker type Q.

Performance-wise, this means that dropping a TCellOwner is now a tiny bit slower (the Condvar::notify_all call). This should be completely insignificant for any realistic use case. The performance of every other method (including TCellOwner::new) is unaffected. TCellOwner::wait_for_new is just as fast as TCellOwner::new if there is no need to wait.

+166 -5

0 comment

3 changed files

pr created time in a month

push eventMigi/qcell

Michiel De Muycnk

commit sha 54f3554968a3a98efe81c0d4c7b1851fa008b6dd

Add `TCellOwner::try_new` and `TCellOwner::wait_for_new` This commit adds two new functions: - `TCellOwner::try_new`: checks if a `TCellOwner` already exists, and returns `None` if it does. - `TCellOwner::wait_for_new`: if a `TCellOwner` already exists, it blocks the thread until that existing owner is dropped. Internally, this was implemented using a single static `Condvar`. If a `wait_for_new` call finds that a `TCellOwner` with its marker type `Q` already exists, it waits for this `Condvar`. Any time a `TCellOwner` is dropped, all threads waiting for this `Condvar` are woken up and check if the `TCellOwner` that was dropped was their marker type `Q`. Performance-wise, this means that dropping a `TCellOwner` is now a tiny bit slower (the `Condvar::notify_all` call). This should be completely insignificant for any realistic use case. The performance of every other method (including `TCellOwner::new`) is unaffected. `TCellOwner::wait_for_new` is just as fast as `TCellOwner::new` if there is no need to wait.

view details

push time in a month

push eventMigi/qcell

Michiel De Muycnk

commit sha da33f04035444a17d1fa34c5956194986f6958f4

Add `TCellOwner::try_new` and `TCellOwner::wait_for_new` This commit adds two new functions: - `TCellOwner::try_new`: checks if a `TCellOwner` already exists, and returns `None` if it does. - `TCellOwner::wait_for_new`: if a `TCellOwner` already exists, it blocks the thread until that existing owner is dropped. Internally, this was implemented using a single static `Condvar`. If a `wait_for_new` call finds that a `TCellOwner` with its marker type `Q` already exists, it waits for this `Condvar`. Any time a `TCellOwner` is dropped, all threads waiting for this `Condvar` are woken up and check if the `TCellOwner` that was dropped was their marker type `Q`. Performance-wise, this means that dropping a `TCellOwner` is now a tiny bit slower (the `Condvar::notify_all` call). This should be completely insignificant for any realistic use case. The performance of every other method (including `TCellOwner::new`) is unaffected. `TCellOwner::wait_for_new` is just as fast as `TCellOwner::new` if there is no need to wait.

view details

push time in a month

push eventMigi/qcell

Jim Peters

commit sha 011677a4dc3ec0608816ab94e5e957de6406f96c

Merge pull request #4 from Migi/master Implement Sync for QCell, LCell and LCellOwner, and Send for TCell.

view details

Jim Peters

commit sha ab0bbf6d4adf1964ff2b7cce795b4b23f4dbc90a

Separate TLCell from TCell / Send and Sync - Cargo features must be additive, so the old no-thread-local feature was removed and TLCell (thread-local type-based cell) is now a separate type from TCell (process-wide type-based cell). - Send and Sync support was documented and tested

view details

Jim Peters

commit sha a37f3bf6e41d599587b025b1a2d19e35c95943bf

Add `trybuild` to check compile_fail doctests / 0.4.0 - Existing doctests remain as the 'master' source of the tests (because they are more readable for humans), but compile-fail tests are now extracted with a script to test with `trybuild` to check that the compile failures are the expected ones

view details

Ozaren

commit sha 39b09f5dbfda55ab097b941aa38d34837970ae81

added a few extra bits of functionality This allows other crates to build unsafe abstractoins on top of these cells

view details

Ozaren

commit sha c4a683dc4a088bf4fc98a8c0f8f7dea78a71d8a2

added a test for `QCellOwner::owns`

view details

Ozaren

commit sha 584e7a171acaa2a3c539f6e0a4ed8aae32bc7498

fix docs for `as_ptr` https://github.com/uazu/qcell/pull/10#pullrequestreview-336386469

view details

Jim Peters

commit sha fbc76b7745b1f7edc91d33d37c4c61b7227f2462

Merge pull request #10 from KrishnaSannasi/extra-bits Add `as_ptr` and `owns` methods

view details

Jim Peters

commit sha 7f3dc9b63417258aa7468f94b1dba52e5f26027a

Revert "Merge pull request #10 from KrishnaSannasi/extra-bits" This doesn't seem to be used. The PR was accepted 6 months ago but not released in any crate version. It may confuse safety reviewers.

view details

Jim Peters

commit sha dee960013d2e03afc534781e42d90132ebf9e4de

Switch from `lazy_static` to `once_cell` / 0.4.1 - Also check and update compiletests for Rust 1.44

view details

push time in a month