This removes all but 6 uses of `drop {}` from the entire codebase. Removing any of the remaining uses causes various non-trivial bugs; I'll start reporting them once this gets merged.
See issue #4869. I'm not quite sure what constitutes "consensus from the core team" (cf. discussion in the issue), but this at least demonstrates that the proposed change is pretty straightforward.
After this change, there are no new test failures. I've un-ignored the `to_str` vectors test; it's not at all obvious to me why it'd be problematic, and it passes on my Linux machine.
r?
#3406
Pretty straightforward. I'm using opaque pointers instead trying to get trans and core to agree on the types of the main function and crate map. One oddity is that this required changing the order of the `-lrustrt` argument to the linker in order to resolve `upcall_new_stack`. Linkers are mysterious.
r?
After this patch, macros declared in a module, function, or block can only be used inside of that module, function or block, with the exception of modules declared with the #[macro_escape] attribute; these modules allow macros to escape, and can be used as a limited macro export mechanism.
This pull request also includes miscellaneous comments, lots of new test cases, a few renamings, and a few as-yet-unused data definitions for hygiene.
This pull request moves the logic from os::make_absolute() into the path module and fixes path joining for Windows. It does this by adding an ``unsafe_join()`` function that implements the operating system's path joining semantics.
Additionally it also adds an ``is_restricted()`` method to the trait which will return true if the path points to a windows device file.
These couldn't be overridden and so ended up being quite restrictive. This has
the side effect of changing the stringification of ~vecs, but nothing in
relied on this. Closes#4869.
r? @graydon - This is for greater uniformity (for example, macros that generate
tuples). rustc already supported 1-tuple patterns, but there was no
way to construct a 1-tuple term.
@graydon , as far as your comment on #4898 - it did turn out to be solvable inside the macro (since @luqmana already fixed it using structs instead), but I still think it's a good idea to allow 1-tuples, for uniformity. I don't think anyone is likely to trip over it, and I'm not too worried that it changes the amount of ambiguity.
