Fixes#13507.
I haven't familiarized myself with this part of the rust compiler, so hopefully there are no mistakes (despite the simplicity of the commit). It is also 5am.
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:
```rust
struct Baz<'x> {
bar: &'x int
}
impl<'x> Baz<'x> {
fn baz1(&self) -> &int {
self.bar
}
}
```
`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
Before, the `--crate-file-name` flag only checked crate attributes for
possible crate types. Now, if any type is specified by one or more
`--crate-type` flags, only the filenames for those types will be
emitted, and any types specified by crate attributes will be ignored.
Some of this documentation got a little out of date. There was no mention of a
`SyncSender`, and the entire "Outside the runtime" section isn't really true any
more (or really all that relevant).
This also updates a few other doc blocks and adds some examples.
This is intended to be the first thing somebody new to the language reads about Rust. It is supposed to be simple and intriguing, to give the user an idea of whether Rust is appropriate for them, and to hint that there's a lot of cool stuff to learn if they just keep diving deeper.
I'm particularly happy with the sequence of concurrency examples.
Before, normal compilation and the --crate-file-name flag would
generate output based on both #![crate_type] attributes and
--crate-type flags. Now, if one or more flag is specified by command
line, only those will be used.
Closes#11573.
This bug was introduced in #13384 by accident, and this commit continues the
work of #13384 by finishing support for loading a syntax extension crate without
registering it with the local cstore.
Closes#13495
A mismatched type with more type parameters than the expected one causes
`typeck` looking up out of the bound of type parameter vector, which
leads to ICE.
Closes#13466
This is a series of inter-related commits which depend on #13402 (Prune the paths that do not appear in the index). Please consider this as an early review request; I'll rebase this when the parent PR get merged and rebase is required.
----
This PR aims at reducing the search index without removing the actual information. In my measurement with both library and compiler docs, the search index is 52% smaller before gzipped, and 16% smaller after gzipped:
```
1719473 search-index-old.js
1503299 search-index.js (after #13402, 13% gain)
724955 search-index-new.js (after this PR, 52% gain w.r.t. #13402)
262711 search-index-old.js.gz
214205 search-index.js.gz (after #13402, 18.5% gain)
179396 search-index-new.js.gz (after this PR, 16% gain w.r.t. #13402)
```
Both the uncompressed and compressed size of the search index have been accounted. While the former would be less relevant when #12597 (Web site should be transferring data compressed) is resolved, the uncompressed index will be around for a while anyway and directly affects the UX of docs. Moreover, LZ77 (and gzip) can only remove *some* repeated strings (since its search window is limited in size), so optimizing for the uncompressed size often has a positive effect on the compressed size as well.
Each commit represents the following incremental improvements, in the order:
1. Parent paths were referred by its AST `NodeId`, which tends to be large. We don't need the actual node ID, so we remap them to the smaller sequential numbers. This also means that the list of paths can be a flat array instead of an object.
2. We remap each item type to small predefined numbers. This is strictly intended to reduce the uncompressed size of the search index.
3. We use arrays instead of objects and reconstruct the original objects in the JavaScript code. Since this removes a lot of boilerplates, this affects both the uncompressed and compressed size.
4. (I've found that a centralized `searchIndex` is easier to handle in JS, so I shot one global variable down.)
5. Finally, the repeated paths in the consecutive items are omitted (replaced by an empty string). This also greatly affects both the uncompressed and compressed size.
There had been several unsuccessful attempts to reduce the search index. Especially, I explicitly avoided complex optimizations like encoding paths in a compressed form, and only applied the optimizations when it had a substantial gain compared to the changes. Also, while I've tried to be careful, the lack of proper (non-smoke) tests makes me a bit worry; any advice on testing the search indices would be appreciated.
Since the items roughly follow the lexical order, there are
many consecutive items with the same path value which can be
easily compressed.
For the library and compiler docs, this commit decreases
the index size by 26% and 6% before and after gzip, respectively.
`buildIndex` JS function recovers them into the original object form.
This greatly reduces the size of the uncompressed search index (27%),
while this effect is less visible after gzipped (~5%).
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.
Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!
[1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
This bug was introduced in #13384 by accident, and this commit continues the
work of #13384 by finishing support for loading a syntax extension crate without
registering it with the local cstore.
Closes#13495
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.
Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!
[1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
The current error message is misleading, it asks users to add `#[feature(..)]` which ends up being treated as an outer attribute, which then has no error unless `attribute_usage` lint is enforced. The code will still fail and the user might not understand why.
This fixes two separate issues related to character encoding.
* Add `encode_utf16` to the `Char` trait, analogous to `encode_utf8`. `&str` already supports UTF-16 encoding but only with a heap allocation. Also fix `encode_utf8` docs and add tests.
* Correctly decode non-BMP hex escapes in JSON (#13064).
Previously, all slices derived from a vector whose values were of size 0 had a
null pointer as the 'data' pointer on the slice. This caused first pointer to be
yielded during iteration to always be the null pointer. Due to the null pointer
optimization, this meant that the first return value was None, instead of
Some(&T).
This commit changes slice construction from a Vec instance to use a base pointer
of 1 if the values have zero size. This means that the iterator will never
return null, and the iteration will proceed appropriately.
Closes#13467
Previously, upstream C libraries were linked in a nondeterministic fashion
because they were collected through iter_crate_data() which is a nodeterministic
traversal of a hash map. When upstream rlibs had interdependencies among their
native libraries (such as libfoo depending on libc), then the ordering would
occasionally be wrong, causing linkage to fail.
This uses the topologically sorted list of libraries to collect native
libraries, so if a native library depends on libc it just needs to make sure
that the rust crate depends on liblibc.
Rust advertises itself as being compatible with linux 2.6.18, but the timerfd
set of syscalls weren't added until linux 2.6.25. There is no real need for a
specialized timer implementation beyond being a "little more accurate", but the
select() implementation will suffice for now.
If it is later deemed that an accurate timerfd implementation is needed, it can
be added then through some method which will allow the standard distribution to
continue to be compatible with 2.6.18
Closes#13447
Rust advertises itself as being compatible with linux 2.6.18, but the timerfd
set of syscalls weren't added until linux 2.6.25. There is no real need for a
specialized timer implementation beyond being a "little more accurate", but the
select() implementation will suffice for now.
If it is later deemed that an accurate timerfd implementation is needed, it can
be added then through some method which will allow the standard distribution to
continue to be compatible with 2.6.18
Closes#13447
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
* `Sender::try_send(t: T) -> bool`
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
* `SyncSender::try_send(t: T) -> TrySendResult<T>`
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
* `SyncSender::send_opt(t: T) -> Option<T>`
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
* `Receiver::try_recv(t: T) -> TryRecvResult<T>`
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes#11527
A mismatched type with more type parameters than the expected one causes
`typeck` looking up out of the bound of type parameter vector, which
leads to ICE.
Closes#13466
Same representation change performed with path::unix.
This also implements BytesContainer for StrBuf & adds an (unsafe) method
for viewing & mutating the raw byte vector of a StrBuf.
Previously, all slices derived from a vector whose values were of size 0 had a
null pointer as the 'data' pointer on the slice. This caused first pointer to be
yielded during iteration to always be the null pointer. Due to the null pointer
optimization, this meant that the first return value was None, instead of
Some(&T).
This commit changes slice construction from a Vec instance to use a base pointer
of 1 if the values have zero size. This means that the iterator will never
return null, and the iteration will proceed appropriately.
Closes#13467
Previously, upstream C libraries were linked in a nondeterministic fashion
because they were collected through iter_crate_data() which is a nodeterministic
traversal of a hash map. When upstream rlibs had interdependencies among their
native libraries (such as libfoo depending on libc), then the ordering would
occasionally be wrong, causing linkage to fail.
This uses the topologically sorted list of libraries to collect native
libraries, so if a native library depends on libc it just needs to make sure
that the rust crate depends on liblibc.
Add more type signatures to the docs; tweak a few of them.
Someone reading the docs won't know what the types of various things
are, so this adds them in a few meaningful places to help with
comprehension.
cc #13423.
Someone reading the docs won't know what the types of various things
are, so this adds them in a few meaningful places to help with
comprehension.
cc #13423.
Cleans up some remnants of the old mutability system and only allows vector/trait mutability in `VstoreSlice` (`&mut [T]`) and `RegionTraitStore` (`&mut Trait`).
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes#11527
libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and port all code over to use it.
Rebased & tests-fixed version of https://github.com/mozilla/rust/pull/13269
Previously, a private use statement would shadow a public use statement, all of
a sudden publicly exporting the privately used item. The correct behavior here
is to only shadow the use for the module in question, but for now it just
reverts the entire name to private so the pub use doesn't have much effect.
The behavior isn't exactly what we want, but this no longer has backwards
compatibility hazards.
Previously resolve was checking the "import resolution" for whether an import
had succeeded or not, but this was the same structure filled in by a previous
import if a name is shadowed. Instead, this alters resolve to consult the local
resolve state (as opposed to the shared one) to test whether an import succeeded
or not.
Closes#13404
Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:
use std::c_str;
mod test {
use c_str::CString;
}
This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.
As a consequence of this patch, this code, while valid today, is now invalid:
mod test {
use std::c_str;
unsafe fn foo() {
::test::c_str::CString::new(0 as *u8, false);
}
}
While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.
Closes#12612
When calculating the sysroot, it's more accurate to use realpath() rather than
just one readlink() to account for any intermediate symlinks that the rustc
binary resolves itself to.
For rpath, realpath() is necessary because the rpath must dictate a relative
rpath from the destination back to the originally linked library, which works
more robustly if there are no symlinks involved.
Concretely, any binary generated on OSX into $TMPDIR requires an absolute rpath
because the temporary directory is behind a symlink with one layer of
indirection. This symlink causes all relative rpaths to fail to resolve.
cc #11734
cc #11857
Concerns have been raised about using absolute rpaths in #11746, and this is the
first step towards not relying on rpaths at all. The only current use case for
an absolute rpath is when a non-installed rust builds an executable that then
moves from is built location. The relative rpath back to libstd and absolute
rpath to the installation directory still remain (CFG_PREFIX).
Closes#11746
Rebasing of #12754
I think that the test case from this issue has become out of date with resolve
changes in the past 9 months, and it's not entirely clear to me what the
original bug was.
Regardless, it seems like tricky resolve behavior, so tests were added to make
sure things resolved correctly and warnings were correctly reported.
Closes#7663
This commit makes sure that code inlined from other functions isn't assigned the source position of the call site, since this leads to undesired behavior when setting line breakpoints (issue #12886)
This fixes the categorization of the upvars of procs (represented internally
as once fns) to consider usage to require a loan. In doing so, upvars are no
longer allowed to be moved out of repeatedly in loops and such.
Closes#10398Closes#12041Closes#12127
This commit changes the way move errors are reported when some value is
captured by a PatIdent. First, we collect all of the "cannot move out
of" errors before reporting them, and those errors with the same "move
source" are reported together. If the move is caused by a PatIdent (that
binds by value), we add a note indicating where it is and suggest the
user to put `ref` if they don't want the value to move. This makes the
"cannot move out of" error in match expression nicer (though the extra
note may not feel that helpful in other places :P). For example, with
the following code snippet,
```rust
enum Foo {
Foo1(~u32, ~u32),
Foo2(~u32),
Foo3,
}
fn main() {
let f = &Foo1(~1u32, ~2u32);
match *f {
Foo1(num1, num2) => (),
Foo2(num) => (),
Foo3 => ()
}
}
```
Errors before the change:
```rust
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10 Foo1(num1, num2) => (),
^~~~~~~~~~~~~~~~
test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer
test.rs:11 Foo2(num) => (),
^~~~~~~~~
```
After:
```rust
test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer
test.rs:9 match *f {
^~
test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, you can use `ref num1` to capture value by reference)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:10:20: 10:24 note: and here (use `ref num2`)
test.rs:10 Foo1(num1, num2) => (),
^~~~
test.rs:11:14: 11:17 note: and here (use `ref num`)
test.rs:11 Foo2(num) => (),
^~~
```
Close#8064
* Use `setq-local' instead of (set (make-local-variable ...) value).
Provides a version for older Emacsen.
* Remove use of `cl.el'.
* Use \' in file regexp instead of line end match $.
* Use type for defcustom and add parent group.
This fixes the categorization of the upvars of procs (represented internally
as once fns) to consider usage to require a loan. In doing so, upvars are no
longer allowed to be moved out of repeatedly in loops and such.
Closes#10398Closes#12041Closes#12127
This commit removes the compiler support for floating point modulus operations,
as well as from the language. An implementation for this operator is now
required to be provided by libraries.
Floating point modulus is rarely used, doesn't exist in C, and is always lowered
to an fmod library call by LLVM, and LLVM is considering removing support
entirely.
Closes#12278
Previously, if statements of the form "Foo;" or "let _ = Foo;" were encountered
where Foo had a destructor, the destructors were not run. This changes
the relevant locations in trans to check for ty::type_needs_drop and invokes
trans_to_lvalue instead of trans_into.
Closes#4734Closes#6892
Closes#13394 (sync: remove unsafe and add Send+Share to Deref (enabled by autoderef vtables))
Closes#13389 (Made libflate functions return Options instead of outright failing)
Closes#13388 (doc: Document flavorful variations of paths)
Closes#13387 (Register new snapshots)
Closes#13386 (std: Add more docs for ptr mod)
Closes#13384 (Tweak crate loading to load less metadata)
Closes#13382 (fix ~ZeroSizeType rvalues)
Closes#13378 (Update tidy script, replace XXX with FIXME)
Closes#13377 (std: User a smaller stdin buffer on windows)
Closes#13369 (Fix spelling errors in comments.)
Closes#13314 (Made 'make install' include libs for additional targets)
Closes#13278 (std: make vec!() macro handle a trailing comma)
Closes#13276 (Add test for #11881)
Apparently windows doesn't like reading from stdin with a large buffer size, and
it also apparently is ok with a smaller buffer size. This changes the reader
returned by stdin() to return an 8k buffered reader for stdin rather than a 64k
buffered reader.
Apparently libuv has run into this before, taking a peek at their code, with a
specific comment in their console code saying that "ReadConsole can't handle big
buffers", which I presume is related to invoking ReadFile as if it were a file
descriptor.
Closes#13304
Few places where previous version of tidy script cannot find XXX:
* inside one-line comment preceding by a few spaces;
* inside multiline comments (now it finds it if multiline comment starts
on the same line with XXX).
Change occurences of XXX found by new tidy script.
This is an optimization which is quite impactful for compiling small crates.
Reading libstd's metadata takes about 50ms, and a hello world before this change
took about 100ms (this change halves that time).
Recent changes made it such that this optimization wasn't performed, but I think
it's a better idea do to this for now. See #10786 for tracking this issue.
When linking, all crates in the local CStore are used to link the final product.
With #[phase(syntax)], crates want to be omitted from this linkage phase, and
this was achieved by dumping the entire CStore after loading crates. This causes
crates like the standard library to get loaded twice. This loading process is a
fairly expensive operation when dealing with decompressing metadata.
This commit alters the loading process to never register syntax crates in
CStore. Instead, only phase(link) crates ever make their way into the map of
crates. The CrateLoader trait was altered to return everything in one method
instead of having separate methods for finding information.
This separate crate cache is one factor which is causing libstd to be loaded
twice during normal compilation. The crates loaded for syntax extensions have a
separate cache than the crates loaded for linking, so all crates are loaded once
per #[phase] they're tagged with.
This removes the cache and instead uses the CStore structure itself as the cache
for loaded crates. This should allow crates loaded during the syntax phase to be
shared with the crates loaded during the link phase.
This appears to be causing the BSD bots to lock up when looking at the core
dumps I've managed to get. Dropping the `FileDesc` structure triggers the `Arc`
it's contained in to get cleaned up, invoking free(). This instead just closes
the file descriptor (the arc itself is never cleaned up).
I'm still not entirely sure why this is a problem because the pthreads runtime
should register hooks for fork() to prevent this sort of deadlock, but perhaps
that's only done on linux?
... also don't read the whole directory if the glob for that path
component doesn't contain any metacharacters.
Patterns like `../*.jpg` will work now, and `.*` will match both `.` and
`..` to be consistent with shell expansion.
As before: Just `*` still won't match `.` and `..`, while it will still
match dotfiles like `.git` by default.
Add requirements of TotalEq and TotalOrd
Clarify that TotalEq needs an underlying equivalence relation and that TotalOrd
needs a total ordering and specifically named the required (and sufficient)
attributes.
This test relies on the parent to be descheduled before the child sends its
data. This has proved to be unreliable on libnative on the bots. It's a fairly
trivial test regardless, so ignoring it for now won't lose much.
`Reader`, `Writer`, `MemReader`, `MemWriter`, and `MultiWriter` now work with `Vec<u8>` instead of `~[u8]`. This does introduce some extra copies since `from_utf8_owned` isn't usable anymore, but I think that can't be helped until `~str`'s representation changes.
In the error message for when a private field is used, include the name of the struct, or if it's a struct-like enum variant, the names of the variant and the enum.
This fixes#13341.
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
Clarify that TotalEq needs an underlying equivalence relation and that TotalOrd
needs a total ordering and specifically named the required (and sufficient)
attributes.
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
This test relies on the parent to be descheduled before the child sends its
data. This has proved to be unreliable on libnative on the bots. It's a fairly
trivial test regardless, so ignoring it for now won't lose much.
In summary these are some example transitions this change makes:
'a || => ||: 'a
proc:Send() => proc():Send
The intended syntax for closures is to put the lifetime bound not at the front
but rather in the list of bounds. Currently there is no official support in the
AST for bounds that are not 'static, so this case is currently specially handled
in the parser to desugar to what the AST is expecting. Additionally, this moves
the bounds on procedures to the correct position, which is after the argument
list.
The current grammar for closures and procedures is:
procedure := 'proc' [ '<' lifetime-list '>' ] '(' arg-list ')'
[ ':' bound-list ] [ '->' type ]
closure := [ 'unsafe' ] ['<' lifetime-list '>' ] '|' arg-list '|'
[ ':' bound-list ] [ '->' type ]
lifetime-list := lifetime | lifetime ',' lifetime-list
arg-list := ident ':' type | ident ':' type ',' arg-list
bound-list := bound | bound '+' bound-list
bound := path | lifetime
This does not currently handle the << ambiguity in `Option<<'a>||>`, I am
deferring that to a later patch. Additionally, this removes the support for the
obsolete syntaxes of ~fn and &fn.
Closes#10553Closes#10767Closes#11209Closes#11210Closes#11211
Fix an unnecessary use of `cast::transmute`
Wherever possible, more specialized variants of said functions should be used,
such as in this case `cast::transmute_mmut_unsafe`.
This can be a frustrating error message, ideally we should print the signature mismatch, but hinting that it's a trait incompatibility helps tracking root cause. Also beefed up the testcases for this.
Ideally we would print the signature mismatch in the error helper?
rustc: move the check_loop pass earlier.
This pass is purely AST based, and by running it earlier we emit more
useful error messages, e.g. type inference fails in the case of
`let r = break;` with few constraints on `r`, but it's more useful to be told that
the `break` is outside the loop (rather than a type error) when it is.
Closes#13292.
