This is an implementation of the rustc bits of [RFC 403][rfc]. This adds a new
flag to the compiler, `-l`, as well as tweaking the `include!` macro (and
related source-centric macros).
The compiler's new `-l` flag is used to link libraries in from the command line.
This flag stacks with `#[link]` directives already found in the program. The
purpose of this flag, also stated in the RFC, is to ease linking against native
libraries which have wildly different requirements across platforms and even
within distributions of one platform. This flag accepts a string of the form
`NAME[:KIND]` where `KIND` is optional or one of dylib, static, or framework.
This is roughly equivalent to if the equivalent `#[link]` directive were just
written in the program.
The `include!` macro has been modified to recursively expand macros to allow
usage of `concat!` as an argument, for example. The use case spelled out in RFC
403 was for `env!` to be used as well to include compile-time generated files.
The macro also received a bit of tweaking to allow it to expand to either an
expression or a series of items, depending on what context it's used in.
[rfc]: https://github.com/rust-lang/rfcs/pull/403
I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable `x` (especially when `x` is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing `x` in such cases. ;)
I’m not super happy about the matching-on-range example, as it’s too contrived (`e` and `x` are exactly the same here), but I couldn’t come up with something both simple and non-redundant.
This commit enables implementations of IndexMut for a number of collections,
including Vec, RingBuf, SmallIntMap, TrieMap, TreeMap, and HashMap. At the same
time this deprecates the `get_mut` methods on vectors in favor of using the
indexing notation.
cc #18424
I just found this patch which at some point solved a problem I encountered. Unfortunately I apparently dropped it before I managed to write a test case. I'll try to dig up the code that triggered the issue.
The error messages still aren’t as good as they were before DST, but they better
describe the actual problem, not mentioning `Sized` at all (because that bound
is normally implied, not explicitly stated).
Closes#17567.
Closes#18040.
Closes#18159.
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
