about summary refs log tree commit diff
path: root/compiler/rustc_span/src
AgeCommit message (Collapse)AuthorLines
2020-09-21Add cfg(target_has_atomic_equal_alignment).Mara Bos-0/+1
This is needed for Atomic::from_mut.
2020-09-21Reduce boilerplate for BytePos and CharPosJames Whaley-82/+55
2020-09-21fix typo in docs and commentsyuk1ty-1/+1
2020-09-21Auto merge of #76295 - mati865:remove-mmx, r=Amanieu,oli-obkbors-1/+0
Remove MMX from Rust Follow-up to https://github.com/rust-lang/stdarch/pull/890 This removes most of MMX from Rust (tests pass with small changes), keeping stable `is_x86_feature_detected!("mmx")` working.
2020-09-20Remove MMX from RustMateusz MikuĊ‚a-1/+0
2020-09-20Rollup merge of #76825 - lcnr:array-windows-apply, r=varkorRalf Jung-2/+8
use `array_windows` instead of `windows` in the compiler I do think these changes are beautiful, but do have to admit that using type inference for the window length can easily be confusing. This seems like a general issue with const generics, where inferring constants adds an additional complexity which users have to learn and keep in mind.
2020-09-20use `array_windows` instead of `windows` in the compilerBastian Kauschke-2/+8
2020-09-17Remove redundant #![feature(...)] 's from compiler/est31-2/+0
2020-09-16Rollup merge of #75304 - Aaron1011:feature/diag-deref-move-out, r=estebankDylan DPC-0/+2
Note when a a move/borrow error is caused by a deref coercion Fixes #73268 When a deref coercion occurs, we may end up with a move error if the base value has been partially moved out of. However, we do not indicate anywhere that a deref coercion is occuring, resulting in an error message with a confusing span. This PR adds an explicit note to move errors when a deref coercion is involved. We mention the name of the type that the deref-coercion resolved to, as well as the `Deref::Target` associated type being used.
2020-09-13Add visualization of rustc span in docIvan Tham-1/+19
It took me quite some time to figure out what Span::to means. A picture is worth a thousand words.
2020-09-10Note when a a move/borrow error is caused by a deref coercionAaron Hill-0/+2
Fixes #73268 When a deref coercion occurs, we may end up with a move error if the base value has been partially moved out of. However, we do not indicate anywhere that a deref coercion is occuring, resulting in an error message with a confusing span. This PR adds an explicit note to move errors when a deref coercion is involved. We mention the name of the type that the deref-coercion resolved to, as well as the `Deref::Target` associated type being used.
2020-09-10implement `const_evaluatable_checked` feature MVPBastian Kauschke-0/+1
2020-08-31Adds two source span utility functions used in source-based coverageRich Kadel-0/+16
`span.is_empty()` - returns true if `lo()` and `hi()` are equal. This is not only a convenience, but makes it clear that a `Span` can be empty (that is, retrieving the source for an empty `Span` will return an empty string), and codifies the (otherwise undocumented--in the rustc_span package, at least) fact that `Span` is a half-open interval (where `hi()` is the open end). `source_map.lookup_file_span()` - returns an enclosing `Span` representing the start and end positions of the file enclosing the given `BytePos`. This gives developers a clear way to quickly determine if any any other `BytePos` or `Span` is also from the same file (for example, by simply calling `file_span.contains(span)`). This results in much simpler code and is much more runtime efficient compared with the obvious alternative: calling `source_map.lookup_line()` for any two `Span`'s byte positions, handle both arms of the `Result` (both contain the file), and then compare files. It is also more efficient than the non-public method `lookup_source_file_idx()` for each `BytePos`, because, while comparing the internal source file indexes would be efficient, looking up the source file index for every `BytePos` or `Span` to be compared requires a binary search (worst case performance being O(log n) for every lookup). `source_map.lookup_file_span()` performs the binary search only once, to get the `file_span` result that can be used to compare to any number of other `BytePos` or `Span` values and those comparisons are always O(1).
2020-08-30mv compiler to compiler/mark-0/+7270