Create your own GitHub profile
Sign up for your own profile on GitHub, the best place to host code, manage projects, and build software alongside 50 million developers.
Sign up
Pinned
1,434 contributions in the last year
Activity overview
Contribution activity
October 2020
Created a pull request in rust-lang/rust that received 31 comments
Fully destructure slice and array constants into patterns
There were a lot of workarounds for making such constants not opaque, now we expand all constants into patterns unless they are not structural match
- TypeVisitor: use `std::ops::ControlFlow` instead of `bool`
- Try not to copy when allocating from iterators, take 3
- MIR validation should check `SwitchInt` values are valid for the type
- New mir-opt pass to simplify gotos with const values
- fix static_ptr_ty for foreign statics
- I can't stop writing copy propagation passes
- Optimize const value interning for ZST types
- Implement const expressions and patterns (RFC 2920)
- Make fewer types generic over QueryContext
- Tweak "object unsafe" errors
- rustc_parse: fix spans on cast and range exprs with attrs
- Codegen backend interface refactor
- ICEs should always print the top of the query stack
- Add a MIR pass manager
- added a lint against function references
- fix VecDeque::iter_mut aliasing issues
- builtin_macros: Fix use of interpolated identifiers in `asm!`
- Ignore mir tests on big-endian
- stabilize const_int_pow
- Doc alias name restriction
- Disable the SimplifyArmIdentity mir-opt
- MIR-OPT: Less conservative `EarlyOtherwiseBranch`
- rustc_metadata: Do not forget to encode inherent impls for foreign types
- Remove the old copy propagation pass
Created an issue in rust-lang/rust that received 40 comments
Must a `const fn` behave exactly the same at runtime as at compile-time?
TLDR: should we allow floating point types in const fn? Basically the question is whether the following const fn const fn foo(a: f32, b: f32) -> f32 …