Click or drag to resize
Llvm.NET LogoValueExtensionsSetDebugLocationT Method (T, UInt32, UInt32, DILocalScope)

[This is preliminary documentation and is subject to change.]

Sets the debugging location for a value

Namespace:  Llvm.NET.Values
Assembly:  Llvm.NET (in Llvm.NET.dll) Version: 3.8.6158
Syntax
C#
public static T SetDebugLocation<T>(
	this T value,
	uint line,
	uint column,
	DILocalScope scope
)
where T : Value

Parameters

value
Type: T
Value to set debug location for
line
Type: SystemUInt32
Line number
column
Type: SystemUInt32
Column number
scope
Type: Llvm.NET.DebugInfoDILocalScope
Scope for the value

Type Parameters

T
Type of the value to tag

Return Value

Type: T

Usage Note

In Visual Basic and C#, you can call this method as an instance method on any object of type . When you use instance method syntax to call this method, omit the first parameter. For more information, see Extension Methods (Visual Basic) or Extension Methods (C# Programming Guide).
Remarks

Technically speaking only an Instruction can have debug location information. However, since LLVM will perform constant folding in the InstructionBuilder most of the methods in InstructionBuilder return a Value rather than a more specific Instruction. Thus, without this extension method here, code would need to know ahead of time that an actual instruction would be produced then cast the result to an Instruction and then set the debug location. This makes the code rather ugly and tedious to manage. Placing this as a generic extension method ensures that the return type matches the original and no additional casting is needed, which would defeat the purpose of doing this. For Value types that are not instructions this does nothing. This allows for a simpler fluent style of programming where the actual type is retained even in cases where an InstructionBuilder method will always return an actual instruction.

In order to help simplify code generation for cases where not all of the source information is available this is a NOP if scope is null. Thus, it is safe to call even when debugging information isn't actually available. This helps to avoid cluttering calling code with test for debug info before trying to add it.

See Also