A work-in-progress programming language; not yet suitable for users
Empowering everyone to build reliable and efficient software.
WIP Rust port of https://github.com/nikomatsakis/a-mir-formality
A PROLOG-ish interpreter written in Rust, intended eventually for use in the compiler
UCSC Genome Browser Hub Builder
a PLT redex model of MIR and its type system
The Rust Programming Language Blog
push eventrust-lang/blog.rust-lang.org
commit sha 0d34bbb3adf4d53dde03c35dff464d028e9c0294
grammar fixes in 2023-01-20-types-announcement.md
commit sha 125abbfdd38fd55d5dcb023ed622a766df1da318
ok
commit sha 56e18fa0497fa122f8e49c125cc80a178123b264
Merge pull request #1065 from gardrek/patch-2 grammar fixes in 2023-01-20-types-announcement.md
push time in 3 days
PR merged rust-lang/blog.rust-lang.org
Just one added word and one removed word.
pr closed time in 3 days
pull request commentrust-lang/blog.rust-lang.org
grammar fixes in 2023-01-20-types-announcement.md
Thanks :)
comment created time in 3 days
push eventjackh726/bigtools
commit sha 9f73adf8fc71b5b1bb1868b5f24e2ca98ad9e0bc
Update bench.py
push time in 3 days
pull request commentrust-lang/rust
Don't use `can_eq` in `derive(..)` suggestion for missing method
@bors r+ rollup
comment created time in 3 days
Pull request review commentrust-lang/blog.rust-lang.org
grammar fixes in 2023-01-20-types-announcement.md
As mentioned above, a nearly essential element of the growing Rust language is t As far back as 2015, not long after the release of Rust 1.0, an experimental Rust trait solver called Chalk began to be written. The core idea of Chalk is to translate the surface syntax and ideas of the Rust trait system (e.g. traits, impls, where clauses) into a set of logic rules that can be solved using a Prolog-like solver. Then, once this set of logic and solving reaches parity with the trait solver within the compiler itself, the plan was to simply replace the existing solver. In the meantime (and continuing forward), this new solver could be used by other tools, such as rust-analyzer, where it is used today. -Now, given Chalk's age and the promises it had been hoped to be able to deliver on, you might be tempted to ask the question "Chalk, when?" - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the *compiler* are quite different than the needs of a *formalization*: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.+Now, given Chalk's age and the promises it had hoped to be able to deliver on, you might be tempted to ask the question "Chalk, when?" - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the *compiler* are quite different than the needs of a *formalization*: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.
So, realizing that this PR never got merged.
Ultimately, I'm happy to keep it `it had been hoped to be able to deliver on" or "it had been hoped it would be able to deliver on".
Once you change that, I should be able to merge this PR.
comment created time in 3 days
Pull request review commentrust-lang/rust
Make `EarlyBinder`'s inner value private
fn build_call_shim<'tcx>( let sig = sig.map_bound(|sig| tcx.erase_late_bound_regions(sig)); assert_eq!(sig_substs.is_some(), !instance.has_polymorphic_mir_body());- let mut sig =- if let Some(sig_substs) = sig_substs { sig.subst(tcx, &sig_substs) } else { sig.0 };+ let mut sig = if let Some(sig_substs) = sig_substs {+ sig.subst(tcx, &sig_substs)+ } else {+ sig.skip_binder()
This type of pattern was always sketchy to me. Adding the EarlyBinder type makes it clear why.
I'm not sure how polymorphization works; seems like this could be a byproduct of it.
comment created time in 5 days
issue commentrust-lang/rust
I agree with @lcnr here. (But ultimately either way just very happy that there is no #[defines] required
comment created time in 5 days
pull request commentrust-lang/rust
`EarlyBinder::new` -> `EarlyBinder::bind`
@bors r+
comment created time in 7 days
push eventjackh726/bigtools
commit sha 8ace29019acb4677c0a91dff2896ae4c0b53ea52
Use vec of bytes instead of Bytes
push time in 7 days
push eventjackh726/bigtools
commit sha 749dedee4efd7e666f5786c4e7d2a8661de2aa88
Don't pass around ByteOrdered or BufReader
commit sha 2731bb7037ff90dd3fb6ad2e87a0f14e4d7d06aa
Use vec of bytes instead of Bytes
push time in 7 days
push eventjackh726/bigtools
commit sha b4c8196850a77f9e5ffee7a5f7f5c8a38bd0c2bc
Remove MemCachedFile. It doesn't actually do all that much (if anything).
commit sha 8484208b39515b4cb6a3c163a3d08a2828ee193e
Add explicit option for parallel in bedgraphtobigwig and bench
commit sha 8408b3876f8a94c4b7ff49096bfa2df7ae6575a5
Move chrom_map and chrom_id out of bed parsing
commit sha 49aac0e71c42f69ae96b96729be0a2f2d2ec429a
Make sure we report a stored error
commit sha 7c73701b89f9793d9092d2ffe0a5019373801e47
Add rough but working parallel implementation to bigwigaverageoverbed
push time in 7 days
pull request commentrust-lang/rust
Fix linkage for large binaries on mips64 platforms
@bors r+
comment created time in 7 days
pull request commentrust-lang/rust
feat: `riscv-interrupt-{m,s}` calling conventions
This likely needs some lang and/or compiler team okay
comment created time in 8 days
pull request commentrust-lang/rust
compiler: update solaris/illumos to enable tsan support.
Thanks!
@bors r+ rollup
comment created time in 8 days
pull request commentrust-lang/rust
compiler: update solaris/illumos to enable tsan support.
Sorry, I'm definitely not familiar here. What would the OS_NAME for these targets be there? SunOS?
comment created time in 8 days
pull request commentrust-lang/rust
Make `EarlyBinder`'s inner value private
@bors r+
comment created time in 8 days
pull request commentrust-lang/rust
Make `EarlyBinder`'s inner value private
r=me with rebase :)
@bors p=1
comment created time in 8 days
pull request commentrust-lang/rust
compiler: update solaris/illumos to enable tsan support.
Is there any documentation for this one way or another?
comment created time in 8 days
push eventjackh726/bigtools
commit sha 1041b69c6c44e2651ba368eb10733e2f56bf3c4b
Read into BytesMut instead of individiual read_*
commit sha 749dedee4efd7e666f5786c4e7d2a8661de2aa88
Don't pass around ByteOrdered or BufReader
commit sha a3de60d7131e46347e2caac59281b7e68478247d
Remove MemCachedReader type alias
push time in 9 days
pull request commentrust-lang/rust
refactor and cleanup the leak check, add it to new solver
If you want to split them out, r=me on the first 4 commits
comment created time in 12 days
Pull request review commentrust-lang/rust
Fix linkage for large binaries on mips64 platforms
def build_bootstrap(self, color, verbose_count): # preserve existing RUSTFLAGS env.setdefault("RUSTFLAGS", "")+ # FIXME: remove this if condition on the next bootstrap bump+ # cfg(bootstrap)+ if self.build_triple().startswith('mips'):+ env["RUSTFLAGS"] += " -Ctarget-feature=+xgot"
This should ideally have a comment why this exists.
comment created time in 12 days
pull request commentrust-lang/rust
Use apple-m1 as target CPU for aarch64-apple-darwin.
Seems like from the comments this is appropriate
@bors r+ rollup
comment created time in 12 days
pull request commentrust-lang/rust
Work around `rust-analyzer` false-positive type errors
Honestly, this is such a small, semantically equivalent change that ultimately doesn't hurt readability, so I'm going to r+ it.
In general though, I agree with oli that we shouldn't try to work around tooling issues, particularly if they impact readability or maintainability.
@bors r+ rollup
comment created time in 12 days