summary refs log tree commit diff
path: root/compiler/rustc_span/src/lib.rs
AgeCommit message (Collapse)AuthorLines
2020-09-23/nightly/nightly-rustcErik Hofmayer-1/+1
2020-09-23Updated html_root_url for compiler cratesErik Hofmayer-1/+1
2020-09-21Remove cast to usize for BytePos and CharPosJames Whaley-2/+2
The case shouldn't be necessary and implicitly truncating BytePos is not desirable.
2020-09-21Reduce boilerplate for BytePos and CharPosJames Whaley-82/+55
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-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-08-31Adds two source span utility functions used in source-based coverageRich Kadel-0/+7
`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/+1872