Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes#9510Closes#11533
The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in #11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
Unique pointers and vectors currently contain a reference counting
header when containing a managed pointer.
This `{ ref_count, type_desc, prev, next }` header is not necessary and
not a sensible foundation for tracing. It adds needless complexity to
library code and is responsible for breakage in places where the branch
has been left out.
The `borrow_offset` field can now be removed from `TyDesc` along with
the associated handling in the compiler.
Closes#9510Closes#11533
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
Currently, we have c_void defined to be represented as an empty struct,
but LLVM expects C's void* to be represented as i8*. That means we
currently generate code in which LLVM doesn't recognize malloc() and
free() and can't apply certain optimization that would remove calls to
those functions.
cc @cmr
Temporary change to issue #10535. Requires significant re-factoring to search completely based on the index paths. For example searching for "File::" in this fix will return no results. Still need to search completely based on path (rather than name's + types) to completely fix. Will continue to work this
Made temporary changes to include multiple keywords in rustdoc search
Implemented search based on multiple keywords
Added some commenting and house cleaning
Added path searching to rustdoc
This is a patch for #8005, thanks @lfairy for the hint.
It seems like `block.expr` is None, if the last line of a function has a semi colon (= it ends with a statement).
@kmcallister does this error message cover the intended use cases?
I'm not sure about the message, the wording and the span could probably be improved.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with \<V0>, \<VI0>
and \<VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with <V0>, <VI0>
and <VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
This is unnecessary and also leads to a bug: When the user specifies
```
#[crate_type = "rlib"];
```
rustpkg still creates a dylib.
Also it's good not to duplicate functionality. `build_session_options` handles this just fine.
