- TEST(String) - Static method in class com.github.privacystreams.core.purposes.Purpose
-
Testing purpose.
- TestItem - Class in com.github.privacystreams.core.items
-
A random item for testing.
- TestItem(TestObject) - Constructor for class com.github.privacystreams.core.items.TestItem
-
- TestObject - Class in com.github.privacystreams.core.items
-
A mock object for testing.
- TestObject(int, int, String, double) - Constructor for class com.github.privacystreams.core.items.TestObject
-
- TEXT - Static variable in class com.github.privacystreams.accessibility.BrowserSearch
-
The searched text.
- TEXT - Static variable in class com.github.privacystreams.notification.Notification
-
The text of the notification.
- text - Variable in class com.github.privacystreams.utils.AccessibilityUtils.SerializedAccessibilityNodeInfo
-
- TextEntry - Class in com.github.privacystreams.accessibility
-
A user text input action.
- TIME_CREATED - Static variable in class com.github.privacystreams.core.Item
-
The timestamp of when the Item is created.
- TimeConfig() - Constructor for class com.github.privacystreams.utils.Globals.TimeConfig
-
- TimeOperators - Class in com.github.privacystreams.commons.time
-
A helper class to access time-related functions
- TimeOperators() - Constructor for class com.github.privacystreams.commons.time.TimeOperators
-
- timeout(long) - Method in class com.github.privacystreams.core.MStream
-
Limit the stream with a timeout,
stop the stream after some time.
- timeout(long) - Method in interface com.github.privacystreams.core.MStreamInterface
-
Limit the stream with a timeout,
stop the stream after some time.
- timeout(long) - Static method in class com.github.privacystreams.core.transformations.limit.Limiters
-
Limit the stream with a timeout.
- TIMESTAMP - Static variable in class com.github.privacystreams.accessibility.BaseAccessibilityEvent
-
The timestamp of when the item is generated.
- TIMESTAMP - Static variable in class com.github.privacystreams.accessibility.BrowserSearch
-
The timestamp of when the search event is happened.
- TIMESTAMP - Static variable in class com.github.privacystreams.accessibility.BrowserVisit
-
The timestamp of when the web page is visited.
- TIMESTAMP - Static variable in class com.github.privacystreams.audio.Audio
-
The timestamp of when the audio/record was generated.
- TIMESTAMP - Static variable in class com.github.privacystreams.communication.Call
-
The timestamp of when the phone call is happened.
- TIMESTAMP - Static variable in class com.github.privacystreams.communication.Message
-
The timestamp of when the message is sent/received.
- TIMESTAMP - Static variable in class com.github.privacystreams.device.BatteryInfo
-
The timestamp of when the state is requested.
- TIMESTAMP - Static variable in class com.github.privacystreams.device.DeviceEvent
-
The timestamp of when the event is happened.
- TIMESTAMP - Static variable in class com.github.privacystreams.device.DeviceState
-
The timestamp of when the state is requested.
- TIMESTAMP - Static variable in class com.github.privacystreams.device.WifiAp
-
The timestamp of when the WIFI AP information is found.
- TIMESTAMP - Static variable in class com.github.privacystreams.environment.LightEnv
-
The timestamp of when the light sensor value is read.
- TIMESTAMP - Static variable in class com.github.privacystreams.image.Image
-
The timestamp of when the image was generated.
- TIMESTAMP - Static variable in class com.github.privacystreams.location.Geolocation
-
The timestamp of the location.
- TIMESTAMP - Static variable in class com.github.privacystreams.notification.Notification
-
The timestamp of the notification.
- TimeUtils - Class in com.github.privacystreams.utils
-
A helper class to access timestamp-related utilities.
- TimeUtils() - Constructor for class com.github.privacystreams.utils.TimeUtils
-
- TITLE - Static variable in class com.github.privacystreams.accessibility.BrowserVisit
-
The title of current webpage.
- TITLE - Static variable in class com.github.privacystreams.calendar.CalendarEvent
-
Event title.
- TITLE - Static variable in class com.github.privacystreams.notification.Notification
-
The title of the notification.
- toFormattedString(long) - Static method in class com.github.privacystreams.utils.TimeUtils
-
Format a timestamp to a string using the time format at `Globals.TimeConfig.defaultTimeFormat`.
- toFormattedString(String, long) - Static method in class com.github.privacystreams.utils.TimeUtils
-
Format a timestamp to a string using a time format.
- toItem() - Static method in class com.github.privacystreams.core.actions.collect.Collectors
-
Collect the SStream to an Item.
- toItemList() - Static method in class com.github.privacystreams.core.actions.collect.Collectors
-
Collect the MStream to a list of Items.
- toJson() - Method in class com.github.privacystreams.core.Item
-
- toMap() - Method in class com.github.privacystreams.core.Item
-
- toMap() - Method in class com.github.privacystreams.core.Stream
-
- toString() - Method in class com.github.privacystreams.audio.AudioData
-
- toString() - Method in exception com.github.privacystreams.core.exceptions.PSException
-
- toString() - Method in class com.github.privacystreams.core.Function
-
- toString() - Method in class com.github.privacystreams.core.Item
-
- toString() - Method in class com.github.privacystreams.core.items.TestObject
-
- toString() - Method in class com.github.privacystreams.core.purposes.Purpose
-
- toString() - Method in class com.github.privacystreams.core.Stream
-
- toString() - Method in class com.github.privacystreams.image.ImageData
-
- toString() - Method in class com.github.privacystreams.location.LatLng
-
- transform(M2MTransformation) - Method in class com.github.privacystreams.core.MStream
-
Transform the current MStream to another MStream.
- transform(M2STransformation) - Method in class com.github.privacystreams.core.MStream
-
Transform the current MStream to an SStream.
- transform(M2MTransformation) - Method in interface com.github.privacystreams.core.MStreamInterface
-
Transform the current MStream to another MStream.
- transform(M2STransformation) - Method in interface com.github.privacystreams.core.MStreamInterface
-
Transform the current MStream to an SStream.
- transform(S2STransformation) - Method in class com.github.privacystreams.core.SStream
-
Transform current SStream to another SStream.
- transform(S2MTransformation) - Method in class com.github.privacystreams.core.SStream
-
Transform current SStream to a MStream.
- transform(S2STransformation) - Method in interface com.github.privacystreams.core.SStreamInterface
-
Transform current SStream to another SStream.
- transform(S2MTransformation) - Method in interface com.github.privacystreams.core.SStreamInterface
-
Transform current SStream to a MStream.
- TYPE - Static variable in class com.github.privacystreams.communication.Call
-
The type of the phone call, could be "incoming", "outgoing" or "missed".
- TYPE - Static variable in class com.github.privacystreams.communication.Message
-
The message type, could be "received"/"sent"/"draft"/"pending"/"unknown".
- TYPE - Static variable in class com.github.privacystreams.device.DeviceEvent
-
The type of the event, could be "screen", "boot", "battery", "ringer", etc.
- TYPE_BATTERY - Static variable in class com.github.privacystreams.device.DeviceEvent
-
- TYPE_BOOT - Static variable in class com.github.privacystreams.device.DeviceEvent
-
- TYPE_DRAFT - Static variable in class com.github.privacystreams.communication.Message
-
- TYPE_INCOMING - Static variable in class com.github.privacystreams.communication.Call
-
- TYPE_INTERRUPTED - Static variable in exception com.github.privacystreams.core.exceptions.PSException
-
- TYPE_MISSED - Static variable in class com.github.privacystreams.communication.Call
-
- TYPE_OUTGOING - Static variable in class com.github.privacystreams.communication.Call
-
- TYPE_PENDING - Static variable in class com.github.privacystreams.communication.Message
-
- TYPE_PERMISSION_DENIED - Static variable in exception com.github.privacystreams.core.exceptions.PSException
-
- TYPE_RECEIVED - Static variable in class com.github.privacystreams.communication.Message
-
- TYPE_RINGER - Static variable in class com.github.privacystreams.device.DeviceEvent
-
- TYPE_SCREEN - Static variable in class com.github.privacystreams.device.DeviceEvent
-
- TYPE_SENT - Static variable in class com.github.privacystreams.communication.Message
-
- TYPE_UNKNOWN - Static variable in class com.github.privacystreams.communication.Message
-


Rustc-cn
[](https://doc.rust-lang.org/rustc/print.html#what-is-rustc)
What is rustc?
Welcome to “The rustc book”! rustc
is the compiler for the Rust programming language, provided by the project itself. Compilers take your source code and produce binary code, either as a library or executable.
欢迎! rustc 是rust编程语言的编译器。它通过编译rust源码产生库文件或可执行文件。
Most Rust programmers don’t invoke rustc
directly, but instead do it through Cargo. It’s all in service of rustc
though! If you want to see how Cargo calls rustc
, you can
开发人员一般可以通过Cargo来调用rustc, 当然这都是由 rustc 来提供支持. 如果希望了解具体情况 可以执行:
$ cargo build --verbose
And it will print out each rustc
invocation. This book can help you understand what each of these options does. Additionally, while most Rustaceans use Cargo, not all do: sometimes they integrate rustc
into other build systems. This book should provide a guide to all of the options you’d need to do so.
[](https://doc.rust-lang.org/rustc/print.html#basic-usage)
Basic usage
Let’s say you’ve got a little hello world program in a file hello.rs
:
fn main() {
println!("Hello, world!");
}
To turn this source code into an executable, you can use rustc
:
$ rustc hello.rs
$ ./hello # on a *NIX
$ .\hello.exe # on Windows
Note that we only ever pass rustc
the crate root, not every file we wish to compile. For example, if we had a main.rs
that looked like this:
`mod foo;
fn main() { foo::hello(); }`
And a foo.rs
that had this:
pub fn hello() {
println!("Hello, world!");
}
To compile this, we’d run this command:
$ rustc main.rs
No need to tell rustc
about foo.rs
; the mod
statements give it everything that it needs. This is different than how you would use a C compiler, where you invoke the compiler on each file, and then link everything together. In other words, the crate is a translation unit, not a particular module.
[](https://doc.rust-lang.org/rustc/print.html#command-line-arguments)
Command-line arguments
Here’s a list of command-line arguments to rustc
and what they do.
[](https://doc.rust-lang.org/rustc/print.html#a-h--help-get-help)
-h
/--help
: get help
This flag will print out help information for rustc
.
[](https://doc.rust-lang.org/rustc/print.html#a--cfg-configure-the-compilation-environment)
--cfg
: configure the compilation environment
This flag can turn on or off various #[cfg]
settings.
The value can either be a single identifier or two identifiers separated by =
.
For examples, --cfg 'verbose'
or --cfg 'feature="serde"'
. These correspond to #[cfg(verbose)]
and #[cfg(feature = "serde")]
respectively.
[](https://doc.rust-lang.org/rustc/print.html#a-l-add-a-directory-to-the-library-search-path)
-L
: add a directory to the library search path
When looking for external crates, a directory passed to this flag will be searched.
[](https://doc.rust-lang.org/rustc/print.html#a-l-link-the-generated-crate-to-a-native-library)
-l
: link the generated crate to a native library
This flag allows you to specify linking to a specific native library when building a crate.
--crate-type
: a list of types of crates for the compiler to emit
This instructs rustc
on which crate type to build.
[](https://doc.rust-lang.org/rustc/print.html#a--crate-name-specify-the-name-of-the-crate-being-built)
--crate-name
: specify the name of the crate being built
This informs rustc
of the name of your crate.
[](https://doc.rust-lang.org/rustc/print.html#a--emit-emit-output-other-than-a-crate)
--emit
: emit output other than a crate
Instead of producing a crate, this flag can print out things like the assembly or LLVM-IR.
[](https://doc.rust-lang.org/rustc/print.html#a--print-print-compiler-information)
--print
: print compiler information
This flag prints out various information about the compiler.
[](https://doc.rust-lang.org/rustc/print.html#a-g-include-debug-information)
-g
: include debug information
A synonym for -C debuginfo=2
, for more see here.
[](https://doc.rust-lang.org/rustc/print.html#a-o-optimize-your-code)
-O
: optimize your code
A synonym for -C opt-level=2
, for more see here.
[](https://doc.rust-lang.org/rustc/print.html#a-o-filename-of-the-output)
-o
: filename of the output
This flag controls the output filename.
[](https://doc.rust-lang.org/rustc/print.html#a--out-dir-directory-to-write-the-output-in)
--out-dir
: directory to write the output in
The outputted crate will be written to this directory.
--explain
: provide a detailed explanation of an error message
Each error of rustc
’s comes with an error code; this will print out a longer explanation of a given error.
[](https://doc.rust-lang.org/rustc/print.html#a--test-build-a-test-harness)
--test
: build a test harness
When compiling this crate, rustc
will ignore your main
function and instead produce a test harness.
[](https://doc.rust-lang.org/rustc/print.html#a--target-select-a-target-triple-to-build)
--target
: select a target triple to build
This controls which target to produce.
[](https://doc.rust-lang.org/rustc/print.html#a-w-set-lint-warnings)
-W
: set lint warnings
This flag will set which lints should be set to the warn level.
[](https://doc.rust-lang.org/rustc/print.html#a-a-set-lint-allowed)
-A
: set lint allowed
This flag will set which lints should be set to the allow level.
[](https://doc.rust-lang.org/rustc/print.html#a-d-set-lint-denied)
-D
: set lint denied
This flag will set which lints should be set to the deny level.
[](https://doc.rust-lang.org/rustc/print.html#a-f-set-lint-forbidden)
-F
: set lint forbidden
This flag will set which lints should be set to the forbid level.
[](https://doc.rust-lang.org/rustc/print.html#a--cap-lints-set-the-most-restrictive-lint-level)
--cap-lints
: set the most restrictive lint level
This flag lets you ‘cap’ lints, for more, see here.
[](https://doc.rust-lang.org/rustc/print.html#a-c--codegen-code-generation-options)
-C
/--codegen
: code generation options
This flag will allow you to set codegen options.
[](https://doc.rust-lang.org/rustc/print.html#a-v--version-print-a-version)
-V
/--version
: print a version
This flag will print out rustc
’s version.
[](https://doc.rust-lang.org/rustc/print.html#a-v--verbose-use-verbose-output)
-v
/--verbose
: use verbose output
This flag, when combined with other flags, makes them produce extra output.
[](https://doc.rust-lang.org/rustc/print.html#a--extern-specify-where-an-external-library-is-located)
--extern
: specify where an external library is located
This flag allows you to pass the name and location of an external crate that will be linked into the crate you’re buildling.
[](https://doc.rust-lang.org/rustc/print.html#a--sysroot-override-the-system-root)
--sysroot
: Override the system root
The “sysroot” is where rustc
looks for the crates that come with the Rust distribution; this flag allows that to be overridden.
[](https://doc.rust-lang.org/rustc/print.html#a--error-format-control-how-errors-are-produced)
--error-format
: control how errors are produced
This flag lets you control the format of errors.
[](https://doc.rust-lang.org/rustc/print.html#a--color-configure-coloring-of-output)
--color
: configure coloring of output
This flag lets you control color settings of the output.
[](https://doc.rust-lang.org/rustc/print.html#lints)
Lints
In software, a “lint” is a tool used to help improve your source code. The Rust compiler contains a number of lints, and when it compiles your code, it will also run the lints. These lints may produce a warning, an error, or nothing at all, depending on how you’ve configured things.
Here’s a small example:
$ cat main.rs
fn main() {
let x = 5;
}
$ rustc main.rs
warning: unused variable: `x`
--> main.rs:2:9
|
2 | let x = 5;
| ^
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_x` instead
This is the unused_variables
lint, and it tells you that you’ve introduced a variable that you don’t use in your code. That’s not wrong, so it’s not an error, but it might be a bug, so you get a warning.
[](https://doc.rust-lang.org/rustc/print.html#lint-levels)
Lint levels
In rustc
, lints are divided into four levels:
- allow
- warn
- deny
- forbid
Each lint has a default level (explained in the lint listing later in this chapter), and the compiler has a default warning level. First, let’s explain what these levels mean, and then we’ll talk about configuration.
[](https://doc.rust-lang.org/rustc/print.html#allow)
allow
These lints exist, but by default, do nothing. For example, consider this source:
pub fn foo() {}
Compiling this file produces no warnings:
$ rustc lib.rs --crate-type=lib
$
But this code violates the missing_docs
lint.
These lints exist mostly to be manually turned on via configuration, as we’ll talk about later in this section.
[](https://doc.rust-lang.org/rustc/print.html#warn)
warn
The ‘warn’ lint level will produce a warning if you violate the lint. For example, this code runs afoul of the unused_variable
lint:
pub fn foo() {
let x = 5;
}
This will produce this warning:
$ rustc lib.rs --crate-type=lib
warning: unused variable: `x`
--> lib.rs:2:9
|
2 | let x = 5;
| ^
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_x` instead
[](https://doc.rust-lang.org/rustc/print.html#deny)
deny
A ‘deny’ lint produces an error if you violate it. For example, this code runs into the exceeding_bitshifts
lint.
fn main() {
100u8 << 10;
}
$ rustc main.rs
error: bitshift exceeds the type's number of bits
--> main.rs:2:13
|
2 | 100u8 << 10;
| ^^^^^^^^^^^
|
= note: #[deny(exceeding_bitshifts)] on by default
What’s the difference between an error from a lint and a regular old error? Lints are configurable via levels, so in a similar way to ‘allow’ lints, warnings that are ‘deny’ by default let you allow them. Similarly, you may wish to set up a lint that is warn
by default to produce an error instead. This lint level gives you that.
[](https://doc.rust-lang.org/rustc/print.html#forbid)
forbid
‘forbid’ is a special lint level that’s stronger than ‘deny’. It’s the same as ‘deny’ in that a lint at this level will produce an error, but unlike the ‘deny’ level, the ‘forbid’ level can not be overridden to be anything lower than an error. However, lint levels may still be capped with --cap-lints
(see below) so rustc --cap-lints warn
will make lints set to ‘forbid’ just warn.
[](https://doc.rust-lang.org/rustc/print.html#configuring-warning-levels)
Configuring warning levels
Remember our missing_docs
example from the ‘allow’ lint level?
$ cat lib.rs
pub fn foo() {}
$ rustc lib.rs --crate-type=lib
$
We can configure this lint to operate at a higher level, both with compiler flags, as well as with an attribute in the source code.
You can also “cap” lints so that the compiler can choose to ignore certain lint levels. We’ll talk about that last.
[](https://doc.rust-lang.org/rustc/print.html#via-compiler-flag)
Via compiler flag
The -A
, -W
, -D
, and -F
flags let you turn one or more lints into allowed, warning, deny, or forbid levels, like this:
`$ rustc lib.rs --crate-type=lib -W missing-docs
warning: missing documentation for crate
--> lib.rs:1:1
|
1 | pub fn foo() {}
| ^^^^^^^^^^^^
|
= note: requested on the command line with
-W missing-docs`
warning: missing documentation for a function –> lib.rs:1:1 | 1 | pub fn foo() {} | ^^^^^^^^^^^^``
`$ rustc lib.rs --crate-type=lib -D missing-docs
error: missing documentation for crate
--> lib.rs:1:1
|
1 | pub fn foo() {}
| ^^^^^^^^^^^^
|
= note: requested on the command line with
-D missing-docs`
error: missing documentation for a function –> lib.rs:1:1 | 1 | pub fn foo() {} | ^^^^^^^^^^^^
error: aborting due to 2 previous errors``
You can also pass each flag more than once for changing multiple lints:
$ rustc lib.rs --crate-type=lib -D missing-docs -D unused-variables
And of course, you can mix these four flags together:
$ rustc lib.rs --crate-type=lib -D missing-docs -A unused-variables
[](https://doc.rust-lang.org/rustc/print.html#via-an-attribute)
Via an attribute
You can also modify the lint level with a crate-wide attribute:
`$ cat lib.rs #![warn(missing_docs)]
pub fn foo() {} $ rustc lib.rs –crate-type=lib warning: missing documentation for crate –> lib.rs:1:1 | 1 | / #![warn(missing_docs)] 2 | | 3 | | pub fn foo() {} | |_______________^ | note: lint level defined here –> lib.rs:1:9 | 1 | #![warn(missing_docs)] | ^^^^^^^^^^^^
warning: missing documentation for a function –> lib.rs:3:1 | 3 | pub fn foo() {} | ^^^^^^^^^^^^`
All four, warn
, allow
, deny
, and forbid
all work this way.
You can also pass in multiple lints per attribute:
`#![warn(missing_docs, unused_variables)]
pub fn foo() {}`
And use multiple attributes together:
`#![warn(missing_docs)] #![deny(unused_variables)]
pub fn foo() {}`
[](https://doc.rust-lang.org/rustc/print.html#capping-lints)
Capping lints
rustc
supports a flag, --cap-lints LEVEL
that sets the “lint cap level.” This is the maximum level for all lints. So for example, if we take our code sample from the “deny” lint level above:
fn main() {
100u8 << 10;
}
And we compile it, capping lints to warn:
`$ rustc lib.rs –cap-lints warn warning: bitshift exceeds the type’s number of bits –> lib.rs:2:5 | 2 | 100u8 << 10; | ^^^^^^^^^^^ | = note: #[warn(exceeding_bitshifts)] on by default
warning: this expression will panic at run-time –> lib.rs:2:5 | 2 | 100u8 << 10; | ^^^^^^^^^^^ attempt to shift left with overflow`
It now only warns, rather than errors. We can go further and allow all lints:
$ rustc lib.rs --cap-lints allow
$
This feature is used heavily by Cargo; it will pass --cap-lints allow
when compiling your dependencies, so that if they have any warnings, they do not pollute the output of your build.
[](https://doc.rust-lang.org/rustc/print.html#lint-groups)
Lint Groups
rustc
has the concept of a “lint group”, where you can toggle several warnings through one name.
For example, the nonstandard-style
lint sets non-camel-case-types
, non-snake-case
, and non-upper-case-globals
all at once. So these are equivalent:
$ rustc -D nonstandard-style
$ rustc -D non-camel-case-types -D non-snake-case -D non-upper-case-globals
Here’s a list of each lint group, and the lints that they are made up of:
group
description
lints
nonstandard-style
Violation of standard naming conventions
non-camel-case-types, non-snake-case, non-upper-case-globals
warnings
all lints that would be issuing warnings
all lints that would be issuing warnings
edition-2018
Lints that will be turned into errors in Rust 2018
tyvar-behind-raw-pointer
rust-2018-idioms
Lints to nudge you toward idiomatic features of Rust 2018
bare-trait-object, unreachable-pub
unused
These lints detect things being declared but not used
unused-imports, unused-variables, unused-assignments, dead-code, unused-mut, unreachable-code, unreachable-patterns, unused-must-use, unused-unsafe, path-statements, unused-attributes, unused-macros, unused-allocation, unused-doc-comment, unused-extern-crates, unused-features, unused-parens
future-incompatible
Lints that detect code that has future-compatibility problems
private-in-public, pub-use-of-private-extern-crate, patterns-in-fns-without-body, safe-extern-statics, invalid-type-param-default, legacy-directory-ownership, legacy-imports, legacy-constructor-visibility, missing-fragment-specifier, illegal-floating-point-literal-pattern, anonymous-parameters, parenthesized-params-in-types-and-modules, late-bound-lifetime-arguments, safe-packed-borrows, incoherent-fundamental-impls, tyvar-behind-raw-pointer, unstable-name-collision
Additionally, there’s a bad-style
lint group that’s a deprecated alias for nonstandard-style
.
Finally, you can also see the table above by invoking rustc -W help
. This will give you the exact values for the specific compiler you have installed.
[](https://doc.rust-lang.org/rustc/print.html#lint-listing)
Lint listing
This section lists out all of the lints, grouped by their default lint levels.
You can also see this list by running rustc -W help
.
[](https://doc.rust-lang.org/rustc/print.html#allowed-by-default-lints)
Allowed-by-default lints
These lints are all set to the ‘allow’ level by default. As such, they won’t show up unless you set them to a higher lint level with a flag or attribute.
[](https://doc.rust-lang.org/rustc/print.html#anonymous-parameters)
anonymous-parameters
This lint detects anonymous parameters. Some example code that triggers this lint:
trait Foo {
fn foo(usize);
}
When set to ‘deny’, this will produce:
error: use of deprecated anonymous parameter
--> src/lib.rs:5:11
|
5 | fn foo(usize);
| ^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #41686 <https://github.com/rust-lang/rust/issues/41686>
This syntax is mostly a historical accident, and can be worked around quite easily:
trait Foo {
fn foo(_: usize);
}
[](https://doc.rust-lang.org/rustc/print.html#bare-trait-object)
bare-trait-object
This lint suggests using dyn Trait
for trait objects. Some example code that triggers this lint:
`#![feature(dyn_trait)]
trait Trait { }
fn takes_traitobject(: Box
When set to ‘deny’, this will produce:
error: trait objects without an explicit `dyn` are deprecated
--> src/lib.rs:7:30
|
7 | fn takes_trait_object(_: Box<Trait>) {
| ^^^^^ help: use `dyn`: `dyn Trait`
|
To fix it, do as the help message suggests:
`#![feature(dyn_trait)] #![deny(bare_trait_objects)]
trait Trait { }
fn takes_traitobject(: Box
[](https://doc.rust-lang.org/rustc/print.html#box-pointers)
box-pointers
This lints use of the Box type. Some example code that triggers this lint:
struct Foo {
x: Box<isize>,
}
When set to ‘deny’, this will produce:
error: type uses owned (Box type) pointers: std::boxed::Box<isize>
--> src/lib.rs:6:5
|
6 | x: Box<isize> //~ ERROR type uses owned
| ^^^^^^^^^^^^^
|
This lint is mostly historical, and not particularly useful. Box<T>
used to be built into the language, and the only way to do heap allocation. Today’s Rust can call into other allocators, etc.
[](https://doc.rust-lang.org/rustc/print.html#elided-lifetime-in-path)
elided-lifetime-in-path
This lint detects the use of hidden lifetime parameters. Some example code that triggers this lint:
`struct Foo<‘a> { x: &‘a u32 }
fn foo(x: &Foo) { }`
When set to ‘deny’, this will produce:
error: hidden lifetime parameters are deprecated, try `Foo<'_>`
--> src/lib.rs:5:12
|
5 | fn foo(x: &Foo) {
| ^^^
|
Lifetime elision elides this lifetime, but that is being deprecated.
[](https://doc.rust-lang.org/rustc/print.html#missing-copy-implementations)
missing-copy-implementations
This lint detects potentially-forgotten implementations of Copy
. Some example code that triggers this lint:
pub struct Foo {
pub field: i32
}
When set to ‘deny’, this will produce:
error: type could implement `Copy`; consider adding `impl Copy`
--> src/main.rs:3:1
|
3 | / pub struct Foo { //~ ERROR type could implement `Copy`; consider adding `impl Copy`
4 | | pub field: i32
5 | | }
| |_^
|
You can fix the lint by deriving Copy
.
This lint is set to ‘allow’ because this code isn’t bad; it’s common to write newtypes like this specifically so that a Copy
type is no longer Copy
.
[](https://doc.rust-lang.org/rustc/print.html#missing-debug-implementations)
missing-debug-implementations
This lint detects missing implementations of fmt::Debug
. Some example code that triggers this lint:
pub struct Foo;
When set to ‘deny’, this will produce:
error: type does not implement `fmt::Debug`; consider adding #[derive(Debug)] or a manual implementation
--> src/main.rs:3:1
|
3 | pub struct Foo;
| ^^^^^^^^^^^^^^^
|
You can fix the lint by deriving Debug
.
[](https://doc.rust-lang.org/rustc/print.html#missing-docs)
missing-docs
This lint detects missing documentation for public items. Some example code that triggers this lint:
pub fn foo() {}
When set to ‘deny’, this will produce:
`error: missing documentation for crate –> src/main.rs:1:1 | 1 | / #![deny(missing_docs)] 2 | | 3 | | pub fn foo() {} 4 | | 5 | | fn main() {} | |____________^ |
error: missing documentation for a function –> src/main.rs:3:1 | 3 | pub fn foo() {} | ^^^^^^^^^^^^`
To fix the lint, add documentation to all items.
[](https://doc.rust-lang.org/rustc/print.html#single-use-lifetime)
single-use-lifetime
This lint detects lifetimes that are only used once. Some example code that triggers this lint:
struct Foo<'x> {
x: &'x u32
}
When set to ‘deny’, this will produce:
error: lifetime name `'x` only used once
--> src/main.rs:3:12
|
3 | struct Foo<'x> {
| ^^
|
[](https://doc.rust-lang.org/rustc/print.html#trivial-casts)
trivial-casts
This lint detects trivial casts which could be removed. Some example code that triggers this lint:
let x: &u32 = &42;
let _ = x as *const u32;
When set to ‘deny’, this will produce:
error: trivial cast: `&u32` as `*const u32`. Cast can be replaced by coercion, this might require type ascription or a temporary variable
--> src/main.rs:5:13
|
5 | let _ = x as *const u32;
| ^^^^^^^^^^^^^^^
|
note: lint level defined here
--> src/main.rs:1:9
|
1 | #![deny(trivial_casts)]
| ^^^^^^^^^^^^^
[](https://doc.rust-lang.org/rustc/print.html#trivial-numeric-casts)
trivial-numeric-casts
This lint detects trivial casts of numeric types which could be removed. Some example code that triggers this lint:
let x = 42i32 as i32;
When set to ‘deny’, this will produce:
error: trivial numeric cast: `i32` as `i32`. Cast can be replaced by coercion, this might require type ascription or a temporary variable
--> src/main.rs:4:13
|
4 | let x = 42i32 as i32;
| ^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unreachable-pub)
unreachable-pub
This lint triggers for pub
items not reachable from the crate root. Some example code that triggers this lint:
`mod foo { pub mod bar {
}
}`
When set to ‘deny’, this will produce:
error: unreachable `pub` item
--> src/main.rs:4:5
|
4 | pub mod bar {
| ---^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
[](https://doc.rust-lang.org/rustc/print.html#unsafe-code)
unsafe-code
This lint catches usage of unsafe
code. Some example code that triggers this lint:
`fn main() { unsafe {
}
}`
When set to ‘deny’, this will produce:
error: usage of an `unsafe` block
--> src/main.rs:4:5
|
4 | / unsafe {
5 | |
6 | | }
| |_____^
|
[](https://doc.rust-lang.org/rustc/print.html#unstable-features)
unstable-features
This lint is deprecated and no longer used.
[](https://doc.rust-lang.org/rustc/print.html#unused-extern-crates)
unused-extern-crates
This lint guards against extern crate
items that are never used. Some example code that triggers this lint:
extern crate semver;
When set to ‘deny’, this will produce:
error: unused extern crate
--> src/main.rs:3:1
|
3 | extern crate semver;
| ^^^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-import-braces)
unused-import-braces
This lint catches unnecessary braces around an imported item. Some example code that triggers this lint:
`use test::{A};
pub mod test { pub struct A; }`
When set to ‘deny’, this will produce:
error: braces around A is unnecessary
--> src/main.rs:3:1
|
3 | use test::{A};
| ^^^^^^^^^^^^^^
|
To fix it, use test::A;
[](https://doc.rust-lang.org/rustc/print.html#unused-qualifications)
unused-qualifications
This lint detects unnecessarily qualified names. Some example code that triggers this lint:
`mod foo { pub fn bar() {} }
fn main() { use foo::bar; foo::bar(); }`
When set to ‘deny’, this will produce:
error: unnecessary qualification
--> src/main.rs:9:5
|
9 | foo::bar();
| ^^^^^^^^
|
You can call bar()
directly, without the foo::
.
[](https://doc.rust-lang.org/rustc/print.html#unused-results)
unused-results
This lint checks for the unused result of an expression in a statement. Some example code that triggers this lint:
`fn foo
fn main() {
foo::
When set to ‘deny’, this will produce:
error: unused result
--> src/main.rs:6:5
|
6 | foo::<usize>();
| ^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#variant-size-differences)
variant-size-differences
This lint detects enums with widely varying variant sizes. Some example code that triggers this lint:
enum En {
V0(u8),
VBig([u8; 1024]),
}
When set to ‘deny’, this will produce:
error: enum variant is more than three times larger (1024 bytes) than the next largest
--> src/main.rs:5:5
|
5 | VBig([u8; 1024]), //~ ERROR variant is more than three times larger
| ^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#warn-by-default-lints)
Warn-by-default lints
These lints are all set to the ‘warn’ level by default.
[](https://doc.rust-lang.org/rustc/print.html#const-err)
const-err
This lint detects an erroneous expression while doing constant evaluation. Some example code that triggers this lint:
let b = 200u8 + 200u8;
This will produce:
warning: attempt to add with overflow
--> src/main.rs:2:9
|
2 | let b = 200u8 + 200u8;
| ^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#dead-code)
dead-code
This lint detects unused, unexported items. Some example code that triggers this lint:
fn foo() {}
This will produce:
warning: function is never used: `foo`
--> src/lib.rs:2:1
|
2 | fn foo() {}
| ^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#deprecated)
deprecated
This lint detects use of deprecated items. Some example code that triggers this lint:
`#[deprecated] fn foo() {}
fn bar() { foo(); }`
This will produce:
warning: use of deprecated item 'foo'
--> src/lib.rs:7:5
|
7 | foo();
| ^^^
|
[](https://doc.rust-lang.org/rustc/print.html#illegal-floating-point-literal-pattern)
illegal-floating-point-literal-pattern
This lint detects floating-point literals used in patterns. Some example code that triggers this lint:
`let x = 42.0;
match x { 5.0 => {}, _ => {}, }`
This will produce:
warning: floating-point literals cannot be used in patterns
--> src/main.rs:4:9
|
4 | 5.0 => {},
| ^^^
|
= note: #[warn(illegal_floating_point_literal_pattern)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #41620 <https://github.com/rust-lang/rust/issues/41620>
[](https://doc.rust-lang.org/rustc/print.html#improper-ctypes)
improper-ctypes
This lint detects proper use of libc types in foreign modules. Some example code that triggers this lint:
extern "C" {
static STATIC: String;
}
This will produce:
warning: found struct without foreign-function-safe representation annotation in foreign module, consider adding a #[repr(C)] attribute to the type
--> src/main.rs:2:20
|
2 | static STATIC: String;
| ^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#late-bound-lifetime-arguments)
late-bound-lifetime-arguments
This lint detects generic lifetime arguments in path segments with late bound lifetime parameters. Some example code that triggers this lint:
`struct S;
impl S { fn late<‘a, ‘b>(self, _: &‘a u8, _: &‘b u8) {} }
fn main() { S.late::<‘static>(&0, &0); }`
This will produce:
warning: cannot specify lifetime arguments explicitly if late bound lifetime parameters are present
--> src/main.rs:8:14
|
4 | fn late<'a, 'b>(self, _: &'a u8, _: &'b u8) {}
| -- the late bound lifetime parameter is introduced here
...
8 | S.late::<'static>(&0, &0);
| ^^^^^^^
|
= note: #[warn(late_bound_lifetime_arguments)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #42868 <https://github.com/rust-lang/rust/issues/42868>
[](https://doc.rust-lang.org/rustc/print.html#non-camel-case-types)
non-camel-case-types
This lint detects types, variants, traits and type parameters that don’t have camel case names. Some example code that triggers this lint:
struct s;
This will produce:
warning: type `s` should have a camel case name such as `S`
--> src/main.rs:1:1
|
1 | struct s;
| ^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#non-shorthand-field-patterns)
non-shorthand-field-patterns
This lint detects using Struct { x: x }
instead of Struct { x }
in a pattern. Some example code that triggers this lint:
`struct Point { x: i32, y: i32, }
fn main() { let p = Point { x: 5, y: 5, };
match p {
Point { x: x, y: y } => (),
}
}`
This will produce:
`warning: the
x:` in this pattern is redundant
–> src/main.rs:14:17
|
14 | Point { x: x, y: y } => (),
| –^^
| |
| help: remove this
|
warning: the y:
in this pattern is redundant
–> src/main.rs:14:23
|
14 | Point { x: x, y: y } => (),
| –^^
| |
| help: remove this``
[](https://doc.rust-lang.org/rustc/print.html#non-snake-case)
non-snake-case
This lint detects variables, methods, functions, lifetime parameters and modules that don’t have snake case names. Some example code that triggers this lint:
let X = 5;
This will produce:
warning: variable `X` should have a snake case name such as `x`
--> src/main.rs:2:9
|
2 | let X = 5;
| ^
|
[](https://doc.rust-lang.org/rustc/print.html#non-upper-case-globals)
non-upper-case-globals
This lint detects static constants that don’t have uppercase identifiers. Some example code that triggers this lint:
static x: i32 = 5;
This will produce:
warning: static variable `x` should have an upper case name such as `X`
--> src/main.rs:1:1
|
1 | static x: i32 = 5;
| ^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#no-mangle-generic-items)
no-mangle-generic-items
This lint detects generic items must be mangled. Some example code that triggers this lint:
`#[no_mangle]
fn foo
}`
This will produce:
warning: functions generic over types must be mangled
--> src/main.rs:2:1
|
1 | #[no_mangle]
| ------------ help: remove this attribute
2 | / fn foo<T>(t: T) {
3 | |
4 | | }
| |_^
|
[](https://doc.rust-lang.org/rustc/print.html#path-statements)
path-statements
This lint detects path statements with no effect. Some example code that triggers this lint:
`let x = 42;
x;`
This will produce:
warning: path statement with no effect
--> src/main.rs:3:5
|
3 | x;
| ^^
|
[](https://doc.rust-lang.org/rustc/print.html#patterns-in-fns-without-body)
patterns-in-fns-without-body
This lint detects patterns in functions without body were that were previously erroneously allowed. Some example code that triggers this lint:
trait Trait {
fn foo(mut arg: u8);
}
This will produce:
warning: patterns aren't allowed in methods without bodies
--> src/main.rs:2:12
|
2 | fn foo(mut arg: u8);
| ^^^^^^^
|
= note: #[warn(patterns_in_fns_without_body)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #35203 <https://github.com/rust-lang/rust/issues/35203>
To fix this, remove the pattern; it can be used in the implementation without being used in the definition. That is:
`trait Trait { fn foo(arg: u8); }
impl Trait for i32 { fn foo(mut arg: u8) {
}
}`
[](https://doc.rust-lang.org/rustc/print.html#plugin-as-library)
plugin-as-library
This lint detects when compiler plugins are used as ordinary library in non-plugin crate. Some example code that triggers this lint:
`#![feature(plugin)] #![plugin(macro_crate_test)]
extern crate macro_crate_test;`
[](https://doc.rust-lang.org/rustc/print.html#private-in-public)
private-in-public
This lint detects private items in public interfaces not caught by the old implementation. Some example code that triggers this lint:
`pub trait Trait { type A; }
pub struct S;
mod foo { struct Z;
impl ::Trait for ::S {
type A = Z;
}
}`
This will produce:
error[E0446]: private type `foo::Z` in public interface
--> src/main.rs:11:9
|
11 | type A = Z;
| ^^^^^^^^^^^ can't leak private type
[](https://doc.rust-lang.org/rustc/print.html#private-no-mangle-fns)
private-no-mangle-fns
This lint detects functions marked #[no_mangle]
that are also private. Given that private functions aren’t exposed publicly, and #[no_mangle]
controls the public symbol, this combination is erroneous. Some example code that triggers this lint:
#[no_mangle]
fn foo() {}
This will produce:
warning: function is marked #[no_mangle], but not exported
--> src/main.rs:2:1
|
2 | fn foo() {}
| -^^^^^^^^^^
| |
| help: try making it public: `pub`
|
To fix this, either make it public or remove the #[no_mangle]
.
[](https://doc.rust-lang.org/rustc/print.html#private-no-mangle-statics)
private-no-mangle-statics
This lint detects any statics marked #[no_mangle]
that are private. Given that private statics aren’t exposed publicly, and #[no_mangle]
controls the public symbol, this combination is erroneous. Some example code that triggers this lint:
#[no_mangle]
static X: i32 = 4;
This will produce:
warning: static is marked #[no_mangle], but not exported
--> src/main.rs:2:1
|
2 | static X: i32 = 4;
| -^^^^^^^^^^^^^^^^^
| |
| help: try making it public: `pub`
|
To fix this, either make it public or remove the #[no_mangle]
.
[](https://doc.rust-lang.org/rustc/print.html#renamed-and-removed-lints)
renamed-and-removed-lints
This lint detects lints that have been renamed or removed. Some example code that triggers this lint:
#![deny(raw_pointer_derive)]
This will produce:
warning: lint raw_pointer_derive has been removed: using derive with raw pointers is ok
--> src/main.rs:1:9
|
1 | #![deny(raw_pointer_derive)]
| ^^^^^^^^^^^^^^^^^^
|
To fix this, either remove the lint or use the new name.
[](https://doc.rust-lang.org/rustc/print.html#safe-packed-borrows)
safe-packed-borrows
This lint detects borrowing a field in the interior of a packed structure with alignment other than 1. Some example code that triggers this lint:
`#[repr(packed)]
pub struct Unaligned
pub struct Foo {
start: u8,
data: Unaligned
fn main() { let x = Foo { start: 0, data: Unaligned(1) }; let y = &x.data.0; }`
This will produce:
warning: borrow of packed field requires unsafe function or block (error E0133)
--> src/main.rs:11:13
|
11 | let y = &x.data.0;
| ^^^^^^^^^
|
= note: #[warn(safe_packed_borrows)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>
[](https://doc.rust-lang.org/rustc/print.html#stable-features)
stable-features
This lint detects a #[feature]
attribute that’s since been made stable. Some example code that triggers this lint:
#![feature(test_accepted_feature)]
This will produce:
warning: this feature has been stable since 1.0.0. Attribute no longer needed
--> src/main.rs:1:12
|
1 | #![feature(test_accepted_feature)]
| ^^^^^^^^^^^^^^^^^^^^^
|
To fix, simply remove the #![feature]
attribute, as it’s no longer needed.
[](https://doc.rust-lang.org/rustc/print.html#type-alias-bounds)
type-alias-bounds
This lint detects bounds in type aliases. These are not currently enforced. Some example code that triggers this lint:
type SendVec<T: Send> = Vec<T>;
This will produce:
warning: type alias is never used: `SendVec`
--> src/main.rs:1:1
|
1 | type SendVec<T: Send> = Vec<T>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#tyvar-behind-raw-pointer)
tyvar-behind-raw-pointer
This lint detects raw pointer to an inference variable. Some example code that triggers this lint:
`let data = std::ptr::null(); let _ = &data as *const *const ();
if data.is_null() {}`
This will produce:
warning: type annotations needed
--> src/main.rs:4:13
|
4 | if data.is_null() {}
| ^^^^^^^
|
= note: #[warn(tyvar_behind_raw_pointer)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
= note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906>
[](https://doc.rust-lang.org/rustc/print.html#unconditional-recursion)
unconditional-recursion
This lint detects functions that cannot return without calling themselves. Some example code that triggers this lint:
fn foo() {
foo();
}
This will produce:
warning: function cannot return without recursing
--> src/main.rs:1:1
|
1 | fn foo() {
| ^^^^^^^^ cannot return without recursing
2 | foo();
| ----- recursive call site
|
[](https://doc.rust-lang.org/rustc/print.html#unions-with-drop-fields)
unions-with-drop-fields
This lint detects use of unions that contain fields with possibly non-trivial drop code. Some example code that triggers this lint:
`#![feature(untagged_unions)]
union U { s: String, }`
This will produce:
warning: union contains a field with possibly non-trivial drop code, drop code of union fields is ignored when dropping the union
--> src/main.rs:4:5
|
4 | s: String,
| ^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unknown-lints)
unknown-lints
This lint detects unrecognized lint attribute. Some example code that triggers this lint:
#[allow(not_a_real_lint)]
This will produce:
warning: unknown lint: `not_a_real_lint`
--> src/main.rs:1:10
|
1 | #![allow(not_a_real_lint)]
| ^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unreachable-code)
unreachable-code
This lint detects unreachable code paths. Some example code that triggers this lint:
`panic!(“we never go past here!”);
let x = 5;`
This will produce:
warning: unreachable statement
--> src/main.rs:4:5
|
4 | let x = 5;
| ^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unreachable-patterns)
unreachable-patterns
This lint detects unreachable patterns. Some example code that triggers this lint:
let x = 5;
match x {
y => (),
5 => (),
}
This will produce:
warning: unreachable pattern
--> src/main.rs:5:5
|
5 | 5 => (),
| ^
|
The y
pattern will always match, so the five is impossible to reach. Remember, match arms match in order, you probably wanted to put the 5
case above the y
case.
[](https://doc.rust-lang.org/rustc/print.html#unstable-name-collision)
unstable-name-collision
This lint detects that you’ve used a name that the standard library plans to add in the future, which means that your code may fail to compile without additional type annotations in the future. Either rename, or add those annotations now.
[](https://doc.rust-lang.org/rustc/print.html#unused-allocation)
unused-allocation
This lint detects unnecessary allocations that can be eliminated.
[](https://doc.rust-lang.org/rustc/print.html#unused-assignments)
unused-assignments
This lint detects assignments that will never be read. Some example code that triggers this lint:
let mut x = 5;
x = 6;
This will produce:
warning: value assigned to `x` is never read
--> src/main.rs:4:5
|
4 | x = 6;
| ^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-attributes)
unused-attributes
This lint detects attributes that were not used by the compiler. Some example code that triggers this lint:
`#![feature(custom_attribute)]
#![mutable_doc]`
This will produce:
warning: unused attribute
--> src/main.rs:4:1
|
4 | #![mutable_doc]
| ^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-comparisons)
unused-comparisons
This lint detects comparisons made useless by limits of the types involved. Some example code that triggers this lint:
fn foo(x: u8) {
x >= 0;
}
This will produce:
warning: comparison is useless due to type limits
--> src/main.rs:6:5
|
6 | x >= 0;
| ^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-doc-comment)
unused-doc-comment
This lint detects doc comments that aren’t used by rustdoc. Some example code that triggers this lint:
/// docs for x
let x = 12;
This will produce:
warning: doc comment not used by rustdoc
--> src/main.rs:2:5
|
2 | /// docs for x
| ^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-features)
unused-features
This lint detects unused or unknown features found in crate-level #[feature] directives. To fix this, simply remove the feature flag.
[](https://doc.rust-lang.org/rustc/print.html#unused-imports)
unused-imports
This lint detects imports that are never used. Some example code that triggers this lint:
use std::collections::HashMap;
This will produce:
warning: unused import: `std::collections::HashMap`
--> src/main.rs:1:5
|
1 | use std::collections::HashMap;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-macros)
unused-macros
This lint detects macros that were not used. Some example code that triggers this lint:
`macro_rules! unused { () => {}; }
fn main() { }`
This will produce:
warning: unused macro definition
--> src/main.rs:1:1
|
1 | / macro_rules! unused {
2 | | () => {};
3 | | }
| |_^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-must-use)
unused-must-use
This lint detects unused result of a type flagged as #[must_use]. Some example code that triggers this lint:
`fn returns_result() -> Result<(), ()> { Ok(()) }
fn main() { returns_result(); }`
This will produce:
warning: unused `std::result::Result` that must be used
--> src/main.rs:6:5
|
6 | returns_result();
| ^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#unused-mut)
unused-mut
This lint detects mut variables which don’t need to be mutable. Some example code that triggers this lint:
let mut x = 5;
This will produce:
warning: variable does not need to be mutable
--> src/main.rs:2:9
|
2 | let mut x = 5;
| ----^
| |
| help: remove this `mut`
|
[](https://doc.rust-lang.org/rustc/print.html#unused-parens)
unused-parens
This lint detects if
, match
, while
and return
with parentheses; they do not need them. Some example code that triggers this lint:
if(true) {}
This will produce:
warning: unnecessary parentheses around `if` condition
--> src/main.rs:2:7
|
2 | if(true) {}
| ^^^^^^ help: remove these parentheses
|
[](https://doc.rust-lang.org/rustc/print.html#unused-unsafe)
unused-unsafe
This lint detects unnecessary use of an unsafe
block. Some example code that triggers this lint:
unsafe {}
This will produce:
warning: unnecessary `unsafe` block
--> src/main.rs:2:5
|
2 | unsafe {}
| ^^^^^^ unnecessary `unsafe` block
|
[](https://doc.rust-lang.org/rustc/print.html#unused-variables)
unused-variables
This lint detects variables which are not used in any way. Some example code that triggers this lint:
let x = 5;
This will produce:
warning: unused variable: `x`
--> src/main.rs:2:9
|
2 | let x = 5;
| ^ help: consider using `_x` instead
|
[](https://doc.rust-lang.org/rustc/print.html#warnings)
warnings
This lint is a bit special; by changing its level, you change every other warning that would produce a warning to whatever value you’d like:
#![deny(warnings)]
As such, you won’t ever trigger this lint in your code directly.
[](https://doc.rust-lang.org/rustc/print.html#while-true)
while-true
This lint detects while true { }
. Some example code that triggers this lint:
`while true {
}`
This will produce:
warning: denote infinite loops with `loop { ... }`
--> src/main.rs:2:5
|
2 | while true {
| ^^^^^^^^^^ help: use `loop`
|
[](https://doc.rust-lang.org/rustc/print.html#deny-by-default-lints)
Deny-by-default lints
These lints are all set to the ‘deny’ level by default.
[](https://doc.rust-lang.org/rustc/print.html#exceeding-bitshifts)
exceeding-bitshifts
This lint detects that a shift exceeds the type’s number of bits. Some example code that triggers this lint:
1_i32 << 32;
This will produce:
error: bitshift exceeds the type's number of bits
--> src/main.rs:2:5
|
2 | 1_i32 << 32;
| ^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#invalid-type-param-default)
invalid-type-param-default
This lint detects type parameter default erroneously allowed in invalid location. Some example code that triggers this lint:
fn foo<T=i32>(t: T) {}
This will produce:
error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions.
--> src/main.rs:4:8
|
4 | fn foo<T=i32>(t: T) {}
| ^
|
= note: #[deny(invalid_type_param_default)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #36887 <https://github.com/rust-lang/rust/issues/36887>
[](https://doc.rust-lang.org/rustc/print.html#legacy-constructor-visibility)
legacy-constructor-visibility
RFC 1506 modified some visibility rules, and changed the visibility of struct constructors. Some example code that triggers this lint:
``mod m { pub struct S(u8);
fn f() {
// this is trying to use S from the 'use' line, but because the `u8` is
// not pub, it is private
::S;
}
}
use m::S;``
This will produce:
error: private struct constructors are not usable through re-exports in outer modules
--> src/main.rs:5:9
|
5 | ::S;
| ^^^
|
= note: #[deny(legacy_constructor_visibility)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #39207 <https://github.com/rust-lang/rust/issues/39207>
[](https://doc.rust-lang.org/rustc/print.html#legacy-directory-ownership)
legacy-directory-ownership
The legacy_directory_ownership warning is issued when
- There is a non-inline module with a #[path] attribute (e.g. #[path = “foo.rs”] mod bar;),
- The module’s file (“foo.rs” in the above example) is not named “mod.rs”, and
- The module’s file contains a non-inline child module without a #[path] attribute.
The warning can be fixed by renaming the parent module to “mod.rs” and moving it into its own directory if appropriate.
[](https://doc.rust-lang.org/rustc/print.html#missing-fragment-specifier)
missing-fragment-specifier
The missing_fragment_specifier warning is issued when an unused pattern in a macro_rules!
macro definition has a meta-variable (e.g. $e
) that is not followed by a fragment specifier (e.g. :expr
).
This warning can always be fixed by removing the unused pattern in the macro_rules!
macro definition.
[](https://doc.rust-lang.org/rustc/print.html#mutable-transmutes)
mutable-transmutes
This lint catches transmuting from &T
to &mut T
because it is undefined behavior. Some example code that triggers this lint:
unsafe {
let y = std::mem::transmute::<&i32, &mut i32>(&5);
}
This will produce:
error: mutating transmuted &mut T from &T may cause undefined behavior, consider instead using an UnsafeCell
--> src/main.rs:3:17
|
3 | let y = std::mem::transmute::<&i32, &mut i32>(&5);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#no-mangle-const-items)
no-mangle-const-items
This lint detects any const
items with the #[no_mangle]
attribute. Constants do not have their symbols exported, and therefore, this probably means you meant to use a static
, not a const
. Some example code that triggers this lint:
#[no_mangle]
const FOO: i32 = 5;
This will produce:
error: const items should never be #[no_mangle]
--> src/main.rs:3:1
|
3 | const FOO: i32 = 5;
| -----^^^^^^^^^^^^^^
| |
| help: try a static value: `pub static`
|
[](https://doc.rust-lang.org/rustc/print.html#overflowing-literals)
overflowing-literals
This lint detects literal out of range for its type. Some example code that triggers this lint:
let x: u8 = 1000;
This will produce:
error: literal out of range for u8
--> src/main.rs:2:17
|
2 | let x: u8 = 1000;
| ^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#parenthesized-params-in-types-and-modules)
parenthesized-params-in-types-and-modules
This lint detects incorrect parentheses. Some example code that triggers this lint:
let x = 5 as usize();
This will produce:
error: parenthesized parameters may only be used with a trait
--> src/main.rs:2:21
|
2 | let x = 5 as usize();
| ^^
|
= note: #[deny(parenthesized_params_in_types_and_modules)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #42238 <https://github.com/rust-lang/rust/issues/42238>
To fix it, remove the ()
s.
[](https://doc.rust-lang.org/rustc/print.html#pub-use-of-private-extern-crate)
pub-use-of-private-extern-crate
This lint detects a specific situation of re-exporting a private extern crate
;
[](https://doc.rust-lang.org/rustc/print.html#safe-extern-statics)
safe-extern-statics
In older versions of Rust, there was a soundness issue where extern static
s were allowed to be accessed in safe code. This lint now catches and denies this kind of code.
[](https://doc.rust-lang.org/rustc/print.html#unknown-crate-types)
unknown-crate-types
This lint detects an unknown crate type found in a #[crate_type]
directive. Some example code that triggers this lint:
#![crate_type="lol"]
This will produce:
error: invalid `crate_type` value
--> src/lib.rs:1:1
|
1 | #![crate_type="lol"]
| ^^^^^^^^^^^^^^^^^^^^
|
[](https://doc.rust-lang.org/rustc/print.html#incoherent-fundamental-impls)
incoherent-fundamental-impls
This lint detects potentially-conflicting impls that were erroneously allowed. Some example code that triggers this lint:
`pub trait Trait1
pub trait Trait2
pub struct A;
impl
impl
This will produce:
error: conflicting implementations of trait `Trait1<std::boxed::Box<_>>` for type `A`: (E0119)
--> src/main.rs:13:1
|
9 | impl<X, T> Trait1<X> for T where T: Trait2<X> {
| --------------------------------------------- first implementation here
...
13 | impl<X> Trait1<Box<X>> for A {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `A`
|
= note: #[deny(incoherent_fundamental_impls)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #46205 <https://github.com/rust-lang/rust/issues/46205>
= note: downstream crates may implement trait `Trait2<std::boxed::Box<_>>` for type `A`
[](https://doc.rust-lang.org/rustc/print.html#codegen-options)
Codegen options
All of these options are passed to rustc
via the -C
flag, short for “codegen.” You can see a version of this list for your exact compiler by running rustc -C help
.
[](https://doc.rust-lang.org/rustc/print.html#ar)
ar
This option is deprecated and does nothing.
[](https://doc.rust-lang.org/rustc/print.html#linker)
linker
This flag lets you control which linker rustc
invokes to link your code.
[](https://doc.rust-lang.org/rustc/print.html#link-argval)
link-arg=val
This flag lets you append a single extra argument to the linker invocation.
“Append” is significant; you can pass this flag multiple times to add multiple arguments.
[](https://doc.rust-lang.org/rustc/print.html#link-args)
link-args
This flag lets you append multiple extra arguments to the linker invocation. The options should be separated by spaces.
[](https://doc.rust-lang.org/rustc/print.html#linker-flavor)
linker-flavor
This flag lets you control the linker flavor used by rustc
. If a linker is given with the -C linker
flag described above then the linker flavor is inferred from the value provided. If no linker is given then the linker flavor is used to determine the linker to use. Every rustc
target defaults to some linker flavor.
[](https://doc.rust-lang.org/rustc/print.html#link-dead-code)
link-dead-code
Normally, the linker will remove dead code. This flag disables this behavior.
An example of when this flag might be useful is when trying to construct code coverage metrics.
[](https://doc.rust-lang.org/rustc/print.html#lto)
lto
This flag instructs LLVM to use link time optimizations.
It takes one of two values, thin
and fat
. ‘thin’ LTO is a new feature of LLVM, ‘fat’ referring to the classic version of LTO.
[](https://doc.rust-lang.org/rustc/print.html#target-cpu)
target-cpu
This instructs rustc
to generate code specifically for a particular processor.
You can run rustc --print target-cpus
to see the valid options to pass here. Additionally, native
can be passed to use the processor of the host machine.
[](https://doc.rust-lang.org/rustc/print.html#target-feature)
target-feature
Individual targets will support different features; this flag lets you control enabling or disabling a feature.
To see the valid options and an example of use, run rustc --print target-features
.
[](https://doc.rust-lang.org/rustc/print.html#passes)
passes
This flag can be used to add extra LLVM passes to the compilation.
The list must be separated by spaces.
[](https://doc.rust-lang.org/rustc/print.html#llvm-args)
llvm-args
This flag can be used to pass a list of arguments directly to LLVM.
The list must be separated by spaces.
[](https://doc.rust-lang.org/rustc/print.html#save-temps)
save-temps
rustc
will generate temporary files during compilation; normally it will delete them after it’s done with its work. This option will cause them to be preserved instead of removed.
[](https://doc.rust-lang.org/rustc/print.html#rpath)
rpath
This option allows you to set the value of rpath
.
[](https://doc.rust-lang.org/rustc/print.html#overflow-checks)
overflow-checks
This flag allows you to control the behavior of integer overflow. This flag can be passed many options:
- To turn overflow checks on:
y
,yes
, oron
. - To turn overflow checks off:
n
,no
, oroff
.
[](https://doc.rust-lang.org/rustc/print.html#no-prepopulate-passes)
no-prepopulate-passes
The pass manager comes pre-populated with a list of passes; this flag ensures that list is empty.
[](https://doc.rust-lang.org/rustc/print.html#no-vectorize-loops)
no-vectorize-loops
By default, rustc
will attempt to vectorize loops. This flag will turn that behavior off.
[](https://doc.rust-lang.org/rustc/print.html#no-vectorize-slp)
no-vectorize-slp
By default, rustc
will attempt to vectorize loops using superword-level parallelism. This flag will turn that behavior off.
[](https://doc.rust-lang.org/rustc/print.html#soft-float)
soft-float
This option will make rustc
generate code using “soft floats.” By default, a lot of hardware supports floating point instructions, and so the code generated will take advantage of this. “soft floats” emulate floating point instructions in software.
[](https://doc.rust-lang.org/rustc/print.html#prefer-dynamic)
prefer-dynamic
By default, rustc
prefers to statically link dependencies. This option will make it use dynamic linking instead.
[](https://doc.rust-lang.org/rustc/print.html#no-integrated-as)
no-integrated-as
LLVM comes with an internal assembler; this option will let you use an external assembler instead.
[](https://doc.rust-lang.org/rustc/print.html#no-redzone)
no-redzone
This flag allows you to disable the red zone. This flag can be passed many options:
- To enable the red zone:
y
,yes
, oron
. - To disable it:
n
,no
, oroff
.
[](https://doc.rust-lang.org/rustc/print.html#relocation-model)
relocation-model
This option lets you choose which relocation model to use.
To find the valid options for this flag, run rustc --print relocation-models
.
[](https://doc.rust-lang.org/rustc/print.html#code-modelval)
code-model=val
This option lets you choose which code model to use.
To find the valid options for this flag, run rustc --print code-models
.
[](https://doc.rust-lang.org/rustc/print.html#metadata)
metadata
This option allows you to control the metadata used for symbol mangling.
[](https://doc.rust-lang.org/rustc/print.html#extra-filename)
extra-filename
This option allows you to put extra data in each output filename.
[](https://doc.rust-lang.org/rustc/print.html#codegen-units)
codegen-units
This flag lets you control how many threads are used when doing code generation.
Increasing parallelism may speed up compile times, but may also produce slower code.
[](https://doc.rust-lang.org/rustc/print.html#remark)
remark
This flag lets you print remarks for these optimization passes.
The list of passes should be separated by spaces.
all
will remark on every pass.
[](https://doc.rust-lang.org/rustc/print.html#no-stack-check)
no-stack-check
This option is deprecated and does nothing.
[](https://doc.rust-lang.org/rustc/print.html#debuginfo)
debuginfo
This flag lets you control debug information:
0
: no debug info at all1
: line tables only2
: full debug info
[](https://doc.rust-lang.org/rustc/print.html#opt-level)
opt-level
This flag lets you control the optimization level.
0
: no optimizations, also turn oncfg(debug_assertions)
.1
: basic optimizations2
: some optimizations3
: all optimizationss
: optimize for binary sizez
: optimize for binary size, but also turn off loop vectorization.
[](https://doc.rust-lang.org/rustc/print.html#debug-assertions)
debug-assertions
This flag lets you turn cfg(debug_assertions)
on or off.
[](https://doc.rust-lang.org/rustc/print.html#inline-threshold)
inline-threshold
This option lets you set the threshold for inlining a function.
The default is 225.
[](https://doc.rust-lang.org/rustc/print.html#panic)
panic
This option lets you control what happens when the code panics.
abort
: terminate the process upon panicunwind
: unwind the stack upon panic
[](https://doc.rust-lang.org/rustc/print.html#incremental)
incremental
This flag allows you to enable incremental compilation.
[](https://doc.rust-lang.org/rustc/print.html#targets)
Targets
rustc
is a cross-compiler by default. This means that you can use any compiler to build for any architecture. The list of targets are the possible architectures that you can build for.
To see all the options that you can set with a target, see the docs here.
To compile to a particular target, use the --target
flag:
$ rustc src/main.rs --target=wasm32-unknown-unknown
[](https://doc.rust-lang.org/rustc/print.html#built-in-targets)
Built-in Targets
rustc
ships with the ability to compile to many targets automatically, we call these “built-in” targets, and they generally correspond to targets that the team is supporting directly.
To see the list of built-in targets, you can run rustc --print target-list
, or look at the API docs. Each module there defines a builder for a particular target.
[](https://doc.rust-lang.org/rustc/print.html#custom-targets)
Custom Targets
If you’d like to build for a target that is not yet supported by rustc
, you can use a “custom target specification” to define a target. These target specification files are JSON. To see the JSON for the host target, you can run:
$ rustc +nightly -Z unstable-options --print target-spec-json
To see it for a different target, add the --target
flag:
$ rustc +nightly -Z unstable-options --target=wasm32-unknown-unknown --print target-spec-json
To use a custom target, see xargo
.
[](https://doc.rust-lang.org/rustc/print.html#linker-plugin-lto)
Linker-plugin-LTO
The -C linker-plugin-lto
flag allows for deferring the LTO optimization to the actual linking step, which in turn allows for performing interprocedural optimizations across programming language boundaries if all the object files being linked were created by LLVM based toolchains. The prime example here would be linking Rust code together with Clang-compiled C/C++ code.
[](https://doc.rust-lang.org/rustc/print.html#usage)
Usage
There are two main cases how linker plugin based LTO can be used:
- compiling a Rust
staticlib
that is used as a C ABI dependency - compiling a Rust binary where
rustc
invokes the linker
In both cases the Rust code has to be compiled with -C linker-plugin-lto
and the C/C++ code with -flto
or -flto=thin
so that object files are emitted as LLVM bitcode.
[](https://doc.rust-lang.org/rustc/print.html#rust-staticlib-as-dependency-in-cc-program)
Rust staticlib
as dependency in C/C++ program
In this case the Rust compiler just has to make sure that the object files in the staticlib
are in the right format. For linking, a linker with the LLVM plugin must be used (e.g. LLD).
Using rustc
directly:
``# Compile the Rust staticlib rustc –crate-type=staticlib -Clinker-plugin-lto -Copt-level=2 ./lib.rs
Compile the C code with -flto=thin
clang -c -O2 -flto=thin -o main.o ./main.c
Link everything, making sure that we use an appropriate linker
clang -flto=thin -fuse-ld=lld -L . -l”name-of-your-rust-lib” -o main -O2 ./cmain.o``
Using cargo
:
``# Compile the Rust staticlib RUSTFLAGS=“-Clinker-plugin-lto” cargo build –release
Compile the C code with -flto=thin
clang -c -O2 -flto=thin -o main.o ./main.c
Link everything, making sure that we use an appropriate linker
clang -flto=thin -fuse-ld=lld -L . -l”name-of-your-rust-lib” -o main -O2 ./cmain.o``
[](https://doc.rust-lang.org/rustc/print.html#cc-code-as-a-dependency-in-rust)
C/C++ code as a dependency in Rust
In this case the linker will be invoked by rustc
. We again have to make sure that an appropriate linker is used.
Using rustc
directly:
`# Compile C code with
-flto`
clang ./clib.c -flto=thin -c -o ./clib.o -O2
Create a static library from the C code
ar crus ./libxyz.a ./clib.o
Invoke rustc
with the additional arguments
rustc -Clinker-plugin-lto -L. -Copt-level=2 -Clinker=clang -Clink-arg=-fuse-ld=lld ./main.rs``
Using cargo
directly:
`# Compile C code with
-flto`
clang ./clib.c -flto=thin -c -o ./clib.o -O2
Create a static library from the C code
ar crus ./libxyz.a ./clib.o
Set the linking arguments via RUSTFLAGS
RUSTFLAGS=“-Clinker-plugin-lto -Clinker=clang -Clink-arg=-fuse-ld=lld” cargo build –release``
Explicitly specifying the linker plugin to be used by rustc
If one wants to use a linker other than LLD, the LLVM linker plugin has to be specified explicitly. Otherwise the linker cannot read the object files. The path to the plugin is passed as an argument to the -Clinker-plugin-lto
option:
rustc -Clinker-plugin-lto="/path/to/LLVMgold.so" -L. -Copt-level=2 ./main.rs
[](https://doc.rust-lang.org/rustc/print.html#toolchain-compatibility)
Toolchain Compatibility
In order for this kind of LTO to work, the LLVM linker plugin must be able to handle the LLVM bitcode produced by both rustc
and clang
.
Best results are achieved by using a rustc
and clang
that are based on the exact same version of LLVM. One can use rustc -vV
in order to view the LLVM used by a given rustc
version. Note that the version number given here is only an approximation as Rust sometimes uses unstable revisions of LLVM. However, the approximation is usually reliable.
The following table shows known good combinations of toolchain versions.
Clang 7
Clang 8
Rust 1.34
✗
✓
Rust 1.35
✗
✓(?)
Note that the compatibility policy for this feature might change in the future.
[](https://doc.rust-lang.org/rustc/print.html#contributing-to-rustc)
Contributing to rustc
We’d love to have your help improving rustc
! To that end, we’ve written a whole book on its internals, how it works, and how to get started working on it. To learn more, you’ll want to check that out.
If you would like to contribute to this book, you can find its source in the rustc source at src/doc/rustc.


Important Note
To see this working, you must open JUST the file without Bootsnip's "View full screen" feature .
http://bootsnipp.com/iframe/V24R
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam leo neque, hendrerit et magna ut, viverra consectetur augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit.


STUDY INFORMATION AND CONSENT TO RESEARCH
Title:
Mole Mapper Study
Protocol No.:
201510920
WIRB® Protocol #20151976
Sponsor:
Sage Bionetworks
INVESTIGATOR:
Stephen H. Friend, MD, PhD
1100 Fairview Ave. North
Seattle, Washington
98109-4433
United States
STUDY-RELATED
PHONE NUMBER(S):
Andrew Trister
1-206-667-2115
or toll-free at: 1-844-693-2137
SUMMARY
You are invited to participate in a research study to understand skin health and melanoma risks. The purpose of this form is to help you decide if you want to participate in this study. Please read the information carefully.
You should not join the research study until all of your questions are answered.
Participating in a research study is not the same as receiving medical care. The decision to join or not join the research study will not affect your medical benefits.
PURPOSE OF THE STUDY
Moles change in size, color, and number during our lifetimes. Rarely, some moles become cancerous (melanoma). This study will collect individual’s information on melanoma risks together with mole measurements and photos using a phone application and the phone camera. The goals of this study are to build a large resource of mole images and measurements, to better understand the dynamic variability in moles and to educate people on melanoma risk. The insights may help develop personalized interventions to detect melanoma early and reduce the incidence of the disease.
PROCEDURES
What will you be asked to do?
If you decide to join the study you will need to download the free study application on your phone and register to the study. Then, we will ask you to answer few questions about yourself and take photographs of your moles using the study application your mobile phone camera.
We will send monthly reminders through the app asking you to re-photograph your moles and answer a few questions. You may choose to act at your convenience, participate in all or only in some parts of the study. This study should take you about 20 minutes per month.
How long will I be in the research study?
This study will last about twelve months. However the application (“app”) will remain on your phone until you delete it. You can keep using the app to track your moles for as long as you like.
How many people will take part in this study?
We will not restrict the number of participants in the study.
RISKS, DISCOMFORTS, AND INCONVENIENCES
There are risks, discomforts, and inconveniences associated with any research study. These deserve careful thought:
Participation in this study may involve risks that are not known at this time. You will be told about any new information that might change your decision to be in this study.
POTENTIAL BENEFITS
The goal of this study is to create knowledge, which can benefit us as a society. We will publish the insights learned from analysis of the study data but these insights may not be of direct benefit to you. However, you will be able to track your moles and export your data at will to share with your medical doctor and anyone you choose.
VOLUNTARY PARTICIPATION AND WITHDRAWAL
Although you can withdraw from the study at any time, you cannot withdraw the coded study data that have already been distributed. If you withdraw from the study, we will stop collecting new data but the coded data that you have already provided will not be able to be destroyed or deleted.
The Study Principal Investigator or the sponsor may also withdraw you from the study without your consent at any time for any reason, including if it is in your best interest, you do not consent to continue in the study after being told of changes in the research that may affect you, or if the study is cancelled.
PAYMENT
You will not be paid and will receive no financial benefit for being in this study.
COSTS
There is no cost to you to participate in this study other than to your mobile data plan if applicable.
COMPENSATION FOR INJURY
This study does not provide any compensation, health or medical care to participants.
If you are injured as a direct result of your participation in this study, the Principal Investigator or the medical monitor and the research study staff will assist you in obtaining appropriate medical treatment. Your medical insurance, managed care plan, or other benefits program will be billed for this treatment. You will be responsible for any associated co-payments or deductibles as required by your insurance.
If costs of care related to such an injury are not covered by your medical insurance, managed care plan or other benefits program, you may be responsible for these costs. The sponsor will not routinely pay charges that your insurance does not cover. No payment is routinely available from the study sponsor.
ALTERNATIVES
Since no medical treatments are provided during this study there are no alternative therapies. The only alternative is to not participate.
AUTHORIZATION TO USE AND DISCLOSE INFORMATION FOR RESEARCH PURPOSES
What personal information will be collected, used, or disclosed?
Your personal information that may be collected, used, or disclosed in connection with this research study may include, but is not limited to your account information, answers to study questions and the photographs you take of your moles.
Who may use and disclose your Personal Information?
The study sponsor, investigators, study coordinators and study staff may use and disclose your personal information to do the research described above or as required by law to:
In addition your name and contact information will be sent to the IRB-approved War on Melanoma Community Registry database managed by researchers at Oregon Health Science University [http://www.ohsu.edu/xd/health/services/dermatology/melanoma-community-registry/]. Information in the registry will be stored on a secure Redcap server at OHSU. Taking part in this registry enables the OHSU War on Melanoma researchers to inform you about other specific melanoma-related educational and research opportunities you may be eligible to participate in. You can choose to participate or not and can opt out of the Melanoma Community Registry at any time.
When will my authorization expire?
Your authorization for the use and/or disclosure of your information will expire if you choose to withdraw from the research study subject to any time limitations imposed by applicable law or by December 31, 2060.
If you choose to withdraw from the research study, we will stop collecting your study data. At the end of the study period we will stop collecting your data, even if the app remains on your phone and you keep using it.
If you opt-out of the Melanoma Community Registry you will stop receiving information about future educational events in your community or research opportunities, but information previously provided will not be deleted.
PRIVACY, CONFIDENTIALITY and DATA PROTECTION
We are committed to protect your information and keep your identity as confidential as possible, however total confidentiality cannot be guaranteed.
Data de-identification
The Mole Mapper study data collected through the app will be encrypted on your phone, transferred electronically and stored securely in Synapse (synapse.org), Sage Bionetworks’ data repository and analysis platform in the United States using secure Cloud services. We will separate your account information (name, email, contact information, etc.) from your study data (your responses to surveys and photographs of moles) to be analyzed.
We will use a random code number instead of your name on all your study data. This code cannot be used to directly identify you. Information about the code will be kept in a secure system. Only the study investigators, including War on Melanoma researchers and essential IT staff will have the key to link your coded study data to your name and account information.
We will NOT access other information on your phone for example, your personal contacts, other applications, text or email message content, or websites visited. We will never sell, rent, or lease your contact information.
Where will my data be stored?
Your study data (survey responses, photographs and measurements of moles) will be encrypted and transferred for data storage and analysis to Sage Bionetworks in the United States. We will combine your coded study data (without your name) with those of other study participants for analysis. For more information about our data practices in the context of the Synapse research platform, see the Synapse Governance Overview [https://www.synapse.org/#!Wiki:syn2502577/ENTITY]
How is my coded study data used in research?
Your study data (without your name) will be added to the data of other study participants and analyzed by the study team. The research team will analyze the combined data and report findings back to the community through scientific publications.
This study gives you the option to share your coded study data broadly, with qualified researchers worldwide for use in this research and beyond to benefit future research both academic and commercial. If you choose to share your study data broadly, your coded unnamed metadata (your response to survey questions and the mole measurements without the mole photo) will be added to a shared dataset available to qualified researchers on the Sage Bionetworks Synapse servers. (www.synapse.org). Your mole photos will be available to qualified researchers who have received ethical approval to use the photos for their research. It is important to note that the Principal Investigator and Sponsor will have no oversight on the future use of the shared study data by other researchers.
Is there risk to privacy?
We take great care to protect your personal information, but there is a slight risk of loss of privacy. This is a low risk because we separate and/or de-identify personal information that can directly identify you, such as your name or email from the study data to respect your privacy. Only the study organizers and some IT staff will have the key to associate your coded study data to your name and account information. However, certain skin features like tattoos or birthmarks may be unique to you and enable your re-identification. So even through your name is kept separate from your coded study data, it is possible that someone could still figure out your identity. To reduce this risk we recommend photographing moles at close range (~6 inches from skin surface) to minimize capture of secondary identifiable skin features.
SOURCE OF FUNDING FOR THE STUDY
The sponsor is Sage Bionetworks, http://sagebase.org/, with some funding from the Robert Wood Johnson Foundation.
QUESTIONS
Contact Drs Stephen Friend or Andrew Trister by email at<EMAIL_ADDRESS>or call 1-206-667-2115 (toll-free at +1-844-693-2137) for any of the following reasons:
Independent Contact: If you are not satisfied with how this study is being conducted, or if you have any questions, concerns, input or complaints about the research or about your rights as a participant, please contact:
Western Institutional Review Board® (WIRB®)
1019 39th Avenue SE Suite 120
Puyallup, WA 98374-2115
Telephone: 1-800-562-4789 or<PHONE_NUMBER>
E-mail<EMAIL_ADDRESS>WIRB is a group of people who independently review research.
WIRB will not be able to answer some study-specific questions, such as questions about appointment times. However, you may contact WIRB if the research staff cannot be reached or if you wish to talk to someone other than the research staff.
War on Melanoma Community Registry: If you have questions or want to opt out of the Melanoma Community registry, contact the registry personnel at 1-844-300-SPOT (7768) or<EMAIL_ADDRESS>For technical support with the app you can email<EMAIL_ADDRESS>CONSENT
I have read about this research study (or it has been read to me). All my questions about the study and my part in it have been answered. It has been explained to me that my participation in this study is voluntary and I freely consent to be in this research study.
I expressly authorize the collection, processing, use and disclosure of my study data, including health information in electronic database(s) for use in research as indicated in the privacy, confidentiality and data protection section, the data sharing setting through the app preferences, and the study Privacy Policy
I expressly authorize the transfer of my personal data, including health information, to Sage Bionetworks in the United States for research and data analysis. I understand that data protection laws in the United States may differ from the laws in the country where I reside.
By signing this consent form I have not given up any of my legal rights. I am free to withdraw my consent at any time and free of charge without giving reason.
 A COPY OF THIS FORM WILL BE EMAILED TO YOU.


The notchless HONOR 9X is RM999 and comes with pop-up camera, Google Mobile Services and more
As per tradition, HONOR Malaysia would always launch a new X-series at the end of the year and here we have finally witnessed the HONOR 9X's official launch. Priced at just RM999, the most interesting thing about this phone is not really the tech specs but rather the fact that it's also installed with Google Mobile Services. Anyway, here's everything you need to know about the phone and pre-order.
The pre-order of the HONOR 9X will begin tomorrow (22 November) on hihonor.com.my and Lazada platform. Depending on which platform you're planning to get from, there is a special deal for each starting from 22 until 27 November 2019 for every HONOR 9X purchase. For hihonor, you get an "add-on RM0.99" and a free HONOR Sports Pro Headphone, whereas for Lazada, you can get a free HONOR Band 5 Sport and gift box. After the pre-order period, the phone will officially go on sale on 28 November across the nation at their experience stores as well as Shopee with exclusive gift packs.
The remaining tech specs of the HONOR 9X are 6GB of RAM, 128GB ROM (expandable up to 512GB), 6.59-inch FHD+ IPS display, AIS Super Night Mode, GPU Turbo 3.0, and more. In addition to that, HONOR Malaysia also mentioned that the MagicBook Pro laptop and MagicWatch 2 are coming to Malaysia pretty soon and we are pretty excited about that! So what do you think about the HONOR 9X? Let us know in the comments section and stay tuned for more HONOR news at TechNave.com.


--- layout: post authors: ["Greg Wilson"] title: "A Few Articles on Education" date: 2015-05-25 time: "10:00:00" tags: ["Research", "Education"] ---
Over the past year, I've come to realize that Software Carpentry will only work if knowledge flows in several directions. Scientists need to learn about software development, but software developers need to learn about science, too. In particular, they need to learn that it's possible to study software and programming scientifically, which is what motivated yesterday's post about my favorite papers from ICSE 2015.
And both groups need to learn about evidence-based teaching practices and the politics that education is embedded in (because without an understanding of the latter, no change is possible). While I don't have a snapshot like ICSE to offer, here are a few recent articles I've found illuminating:
Audrey Watters: Lego Mindstorms: A History of Educational Robots. Near the end, Watters quotes Seymour Papert: "Little by little, the subversive features of the computer were eroded away. Instead of cutting across and challenging the very idea of subject boundaries, the computer now defined a new subject; instead of changing the emphasis from impersonal curriculum to excited live exploration by students, the computer was now used to reinforce School's ways. What had started as a subversive instrument of change was neutralized by the system and converted into an instrument of consolidation."
Audrey Watters: The Invented History of 'The Factory Model of Education'. This piece shows as well as anything that discussion of education is always political: everyone who wants change (or wants things to stay the same) is always arguing to reach a desired goal, and that has to be taken into account when reading what they write.
Bror Saxberg: Why We Need Learning Engineers. "Almost no one who is involved in creating learning materials or large-scale educational experiences relies on the evidence from learning science... We are missing a job category: Where are our talented, creative, user-centric 'learning engineers' – professionals who understand the research about learning, test it, and apply it to help more students learn more effectively?" I agree with the sentiment, but as with the advocates of "teaching machines" that Watters discusses, it's important to keep the author's goals in mind (he works for a large test prep company).
Mark Guzdial: Important paper at SIGCSE 2015: Transferring Skills at Solving Word Problems from Computing to Algebra Through Bootstrap. I'm a big fan of Guzdial's research, and as he says, it's surprising this paper hasn't received more attention, since it seems to show that teaching kids programming helps with their mathematical abilities. That may seem obvious to some readers, but "obvious" and "correct" aren't always connected, and even when they are, the strength of the connection always needs to be investigated.
Scott Freeman, Sarah L. Eddy, Miles McDonough, Michelle K. Smith, Nnadozie Okoroafor, Hannah Jordt, and Mary Pat Wenderoth: Active learning increases student performance in science, engineering, and mathematics. Reports on a meta-analysis of 225 studies comparing undergraduate learning outcomes in science and related disciplines to see if active learning outperformed traditional lectures. Short version: yes.
And if you want to see research and rebuttal in progress, check out Scott Alexander's Growth Mindset 3: A Pox On Growth Your Houses and David Paunesku's detailed rebuttal (with counter-rebuttal by Alexander). If the experimental method is the heart of science, then this kind of back and forth is its lungs.
Anya Kamenetz: Student Course Evaluations Get An 'F'. This popular science piece reports on work by Stark and Freishtat showing (again) that end-of-course surveys dont't actually tell us anything useful. (If you're behind the Great Paywall of Academia, you can read another study by Braga, Paccagnella, and Pellizzari that reaches the same conclusion.) Despite knowing this—the results aren't exactly new—universities continue to use such surveys because... well, that gets us back into a discussion of politics and learning, which is probably best saved for my personal blog, because I'm not supposed to use profanity here.


6 writes to Visibility
System.Management.Automation (6)
engine\InitialSessionState.cs (4)
126
Visibility
= visibility;
1298
aliasEntry.
Visibility
= SessionStateEntryVisibility.Public;
1412
provider.
Visibility
= SessionStateEntryVisibility.Private;
3947
newEntry.
Visibility
= this.DefaultCommandVisibility;
engine\remoting\fanin\InitialSessionStateProvider.cs (2)
2165
existingEntry.
Visibility
= SessionStateEntryVisibility.Public;
2597
existingEntry.
Visibility
= SessionStateEntryVisibility.Public;
21 references to Visibility
System.Management.Automation (21)
engine\CommandDiscovery.cs (2)
172
Visibility = entry.
Visibility
,
182
Visibility = entry.
Visibility
,
engine\InitialSessionState.cs (13)
463
SessionStateCmdletEntry entry = new SessionStateCmdletEntry(Name, ImplementingType, HelpFileName,
Visibility
);
507
SessionStateProviderEntry entry = new SessionStateProviderEntry(Name, ImplementingType, HelpFileName, this.
Visibility
);
555
SessionStateScriptEntry entry = new SessionStateScriptEntry(Path,
Visibility
);
633
SessionStateAliasEntry entry = new SessionStateAliasEntry(Name, Definition, Description, Options,
Visibility
);
689
SessionStateApplicationEntry entry = new SessionStateApplicationEntry(Path,
Visibility
);
782
SessionStateFunctionEntry entry = new SessionStateFunctionEntry(Name, Definition, Options,
Visibility
, ScriptBlock, HelpFile);
929
return new SessionStateVariableEntry(Name, Value, Description, Options, attrs,
Visibility
);
2374
if (ssappe.
Visibility
== SessionStateEntryVisibility.Public)
2385
if (ssse.
Visibility
== SessionStateEntryVisibility.Public)
3268
{ Visibility = e.
Visibility
};
3283
{ Visibility = e.
Visibility
};
5167
Diagnostics.Assert(pair.Value.Visibility == other.
Visibility
, "Pre-generated Provider visibility incorrect");
5187
Diagnostics.Assert(pair.Value.Visibility == other.
Visibility
, "Pre-generated Provider visibility incorrect");
engine\Modules\ModuleUtils.cs (1)
535
if (commandEntry.
Visibility
== SessionStateEntryVisibility.Private)
engine\SessionStateAliasAPIs.cs (1)
31
Visibility = entry.
Visibility
,
engine\SessionStateFunctionAPIs.cs (1)
29
fn.Visibility = entry.
Visibility
;
engine\SessionStateVariableAPIs.cs (1)
33
v.Visibility = entry.
Visibility
;
help\ProviderContext.cs (1)
124
if (sessionStateProvider.
Visibility
== SessionStateEntryVisibility.Private)
namespaces\LocationGlobber.cs (1)
1317
(sessionStateProvider.
Visibility
== SessionStateEntryVisibility.Private) &&


family info form for user
Name
No. of family members
what is your no in family
family info
Grand-Father:
Grand-Mother
father name
Mother Name:
Sister name:
Brother name:
Gender:
male
femail
other
write your feelings about you Family.
favorite person one
grand father
grand mother
papa
Mama
elder sister
younger sister
brother
younger brother


What Does 'Digital' Mean?
In comparison to a continuous signal, a digital signal is one that has been sampled. A digital signal is discrete, and is represented by numerical values. A digital image, for example, is represented by integers ranging from 0-255. A continuous signal must be sampled before it can be synthesized.
Plotted as a function:


@(addressForm: Form[models.users.Address],user: models.users.Customer) @import helper._ @main("Change Address",user){
Change your Address
@form(action=routes.HomeController.changeAddressSubmit, 'class -> "form-horizontal", 'role -> "form") { @* CSRF attack prevention *@ @* This token, sent by the controller, will be used to authenticate the form submission *@ @*The required fields are showing because of the constraints. Gonna look into this.*@ @CSRF.formField @inputText(addressForm("fName").copy(value=Some(user.getAddress.getfName())), '_label -> "Name") @inputText(addressForm("lName").copy(value=Some(user.getAddress.getlName())), '_label -> "Surname") @inputText(addressForm("streetAddress").copy(value=Some(user.getAddress.getStreetAddress())), '_label -> "Street Address") @inputText(addressForm("town").copy(value=Some(user.getAddress.getTown())), '_label -> "Town") @inputText(addressForm("country").copy(value=Some(user.getAddress.getCountry())), '_label -> "Country") @inputText(addressForm("eircode").copy(value=Some(user.getAddress.getEircode())), '_label -> "Postcode")


| View source on GitHub |
Creates early-stopping hook.
tf.compat.v1.estimator.experimental.make_early_stopping_hook
tf.compat.v2.estimator.experimental.make_early_stopping_hook
tf.estimator.experimental.make_early_stopping_hook( estimator, should_stop_fn, run_every_secs=60, run_every_steps=None )
Returns a SessionRunHook
that stops training when should_stop_fn
returns
True
.
estimator = ... hook = early_stopping.make_early_stopping_hook( estimator, should_stop_fn=make_stop_fn(...)) train_spec = tf.estimator.TrainSpec(..., hooks=[hook]) tf.estimator.train_and_evaluate(estimator, train_spec, ...)
Caveat: Current implementation supports early-stopping both training and
evaluation in local mode. In distributed mode, training can be stopped but
evaluation (where it's a separate job) will indefinitely wait for new model
checkpoints to evaluate, so you will need other means to detect and stop it.
Early-stopping evaluation in distributed mode requires changes in
train_and_evaluate
API and will be addressed in a future revision.
estimator
: A tf.estimator.Estimator
instance.should_stop_fn
: callable
, function that takes no arguments and returns a
bool
. If the function returns True
, stopping will be initiated by the
chief.run_every_secs
: If specified, calls should_stop_fn
at an interval of
run_every_secs
seconds. Defaults to 60 seconds. Either this or
run_every_steps
must be set.run_every_steps
: If specified, calls should_stop_fn
every
run_every_steps
steps. Either this or run_every_secs
must be set.A SessionRunHook
that periodically executes should_stop_fn
and initiates
early stopping if the function returns True
.
TypeError
: If estimator
is not of type tf.estimator.Estimator
.ValueError
: If both run_every_secs
and run_every_steps
are set.


{% extends "layout.html" %} {% block page_title %} GOV.UK prototype kit {% endblock %} {% block content %} BETA Home Sign out Warwickshire college Subcontractor: The college of Birmingham What type of funding stream will they deliver? AEB AEB classroom AEB work-based Apprenticeship levy 19+ EFS Course Save and continue {% endblock %}
BETA