So if a filemap's last byte is at position n in the codemap, then n+1 will not refer to any filemap, and the next filemap will begin an n+2.
This is useful for empty files, it means that every file (even empty ones) has a byte in the codemap.
Closes#23301, #26504
fix `configure`: allow both `--enable-debug` and `--disable-debuginfo` in one invocation.
This is my very local fix to allow one to be able to (1.) build `rustc` and (2.) run `make check` with internal debug-mode *assertions* turned on in the presence of bugs like #26447 and #26484 (both of which are solely caused by debuginfo and thus can be sidestepped via `--disable-debuginfo`).
This partially addresses #24416 (namely, it addresses the papercut outlined in the description of that ticket). But there are other issues mentioned in the comment thread that are not addressed here, so they should be separately addressed before closing that ticket, or separate bugs should be opened for them.
This fixes a couple of bugs visible on https://doc.rust-lang.org/nightly/std/marker/trait.Sync.html . For example:
* `impl<T> Sync for *const T` should read `impl<T> !Sync for *const T`
* `impl<T> !Sync for Weak<T>` should read `impl<T> !Sync for Weak<T> where T: ?Sized`
This does change a struct in librustdoc and it seems that almost everything there is marked public, so if librustdoc has stability guarantees that could be a problem. If it is, I'll find a way to rework the change to avoid modifying public structures.
I'm being constantly bitten by the lack of this implementation.
I'm unsure if there's a reason to avoid these implementations though.
Since we have a "lossy" implementation for both Mutex and RWLock (RWLock {{ locked }}) I don't think there's a big reason for not having a Debug implementation for the atomic types, even if the user can't specify the ordering.
Fixes#23812 by stripping the decoration when desugaring macro doc comments into #[doc] attributes, and detects whether the attribute should be inner or outer style and outputs the appropriate token tree.
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.mdCloses#27062
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.mdCloses#27062
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Per the title. I've linked to the reference at http://doc.rust-lang.org/reference.html#type-parameters-1, but I'm not sure that's such a good link - but there doesn't seem to be a great deal of explanation elsewhere in the reference either...
